ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT

2021-04-20 09:33:46


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