Exim ACL perl modules
On a mail server which hosts thousands of mails per any given day for thousands of customers, you have to have effective ways of dealing with spam, the bane of SMTP servers and mailboxes everywhere.
SpamAssassin is a great tool, but there is more that you can do. We've implemented a small perl module, which interfaces with a MySQL database, which implements Greylisting. You can check out this module HERE .
We implemented this module and it is incredibly effective. So much so, that we took the idea of implementing a few similar modules to do some other tasks. The perl module socket launcher we used is Alun Jones' original, just with a small modification to kick start our newer modules.
Credit has to go to Chibi, as it was his idea (due to his frustration with bounces and general disdain for customers and people in general) which lead to the scripts - and the resulting exim acl fragments which he did himself. With his vision and German domineering happy-slapping encourangement, we got the job done.
One of our ideas was to catch out INTERNAL spammers abusing our system. We have zero tolerance for paying customers who think they can get away with spamming from our mail servers. Not only do they take up system resources for other customers, but our mail servers (and indeed our very business) simply cannot afford to be blacklisted because of one or more spammers.
We found that spammers usually leave a trail of bounces behind in the log file, usually because they are spamming a whole list of people and many of the addresses in their lists are usually non-existant, OR they are simply running a dictionary attack in a blatant attempt to guess them. End result? A pile of bounces showing up in the log files for a particular user in a short space of time.
The only other reason to get many bounces in a short space of time is when some business customers send out legitimate mailing list messages - except that their lists are now full of non-existant mailboxes because they haven't updated their lists for a long time. At least now we can prompt them easily to update their mailing lists.
The solution we devised actually employs two scripts. The first "bouncewatcher" script runs as a cronjob (usually every 5 minutes), and trails the exim mainlog hunting for bounces. (I wish there was an easier way to detect bounces, but you only ever find out about them after they've spun around the queue for a while.) The bounces it picks up are recorded into a mysql database that you set up somewhere. (Check out the contents of the script to see how to set up the database table schema). It tries to grab the authenticated user, and if it can't, at least the sender. That way we have at least something to track.
The other script is essentially the perl module which exim employs to do a lookup on the database. When exim gets a new mail to process, the ACL will see if that authenticated user is in the database. If they are, their mail gets "special" treatment, usually a punishing mail delivery delay over a certain bounce threshold. Also, we keep an eye on bounce offenders and make moves to introduce LARTing on their accounts.
The bouncewatcher script relies on the logtail program, so make sure it's installed. The script will also delete old database entries which are older than the timeout threshold. By default, this is set at 24 hours (besides, any longer and the effectiveness of catching bouncy senders is diminished).
One other thing, the bouncewatcher script can scale. You can use it across multiple mail gateways, and as long as they all point to the same database, you'll be fine.
Download the Bouncelist script package HERE
While the Bouncelisting combo traps spammers with bad spam/mailing list, we decided to also do something about spammers who conduct dictionary attacks on our MX servers, hunting for user accounts to spam into our domain. This solution was much simpler to devise than the Bouncelisting, and the exim acl can be rewritten to hunt for just about any behaviour that it wants to punish users for. In our case, we wanted to punish senders by "tarpitting" them for every consecutive unrouteable address, by delaying their mail. Just like sticky tar, users who keep pushing their luck are slowed.. down.... until..... they....... can't .......... send............. mail.
What the module does is to record the IP address of the offender into a MySQL database, and if that IP address is not in our whitelist, we add the IP address and a timestamp to the database. Now, our whitelist comes from the whitelist results we have from the use of the Greylisting perl module, so if you aren't using Alun's Greylisting module, we recommend doing so. If you are not using a whitelist, you will have to configure the script to skip the whitelist check.
Database entries are purged after 4 hours or so, and this cleanup is activated by a cronjob which calls the cleanup sub of the Tarlist perlmodule. Make sure it's active otherwise your database will grow big enough to threaten small countries.
The Tarlist perl module can also scale effectively across mail gateways, although you may wish to call the Tarlist cleanup sub from the database server itself.
Download the Tarlist script package HERE