[Top] [All Lists]

Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

2020-09-26 20:45:33
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 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.


ietf-smtp mailing list