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
does.
Yes.
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?
Maybe?
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com