On 20 Apr 2021, at 15:19, Richard Clayton <richard(_at_)highwayman(_dot_)com>
wrote:
In message
<F8AC11B4-1C30-4DE6-AE70-F91994EE7539(_at_)wordtothewise(_dot_)com>,
Laura Atkins <laura(_at_)wordtothewise(_dot_)com> writes
I see nothing to gain from forcing a sending server to artificially limit
itself; how after every N sent messages it has to close its socket, and
reconnect again. What is that supposed to accomplish? I don't get it.
It’s a limit that was implemented more than a decade ago by some of the
highest
volume receivers around. I don’t think we have to understand why they did it
-
if even the folks who made the decision are still around. [1] We can just
say:
this is commonly occurring behavior and it makes sense for SMTP to document
it
and have a way to explain it.
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".
Absolutely this is true.
But many of these systems also have rules that apply universally and have
nothing to do with any reputation or performance issues. I was keeping track of
them and making them publicly available many years ago. The commercial MTAs
mostly handle this in an automated fashion and these limits aren’t published
the same way they were in the past (on postmaster pages).
To give an example of limits I was sharing:
Provider 1: 25 connections per IP address 100 recipients per
message
Provider 2: 5 connections per IP address 100 messages
per connection
Provider 3: 1 connection per IP 1 email
per connection
Provider 4:
500 emails per connection; 100 recipients per message
Provider 5:
20 emails per connection; reputation based rate limiting
Providers 3 and 5 still have those limits in place. The others I’m not as sure
about.
This data is publicly available, I’m just hiding the providers because I really
don’t think the details of who is doing what is relevant to the discussion.
It’s enough to know that major providers are doing this and have been doing
this for at least a decade.
Providing a programatic way to advertise the maximum limits seems to me to be a
good addition to the information transmitted. Less reliance on individual
people manually maintaining lists of information is never a bad thing.
[… snip ...]
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)
That’s the statement I am looking for here. We accept no more than this, even
for the servers with the absolute best reputation. With the understanding that
those limits may be lower (sometimes significantly lower) for senders with
poorer reputation.
laura
--
Having an Email Crisis? We can help! 800 823-9674
Laura Atkins
Word to the Wise
laura(_at_)wordtothewise(_dot_)com
(650) 437-0741
Email Delivery Blog: https://wordtothewise.com/blog
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp