[Top] [All Lists]

Re: Submission identifiers

2009-01-24 09:55:19

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", 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 (or
anything vaguely like that) as a syntax error and reject the

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?

<Prev in Thread] Current Thread [Next in Thread>