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

[Sam Varshavchik <[e-mail]>]

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.