[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-19 13:53:25
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.


ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>