Philip Miller <millenix(_at_)zemos(_dot_)net> wrote:
Verifying HELO provides the following benefits, in no particular order:
I'll bite. What, exactly are you verifying?
RFC 2821 Section 3.6 says:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 188.8.131.52.
Section 4.1.4 has similar text.
But many mailers will accept unresolvable names in EHLO. And
Section 4.1.4 says
An SMTP server MAY verify that the domain name parameter in the
EHLO command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about
verification failure is for logging and tracing only.
So you're not supposed to validate the EHLO field.
Further, Section 184.108.40.206 allows for something *other* than primary
domain names or address literals:
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
Ok, that's a SHOULD, not a MUST. So if there's no primary domain
name, and the client doesn't want to send an address literal, what
does it send?
And what address literal does it send? [127.0.0.1] seems to be OK.
Many spammers send an address literal of the IP of the recipients MTA.
Section 4.1.4 says:
If the EHLO command is not acceptable to the SMTP server, 501, 500,
or 502 failure replies MUST be returned as appropriate.
OK, so why would it not be acceptable? Is it up to the
implementation to decide? Apparently so, but the implementation is
forbidden by 4.1.4 from using the argument to EHLO for any kind of
It's a catch-22. Servers are given data in a field, told it means
something, but are forbidden from doing anything to verify that the
data is meaningful.
What does that data mean, then? So far as I can tell, nothing.
We can look at EHLO argument verification as fixing a design flaw in
RFC 2821, where the protocol description contradicts itself, and makes
compliant implementations impossible.