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

[Laura Atkins <[e-mail]>]

> On 20 Apr 2021, at 15:19, Richard Clayton <[e-mail]> wrote:
> 
> In message <[e-mail]>,
> Laura Atkins <[e-mail]> 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
[e-mail]
[phone]		

Email Delivery Blog: https://wordtothewise.com/blog