/me@(voip.)?|www./ SamLown.com

Exim: Removing blocked domains from the hints database

My Mail Transfer Agent of choice is exim, which I’ve now been using for many years. After trying many others over time, I’ve found it the easiest and most flexible to control how I want, including access control from IMAP servers and MySQL databases for virtual domains and user control.

A setup which I have used several times now, is to use two servers for handling mail for small offices. One server sits in the office with IMAP so that everyone has their own local mail, and the second is a box somewhere on the internet that receives all the mail and forwards it to the office machine when needed. This setup works great, except when there is a power out in the office over the weekend, and there is a backlog of mail on the internet server which refuses to be delivered until the retry times are reached.

This is what you’d expect and hope would happen so that no mail is lost, however there are times when you’d like to the situation to be resolved as soon as possible. Here’s how I forced the mail to be delivered.

Exim maintains a special database in its spool directory of delivery hint information. This allows exim to know which domains and hosts haven’t resolved correctly, when to try another delivery, and a list of messages which are waiting to be delivered, amongst a few other bits of information.

To find out what this database contains, the exim_dumpdb command can be used in combination with grep to find out details about hosts stored in the database. To speed things up a bit, we also have the exinext command which will provide information about a specific domain. For example, when a domain is blocked you’ll get something like this:

 > exinext berlin.ciudad21.net
 R: dnslookup for user@berlin.ciudad21.net
 first failed: 02-May-2007 15:57:24
 last try:     03-May-2007 07:48:44
 next try:     03-May-2007 15:24:21

As can be seen, for mail to be delivered to that domain, we’d have to wait until around half past three in the afternoon.

To speed things up, we can delete this record from the database. First we find out the full ID:

 > exim_dumpdb /var/spool/exim4 retry | grep berlin.ciudad21.net
 T:berlin.ciudad21.net:80.38.36.154 113 65 No route to host

We then run the exim_fixdb and simply enter the ID returned from grep, and enter ‘d’ to delete the last entry found.

 > exim_fixdb /var/spool/exim4 retry
 Modifying Exim hints database /var/spool/exim4/db/retry
 > T:berlin.ciudad21.net:80.38.36.154
 03-May-2007 07:48:44
 0 error number: 113 No route to host
 1 extra data:   65
 2 first failed: 02-May-2007 15:57:24
 3 last try:     03-May-2007 07:48:44
 4 next try:     03-May-2007 15:24:21
 5 expired:      no
 > d
 deleted

A few moments after doing this, the server will be resolved correctly, and mail will start flowing as usual.

written by Sam,


Comments

2010-10-28 Andrew McCombe says:

Thanks!

We had a client who have an exchange server running from their office and their internet connection was down for a week. Exim had logged that this was the case and when the connection was back up it wouldn’t send.

Using the exim_fixdb from above resolved the issue.

2010-11-22 aminata graphiste says:

We implemented it on our clients sites, thank you!

http://www.graphic-instinct.com


Write your comment



HTML will be removed, but Textile formating is permitted. Log in for your comment to be posted without review.