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.)
> 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.
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.
Keith


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp