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.
pgp2zWAGDh6Uj.pgp
Description: PGP signature
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp