On Sat, 2005-04-02 at 21:14, Gavin Carr wrote: > On Sat, Apr 02, 2005 at 03:54:37PM -0600, Les Mikesell wrote: > > > Anyway, the point of checking that a system that's trying to deliver > > > email to you has a name that resolves to the address it's using, that > > > that address resolves back to the name, and that the HELO specifies > > > the correct name as well, is that most privately owned Windows PCs > > > don't fulfill those requirements. > > > > There is no requirement for the HELO to match anything else. It must > > be syntactically correct but it does not have to have anything to do > > with the particular interface you happen to be using. On the other > > hand the From: address does have to be resolvable - otherwise you > > wouldn't be able to reply anyway. > > Wrong. RFC2821 says: > > 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) > > These commands are used to identify the SMTP client to the SMTP > server. The argument field contains the fully-qualified domain name > of the SMTP client if one is available. In situations in which the > SMTP client system does not have a meaningful domain name (e.g., when > its address is dynamically allocated and no reverse mapping record is > available), the client SHOULD send an address literal (see section > 4.1.3), optionally followed by information that will help to identify > the client system. The SMTP server identifies itself to the SMTP > client in the connection greeting reply and in the response to this > command. A SHOULD is not a requirement. A MUST would be a requirement. Even if it did mention a requirement, there is nothing that says a host with multiple addresses should use the name matching the connected interface each time. There is certainly nothing there to override the earlier RFC (which I've forgotten) that specifies a similar recommendation but goes on to say that the receiver MUST NOT reject the message based on an address lookup mismatch for the HELO/EHLO name (obviously written by someone who realized that multi-homed servers are common and that corporate servers often live behind NAT firewalls and don't even know the address that will be used the public side). -- Les Mikesell les at futuresource.com