[Top] [All Lists]

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

2020-09-18 17:36:38
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.

Courier has an optional setting that can be enabled, that verifies that "the domain name argument in the EHLO command actually correspond to the IP address". I have it enabled. It's one of my most successful spam filters. It's very valueable to me. It's possible that there were one or two instances in the last 25 or so years when I found out that this rejected something that wasn't junk, but I don't immediately recall a single one. I'll stipulate that there might've been one or two times, and that's a pretty good record.

I have no specific knowledge about other MTAs capabilities, but I suspect that many of them (at least the non-commercial ones) offer something similar in nature.

I think that the "MUST NOT", in there, should be, at the most, a "MAY NOT". The only situation where MUST NOT makes sense in my eyes would be someone who's already authenticated; a mail client on port 587.

I don't recall anyone flaming me in the aforementioned last 25 or so years, accusing me of violating the SMTP standard because I rejected whatever they deemed was so important to email to me and that I was obligated to read it. Maybe it happened, once or twice, I don't remember. But if someone did, I would've responded like this: you are absolutely right, and then end the conversion without any follow-up.

If I emailed someone and it bounced back because of this, it would never cross my mind complain about it. It's their mail server. Their rules.

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.

As a side note, I wasn't sure whether I want to mention this at all. It's actually against my self-interest to do so. After all, if this gets changed and becomes compliant behavior, and EHLO/HELO domain name validation becomes more prevalent: the spam factories will surely notice, adjust, and this spam filtering technique will become much less effective.

Attachment: pgp2zWAGDh6Uj.pgp
Description: PGP signature

ietf-smtp mailing list