Søren,
It has been discussed before, but no one ever implemented it. RFC 2821
section 4.5.4.1 discusses a similar strategy:
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.
It also says that:
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.
So I agree on the idea to support progressive delay times. The last time
should be applied for all further retries. An RFC compliant configuration
might look like:
<!-- 5 minutes -->
<delayTime> 300000 </delayTime>
<!-- 10 minutes -->
<delayTime> 600000 </delayTime>
<!-- 45 minutes -->
<delayTime> 2700000 </delayTime>
<!-- 2 hours -->
<delayTime> 7200000 </delayTime>
<!-- 3 hours -->
<delayTime> 10800000 </delayTime>
<!-- 6 hours -->
<delayTime> 21600000 </delayTime>
<maxRetries> 25 </maxRetries>
That provides a 5 day retry period, with 4 attempts in the first hour, two
more within the first 6 hours, and then every 6 hours for the rest of the
period.
That is quite likely the initial configuration I would test on my server.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
