On Fri, 17 Jan 2003, Dr Andrew C Aitchison wrote:
> Ian Jackson has pointed me at RFC1123, section 5.3.1.1 Sending Strategy
> The sender MUST delay retrying a particular destination
> after one attempt has failed. In general, the retry
> interval SHOULD be at least 30 minutes; however, more
> sophisticated and variable strategies will be beneficial
> when the sender-SMTP can determine the reason for non-
> delivery.
>
> The default retry rule in src/configure.default (exim 4.12) is
> * * F,2h,15m; G,16h,1h,1.5; F,4d,6h
>
> which for the first 2 hours retries twice as often as the
> SHOULD requests. Are there good reasons for the default config
> to ignore the advice of an RFC ?
SHOULD of course is weaker than MUST, and even then RFCs are not legally
binding statutes. Note also that 1123 is now 13 years old. Back then, a
lot of MTAs' retry strategies were simply to retry each message at a
fixed interval until it expired.
When I wrote Exim, I wanted to be more clever than "retry every x
minutes for y days"; hence the more sophisticated retry rules, which try
frequently for a short time, and then start backing off.
I cannot remember why I chose the values that I did back in 1995, but
note that Exim's retry times are not guarantees. They are just
suggestions, and in general the actual interval will be longer. If you
are running queue runners every 15 minutes (on the quarter hour, say),
and a message fails at xx:08, the queue runner at xx:15 will skip it, so
it won't be retried until the xx:30 queue runner finds it. Depending
on the speed with which that queue runner processes the queue, it might
be some time after xx:30; however, at the fastest, you get a 22-minute
delay, not a 15-minute one. If your queue runners are hourly, the delay
will be longer.
The answer to your question is probably "No, there are no 'good
reasons', just gut feelings." I think you are the first person to
question this since 1995. Back then, I felt that the default rule was a
rough guess that could/should be refined in the light of experience.
It's taken a long time for the feedback to arrive. :-) In practice,
almost everybody seems to make use of the default rule without change.
The only change that has ever been made to the default was to shorten
the final interval from 8 hours to 6 hours.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.