Alan DeKok said:
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 4.1.1.1.
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.
I interpreted that to mean that an EHLO cannot be rejected on the basis of
the EHLO argument not resolving to the peer IP address.
Further, Section 4.1.1.1 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.
I think implicit in that text is that the address literal sent would
actually somehow represent the client host. By that criterion, if it
doesn't have a FQDN or a meaningful IP, it should send [127.0.0.1], so as
not to commit forgery.
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
validation.
As I recall, SMTP servers are free to reject (at any point in a
conversation) for any local operational or policy reason. That would
include validation of the sort we're discussing.
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.
That's how I'm looking at it. There are flaws in RFC 2821 that prevent
accountability and allow harmful forgery of various protocol fields. We're
here to fix that.
--
Philip Miller
millenix(_at_)zemos(_dot_)net
"Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former"
-- Albert Einstein