On Thu, Dec 19, 2019 at 10:32 AM Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org>
wrote:
\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.
Perhaps the software should add the ability to enforce the rules only on a
sample and
provide a mechanism for feedback so that it would be as easy for the
operator to know
whether a rule is working well as it is to put it in place in the first
place
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.
Yes, it is true that with an operator dealing with metrics and measurements
and is therefore
generally more accurate will, false positives will be harder to deal with.
It's the nature of
that game.
Brandon
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp