Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
On 9/18/20 6:36 PM, Sam Varshavchik wrote:
RFC 5321 declares:
# An SMTP server MAY verify that the domain name argument in the EHLO
# command actually corresponds to the IP address of the client.
# However, if the verification fails, the server MUST NOT refuse to
# accept a message on that basis.
It's been my experience that this is frequently ignored in practice:
in varying ways whatever is seen in EHLO gets validated against DNS
and if found to be unacceptable mail gets rejected based solely on
that criteria. This is not a very popular thing to do overall; but it
is not a rarity either, and I hear about this regularly. This very own
E-mail was prompted by a thread on my mailing list from someone who
had this happen to them this week. I don't know how common this
practice is, but it's not uncommon.
Ok, this will probably look a bit like a rant. Apologies in advance,
and this is not meant to be disparaging to anyone.
1. Especially these days in the widespread presence of NATs and proxies
of various kinds, it is meaningless to "verify" the domain name argument
in HELO/EHLO. Really it has never made any sense to compare HELO/EHLO
argument against PTR lookup results on the source IP address because (a)
hosts commonly had multiple interfaces with different names, and clients
might not bother checking which outgoing interface was being used; (b)
the longstanding practice of two-faced DNS means that the client host
and server may legitimately see different results from PTR lookup; (c)
ISPs have (unfortunately) been polluting in-addr.arpa for years with
made-up names which add no value; (d) historically the most likely
reason for HELO/EHLO arguments to be "wrong" (assuming one could even
define what that meant) was client MTA misconfiguration unrelated to
message content; (e) there was never any requirement that Internet hosts
have distinguished names anyway. Also, these days it's quite
commonplace for servers to log source IP addresses independently of
anything said in HELO/EHLO, so insisting that EHLO arguments match
source IP address as viewed by the server, really adds no value.
2. The HELO/EHLO argument is historically (and should continue to be)
simply what the client host thinks its name is. This is useful in
Received header fields and logs, to diagnose problems that occurred on
the sender's end of things. (e.g. "Which host is generating this
garbage Content-Disposition field?" "It's the one that thinks its name
is 'mumblefrotz'".) So when you find an MTA config with its name set to
mumblefrotz, you know you've found it. This is useful in a different
way than source IP address is, because nothing (that I'm aware of)
requires client SMTPs to have stable source IP addresses. So I would
argue that it SHOULD NOT be derived from the client host's idea of its
source IP address. (I could make a case for encouraging HELO/EHLO
arguments to be UUIDs or some other kind of globally-unique identifier,
but it's probably about 30 years too late for that.)
3. 821, 1123, and subsequent revisions all seem to be based on the
assumption that if you're operating an SMTP server, you're trying in
good faith to deliver (legitimate) email reliably. I'm not sure this
assumption holds true anymore, or has held true in general for the past
20 years or so, because a lot of providers these days seem instead to
regard all externally-originated email with suspicion, and to be trying
to find every possible excuse to reject email.
Seen from that perspective, maybe 5321's language about EHLO arguments
could use some updating along the following lines:
- For a very many reasons [which could be listed, or not], SMTP servers
have no reasonable expectation of being able to determine the validity
or legitimacy of a message based on comparison of the EHLO command
argument with anything else at all. Therefore if what you're trying to
do is reliably deliver legitimate mail (for some meaning of legitimate),
validation of EHLO arguments is useless and strongly NOT RECOMMENDED.
Of course, if your goal is really to discard mail for no good reason,
and you're not handling incoming mail for anyone but yourself, have at
it! Just have the decency to blackhole the mail rather than bounce it,
since you're really not doing anyone any favors.
(If it were normal for SMTP clients to relay mail with TLS and use
client certificates to do so, maybe it would then make sense to check
EHLO arguments against the client certificate's name. But we're a long
way from being there.)
I would argue for making this a SHOULD or perhaps a MAY, because making
it a MUST tempts servers to perform meaningless checks against it.
Then there's also this part:
# o The domain name given in the EHLO command MUST be either a primary
# host name (a domain name that resolves to an address RR) or, if
# the host has no name, an address literal, as described in
# Section 4.1.3 and discussed further in the EHLO discussion of
# Section 4.1.4.
Not sure how to square this away. If it's a MUST, and this fails this
test, it seems to me that a mail server is no longer under any
obligation to continue to attempt to do something useful with a sender
that does not comply with this RFC. But this requirement conflicts
with the other requirement. I do not see how to reconcile these
conflicting assertions. Either it is permissible to disengage from a
non-compliant client, or not. Both can't be true.
ietf-smtp mailing list