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