ietf-smtp
[Top] [All Lists]

Re: 2821bis consideration - New 2nd attempt Retry Strategy recommendation

2007-11-17 08:09:13

Hi John,

Fair enough. I'm going to pencil in some work to get some feedback and tune the default frequency table and also add other factors as you and SM suggested.

But just note, I am not the only one with a 5 minute 2nd retry. I quick review showed ISP bellsouth.net servers had a 5 min retry. AT&T took over BS and it also uses 5 mins. The largest telecomm company, and among the tops in inventing, understanding and optimizing data communications, packet switching, volume distribution ideas can't be that wrong? <g>

I can't say if they are using the same BS computers, but I see they are using different IP addresses. I'm going to take the time to get an average for 2nd retries from my logs for the past year, and also ask a few spread of customers to do the same.

--
HLS

John C Klensin wrote:



--On Friday, November 16, 2007 9:48 PM -0500 Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:


Hector Santos wrote:

I probably should of use, 3 days since our original defaults
(non-variable) was once per hour, 72 attempts or 3 days.  And
if you  follow 2821 recommendation, it suggests 4-5 days.
With 30 mins intervals  it yields an awful amount of 240-300
retries.

Sorry, bad math - 192-240 attempts!

Except that 2821 suggests rather rapid backoff ("...policy of two
connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours..."). One could stay with 30 minutes if one wanted to, but the recommendation is more like
   0, 30 minutes, 1 or 2 hours, 2 or 3 hours, 2 or 3 hours,...
My personal experience is that
0, 30 minutes, 30 minutes, 1 hour, 2 hours, 2 hours, 4 hours, and then continuing at four or even six hour intervals yields good results and, at least in the absence of a deliberate delay policy on the server, does not, on average, result in significantly slower delivery than a "try every thirty minutes" plan. That is especially true if the SMTP sender queues are threaded s.t. as soon as a connection can be made to a given SMTP receiver, all pending traffic for that receiver is moved to the front of the queue and transmitted. Of course, any sort of per-message greylisting would foul that procedure up as well.

    john








--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

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