[Top] [All Lists]

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

2007-11-18 05:22:41

John C Klensin wrote:

--On Saturday, 17 November, 2007 21:54 -0500 "Robert A.

You need at least 4 days to handle 3 day weekends (a holiday
on Friday or Monday) although I've seen 4 day Holidays (Xmas
and New Years on a Friday and the company shutting down at
Noon on Thursday). A better idea is to use 3 days BUT adjust
it to 4 or 5 days when there is a Friday/Monday holiday
(although that can still run into problems since it is US
Centric and can run afoul of Non-US Holidays).

And that is exactly why the guidance in the spec says what it


Please keep in mind that my suggestion is specifically regarding the 2nd and possibly 3rd retry but mainly the 2nd one, in regards in minimizing the impact related to the growth Challenge/Responses-based systems.

Going beyond begins to get into subjective and complex considerations, and I don't believe you want to go there for 2821bis. Me too.

Even though I believe that most systems already have shorter initial intervals, all I am suggesting is a simple clause or sentence to give "hindsight" to RFC 2821 readers and future developers regarding a shorter 2nd attempt.

Based on what I read in 2821bis (I have rev3), it goes into great length regardng reasons why the stragety may be altered, in particular this paragraph:

   Experience suggests that failures are typically transient (the target
   system or its connection has crashed), favoring a 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.

Well, I think there is adequate global experience today that failure may includss challenge/response systems, not just necessarily downed systems or connections. I know anti-spam ideas is a taboo for you in RFC 2821bis, so maybe someone can finesse some sentence there to include this consideration without actually getting into a AVS relationships?


   In addition, experience suggest that a SMTP receiver may have
   a local policy which will temporarily reject the first initial
   delivery attempt by anonymous SMTP senders using a 451 response
   code from with an expectation the SMTP client will
   retry successfully.  For a 451 response, the SMTP client MAY
   consider using a shorter 2nd retry attempt to minimize the
   delivery impact when connecting  to these types of remote systems.

I was thinking of specifically saying 451 only. That way, it won't effect 450, 452 operations. Otherwise, make it 45x.

Or something simpler:

   A SMTP client MAY consider shortening the 2nd attempt ONLY to
   5-10 minutes for 45z responses to RCPT TO or DATA.  For failed
   connections, the SMTP client SHOULD continue with the
   suggestions outlined in this section.


Hector Santos, CTO

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