\On Dec 19, 2019, at 11:55 AM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
Note also in this case - where the presence of an IP address literal in EHLO
is used as the sole criterion for rejecting a message before the message is
actually transferred to the server - there's no opportunity to consider other
criteria such as sender address validity, DKIM or other indications of
authenticity, or the content of the message itself. To justify rejecting a
message on a single test that is entirely unrelated to the content, I'd
expect that test to have an extremely low FP rate, much better than one
considered "good enough" when used in conjunction with other tests.
Performing multi-factor analysis on messages at "." time, while the remote
client is waiting for "250" is expensive and risky. Under high load there
may not be sufficient CPU to evaluate all pending messages before some of
the clients time out. That can lead to multiple deliveries of the same
message, and general exhaustion of server resources. Faced with botnets
and SASL password brute-forcing attacks, ... MTA operators often strive
to turn away as much junk as possible with comparatively cheap tests before
the DATA command.
This includes RBL checks, presence of PTR, PTR name regexp checks, ...
Rejecting address literal in EHLO is a filter in this class, that can
be justified entirely on its efficacy. If the reported one complaint
in 10 years is about right, then it is working well enough in practice.
Yes, likely the efficacy of the local rules is not reassessed as often
as one might wish, and may be largely complaint driven. That's the
nature of how limited devops cycles are spent. This is not shocking
or even surprising.
But I'd rather deal with a responsive operator with a few odd rules
that reject traffic outright (I get a bounce), than operators that
strictly follow the wire protocol, but then silently deliver to the
Junk folder, and are too big to respond to reports from most senders.
(Your example of losing business because of undelivered proposals
likely falls into the Junk folder delivery category, not SMTP-time
rejection, which you'd have addressed on receipt of the bounce).
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp