On Sat, Apr 02, 2005 at 09:41:41PM -0600, Les Mikesell wrote:
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).
I agree with your specific point that using a HELO domain that does not match your ip address (if a literal) or your reverse mapping record does not mean you are in violation of the RFCs. And therefore, denying mail on that basis is bad.
But your initial:
There is no requirement for the HELO to match anything else.
is too strong. There *is* a general requirement (the SHOULD) that the HELO domain belongs to the client. Syntactic goodness is not sufficient.
I reject all mail where the sender HELO's with any of my ip address literals, for instance, which I do consider a violation of the RFCs, and removes a surprisingly large chunk of spam.
Cheers, Gavin