> Exim doesn't promise to do so; the retry time is just a "do not try > before" time. The actual delivery attempt will not occur until a queue
> runner turns up. However the hints database can compensate for this
> randomization.
Right. All I want is to randomise the earliest possible retry time.
> If your problem is within a cluster you control, then it sounds to me like
> a configuration error if your front end can hammer your back end to death.
I am talking about failure recovery, not regular operation.
> Unfortunately Exim doesn't make it easy to control its rate of outgoing
> delivery attempts, so if your front end is also delivering elsewhere (to
> the Internet) then restricting the delivery rate to your back end will
> hurt other email. Perhaps you should look at tuning the back end so that
> it is hurt less by floods of email (queue_only_load, smtp_accept_queue,
> smtp_accept_queue_per_connection).
Queueing under load is bad advice, as it makes things worse. Mail servers
are usually limited by I/O. Immediate delivery delivers from page cache.
Queued delivery has to read the mail back into core, thus causing
additional I/O. It is fine for short peaks, but if in trouble, then try
to avoid queuing and better limit the number of connections and let others
retry.
It's just too bad if they all wait, and then retry all at once. That's
what I am trying to avoid.
> Alternatively, you might try separating
> the back-end delivery queue from your main queue so that it can be managed
> by an Exim with less aggressive parallelism settings.
Put it differently: What would break if geometric retry intervals would
use the computed earliest retry time as interval for a random number?
