On 12/19/19 1:32 PM, Viktor Dukhovni 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.
Yes. Some version of this has been understood since at least RFC 1047.
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.
Not surprising. I wonder if there's any way we can improve the ability
of MTAs to reliably filter spam based on cheap tests?
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.
It is not surprising, but it should be. I don't see why maintenance of
networks should employ any less discipline than maintenance of ships or
aircraft.
(To be fair, the overall state of software used to communicate over a
network is equally sad. I can't help but wonder if typically poor
practice in software development has leaked into "devops" practices and
done further harm to operations.)
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.
I certainly agree about that. Delivery to the Junk folder is pretty
much tantamount to sending the message to /dev/null, except in certain
cases like the initial exchange of email between two people who have
agreed to exchange email via other means. In those cases the recipient
knows to look in the Junk folder to see if the message was mislabeled,
and may even be able to add the sender to a white list or address book.
(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).
I wouldn't have received the bounces in such cases. The senders of
those messages would have received them, and likely concluded that my
email address no longer worked at all.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp