So what do we do when Exim blows a gasket? First thing I do is start looking at the configuration because most of the time it isn't Exim that blew the gasket... it was my fat fingers.

Here are a couple of things I ran accross.

So, your gazing at your logs as most admins do. Looking through the tea leaves trying to spot any evil that may be on the horizon when you notice this little tid bit...

lowest numbered MX record points to local host

What? You think to youself... does that mean. Clutching for the nearest search engine you look to see if someone else ran accross this same line.

Low and behold the search yeilds a drove of results.  Great! You exclaim. Let's see what the heck it is.  You click on the first link and someone is talking about a hostname missing in a file called localhostname or remote hostname or something like that.  So you check another one out. Then another.  They are all saying the same thing.  In fact, exactly the same thing.  As if they copied it from each other. Then you notice none of them actually identify the problem, just the fix. But the fix doesn't work?

Hummm.  Then what the heck does this mean.  Well the first thing it means is there is a lot of people writing about something they know nothing about! But we didn't need the web to find that out.

So... let's look at that line again.

lowest numbered MX record points to local host.

This line is telling you... you have a configuration error.  The MTA is trying to deliver a local message using a remote delivery method (transport). When is looks up the remote host in DNS, it's getting pointed back to itself.

In other words... if this message gets delivered, it's going to be received again because the remote host that would receive it is the localhost i.e. itself. If that happens the message is going to be delivered again... which means it's going to be received again... which means it's going to be delivered again... which means... get the picture? This line is a warning that an endless loop is starting.

How do you fix it? Look at the MTA's configuration. There is something a foul in one of the routers.  Hint: it's the router that would have handled the domain in the address it was processing when this line popped up. I've witnessed this line crop up when a Redirect router went a rye. But there could be a thousand causes. I would bet it's going to be somewhere in a router or transport. - Good luck!

First of all, in the exim world... tainted data is data coming in from the internet a.k.a the wild. So there is no telling what it could be and exim doesn't want to trust it and you shouldn't want to trust it either.

In this situation, what exim wants is clean data from a source that exim trusts like a lookup or a scrub with a perl regex to remove any unwanted character.

But, there is always a but. In the case of tainted mysql server, what exim wants is the server to be defined in the main config file, then that definition to be used elsewhere. This is because the username/password combo can be hidden from sticky fingers.

For example, somewhere in your exim config files you have something like this:

hide mysql_servers = \
   server1.example.com/dbuser/dbuserpassword : \
   server2.example.com/dbuser/dbuserpassword

Then later on, say in a router you are issuing a SQL statement...

${lookup \
   mysql{server1.example.com; \
      SELECT username \
      FROM users \
      WHERE username = $local_part \
   } \
   {1} \
   fail \
}

There are two things happening here to prevent exim from blowing a gasket. First the local_part has been sanatized because it is used in a lookup. Second the server is used from the previous server definition, not the definition itself with the username and password. That is where the tainted mysql server warning comes from.