[Top] [All Lists]

Re: SMTP traffic control

2011-10-28 15:53:00

On Oct 28, 2011, at 12:28 PM, Rosenwald, Jordan wrote:

Perhaps I missed something (this has been a long thread), but I'm completely 
missing how this will solve the problem of long, unpredictable delays for 
users. Everything I've read says these are return codes for server 
consumption, not to be returned to users. 

As best I can tell this proposed idea does nothing for the end user. 

Mail that's delivered quickly, in a minute or so, vs mail that sometimes takes 
a half hour to deliver makes a difference to the end user. Both due to the 
noticeable delay, and the annoyance of conversations arriving out of order.

Sometimes mailservers want to shed load, or prioritize one source of traffic 
over another. The only way to do that within SMTP that doesn't require you to 
keep a session open is to respond with a 4xx deferral and wait for the client 
to retry.

An ESMTP client, such as your ISP smarthost, will wait a while before retrying 
in response to a 4xx deferral. The RFCs say they should wait at least 30 
minutes the first time. 

If Yahoo!, uh, I mean the receivers MX, only needs to shed load for a short 
time period, or just wants you to drop your open TCP session and go back to the 
TCP connect queue so that someone else gets a chance then all they can do is 
send that 4xx response and delay that mail delivery by 30 minutes or so. 

It would be nice if the server could say "give me a minute to get my stuff 
together and come back", have the client retry in 60 seconds and get the mail 
accepted for delivery - with a delay of a minute or so, rather than a delay of 
30 minutes. The server gets to shed load, the client gets to dump a message out 
of it's queue and the human correspondents see fast, in-order mail delivery 
rather than slow, out-of-order delivery.

That's the end-user visible part of the thought behind anyway.


<Prev in Thread] Current Thread [Next in Thread>