Re: Submission identifiers

John C Klensin wrote:
> --On Friday, January 23, 2009 18:37 +0100 Alessandro Vesely
> <vesely(_at_)tana(_dot_)it> wrote:
> > Paul Smith wrote:
> > > IMV, if it is expected by the base standard that the EHLO 
> > > data is to be used for anything other than logging/tracing, 
> > > then these considerations and more need to be looked at 
> > > carefully. 
> > How "meaningful" can a name be?
> >
> > [...] an MTA could say "EHLO SPF:example.com", if SPF were included 
> > in an extended registry of (meaningful) Address Literal Tags.
> Free advice: Changing the argument to EHLO from FQDN-or-literal
> to trick-identifier is likely to be a non-starter.  A very large
> fraction of the deployed base would treat SPF:example.com (or
> anything vaguely like that) as a syntax error and reject the
> message.
I agree that it probably won't work. Of course, the sender might check 
if the server's greeting included "SPF tags accepted", or similar. 
However, that's reinventing SMTP extensions.
The receiving server may answer 504 or 550 to the EHLO command. As 
this is where clients use to try HELO instead, there is little margin 
for negotiation either.
> Consider instead an ESMTP extension command, say IAGG (I'm A
> Good Guy), that was required to be issued immediately after EHLO
> if one intended to use it.
Yeah, a proper SMTP extension would make for sounder specs. Yet, note 
that in both cases the actual specification of the identifier would 
live in its own RFC.
> It would avoid getting the new ideas about what the field might
> be used for tangled up with an installed based that believes
> that it knows what is there and what syntax it obeys.
Having the IP address of the sender seems useless, if it must be the 
same that the server already knows from the IP layer.
Could it be a MAC address? That might be useful in some DHCP-driven 
environment. Unwitting MTAs may just accept any token. However, MACs 
would break DNS checks too.
> > What real cases are there that cannot be handled in similar
> > ways? A careful analysis could help to eventually eliminate
> > the phrase (in 4.1.4) "if the verification fails, the server
> > MUST NOT refuse to accept a message on that basis."
> Keep in mind that there are things that send SMTP that don't
> know their own names, may know there own addresses only in
> private address space behind a NAT, and have no way to anchor
> SPF information even if they wanted to.
I think the question is whether we want those things to be able to 
send to any host but their configured gateways. Since the split 
between submitters and relayers, time should be mature for requiring 
the latter ones to behave somewhat decently. Most of them actually do.
The EHLO name has better be unique for tracing and debugging. OTOH, it 
has better be "meaningful" for filtering and reputation management. Do 
these two kind of activities somehow match the scenarios implied by 
that split?