On Fri, 2 Sep 2005, Michael Haardt wrote: > > And that's pretty much my problem, so I thought about solving it just > the same. I can see a use for fixed retry intervals, but does anybody > really care about a geometric interval being met exactly?
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. 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. 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). 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. Tony. -- <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://dotat.at/ ${sg{\N${sg{\ N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\ \N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}} -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
