As you will know, the highest volume receivers have complex machine
learning systems which can -- after a number of messages -- come to the
conclusion that sending a SYN-ACK at the start was somewhat of a
mistake... use of resources is more efficient if you make such senders
(which dominate) start at the beginning again and you just refuse to let
them connect "ever again".
True, but it's also the case that such conclusions can be reached
by an all-too-human staff; no fancy ML required.
From an engineering standpoint the overhead of 5xx-ing a small number of
emails per session once the sender is understood to be bad may be a
reasonable tradeoff compared with the complexity of chasing round all of
your servers (of which you have rather more than one or two) identifying
which open connections should be aborted.
Especially since you can do it at the MAIL FROM, and if the sender proceeds to
send the message anyway or otherwise misbehave rely on the server's built-in
logic to deal with that.
(We actually support both approaches.)
Other (related) considerations apply to email submitted over
authenticated connections (you may realise as the email piles up that it
is likely that the credentials are being misused)
What we should be doing is figuring out how to make these limits more clear
to
senders.
as I observed before -- don't expect much more than a generic statement
(which comes down to "sending N good emails is the most you can expect
to be able to manage") from such systems. Anything which revealed the
current view ("actually, you've pretty much exhausted our patience")
just is not going to happen (IMO)
I don't really understand the concern here, and more importantly, how to address
it. Any time you connect to someone else's SMTP server there's a implicit
understanding that it will only accept what you send as long as you send what it
considers to be good stuff. The LIMITS extension operates within this context;
all it does is let the server add to the client's understand of what's
acceptable; in no way does it change that basic understanding.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp