Re: RFC 5321bis / 2821ter

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.
Cheers,
  Steve