[Top] [All Lists]

Re: RFC 5321bis / 2821ter

2009-01-25 14:24:09

On Jan 25, 2009, at 10:52 AM, David MacQuigg wrote:

Sorry for being sloppy in implying that section 4.1.4 requires that receivers accept "HELO this is Jupiter". The connection between cause and effect is less direct. I should have said that this requirement (no rejection when verification fails) makes the HELO name unreliable for authentication. It means that receivers MUST accept mail from transmitters that provide a fraudulent ID, i.e. one that does not correspond to the IP address of the TCP connection. The fact that receivers can't rely on the HELO name leads to little use of that name for authentication, and attempts to find some other name (MAIL FROM) that will more reliably ID the transmitter. This may be the reason so many transmitters provide useless HELO names like Jupiter.

The Jupiter example came from a long ago discussion in the SPF group, in which the conclusion was we have to accept this, even if it is obviously invalid. The reason was that some legitimate senders have HELO names like this, and we would be rejecting legitimate mail.

Why not say:

 An SMTP server MAY reject a mail session if a domain name argument in
the EHLO command does not actually correspond to the IP address of the client. Clients that are unable to establish this correspondence MUST
 NOT provide an invalid domain name argument.

How the correspondence is established should be left to another spec (CSV, SPF, whatever). There is no change in the syntax of the HELO command, no change that would affect receivers following the old MUST NOT rule, just a change in emphasis that should have a beneficial effect on the reliability of HELO names as IDs.

I see very little downside. The examples of the digital camera and the roaming laptop don't justify degrading the reliability of HELO IDs for everyone else. Maybe I'm not understanding these examples. See below for discussion of the roaming laptop.

If I'm an SMTP client behind a NAT I probably have no idea I'm behind a NAT, and my local IP address (and, hence, hostname) will likely have little connection to the visible IP address.

More importantly, perhaps, if I'm an SMTP client behind a NAT then the hostname used in EHLO is the only recorded trace of where the email originated. The only time that identifier is useful for diagnostics is in the case where there isn't a 1:1 correspondence between the EHLO identifier and the external IP address.

Mailservers behind NAT aren't at all unusual. Multiple mailservers NATing to a single IP address aren't unheard of.


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