[exim] Need help with retry database

Inizio della pagina
Delete this message
Reply to this message
Autore: Vadnais, Kevin
Data:  
To: exim-users
CC: Russ Wilton, Doran Anderson, Jim Savoy, John Bronk
Oggetto: [exim] Need help with retry database
Hi everyone,

I'm still fairly new to exim, so please have patience with me.

We've encountered a really annoying issue running exim 4.69 and routing
email to google servers. Fairly often we will get "Connection refused"
errors from the google servers, which is understandable given their high
volume of email. However, our exim retry table caches each individual ip
address and doesn't remove itself from the table after a successful retry
occurs.

For example, we had multiple errors sent to this server

T:aspmx.l.google.com:209.85.223.56/142.66.3.48 111 65 Connection refused
17-Feb-2010 15:33:24 17-Feb-2010 22:22:19 17-Feb-2010 23:22:19

The first error was seen at the 17-Feb-2010 15:33:24 timestamp and 5
minutes later that message was successfully delivered(verified in the exim
log). We received two additional rejections later that night at 2010-02-17
20:17:54 and 2010-02-17 22:22:19 respectively. Both messages were
delivered, but the time delays between retries increased beyond what I would
have expected. These emails are also going to a section of our local domain
which we are migrating over to gmail.

Our retry rules look like this.

*@+our_domains         *           F,30m,5m; F,4h,15m; F,4d,1h; F,7d,4h
*@*                 refused_A      F,2h,15m; G,1d,30m,1.5
*@*         timeout_connect_A      F,2h,15m; G,1d,30m,1.5
*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h
Where I am having issues, is that our retry entry is now looking at the
first failure time to base it's retry attempts off of, even though the
original message was successfully delivered.  Now I have to deal with 1 hour
delays between failures on this server, which will eventually get to 4
hours, and finally time out completely.


Eventually, we start to get email refused errors immediately and bounce
messages get sent back indicating too long of retry occured, even though the
bounce messages are sent the exact same second as they were received.

My questions are as follows:
1. Is there a way to remove entries from the retry database when a
successful delivery occurs for a given ip address?
2. Is there a way to reset the original time stamp in the database entry
for the new entries that come in?
3. What kinds of retry rules can I write that might eliminate this issue
from occuring in the future? Can I do something based off of the
google.comdestination?
4. Are there any other obvious solutions to this that I have missed?


Thanks for your help


--

Kevin Vadnais
Systems Programmer
University of Lethbridge
403-332-4056