[Short Tip] Debug Spamassassin within Amavisd

Filtering e-mail for spam and viruses can be done efficiently with Amavisd-New. Besides its own technologies to identify and filter out Spam it can also make use of Spamassassin and its results. However, since Amavisd starts Spamassassin itself, it sometimes is hard to debug when something is not working.

For example in a recent case I saw that the Bayes database was not used when checking for spam characteristics, although the database was properly trained with ham and spam.

Thus first I checked Spamassassin itself:

$ su -s /bin/bash mailuser -c "spamassassin -D -t < ExampleSpam.eml 2>&1"  | tee sa.out

That worked well, the Bayes database was queried, results were shown.

Next, I added $sa_debug = '1,all'; to the Amavisd configuration and run Amavisd in debug mode:

$ amavisd -c /etc/amavisd/amavisd.conf debug

And that showed the problem: one of the Bayes files had wrong permissions. After fixing those, the filter run again properly.

[Howto] Sending test mails with Swaks

Setting up e-mail servers can become a time consuming and complex task. Test mails can help verifying the functionality of the system – and here Swaks comes into play, the “swiss army knife for smtp”.

Swaks can be used to send test mails of all kinds. The advantage of Swaks compared to sending mails with your normal e-mail client is that you are able to alter almost any part of the e-mail: to, from, header, attachments, which server to speak to, etc.

Here are some common Swaks usage examples:

The first, basic example is sending a mail to your own server (here “bayz.de”):

$ swaks -f someone@example.net -t liquidat@example.com

If you need more recipients, add them via comma:

$ swaks -f someone@example.net -t liquidat@example.com,testme@example.com

It gets more interesting if you change the “TO” to another domain, but send the mail via the server for “bayz.de” nevertheless. If that works for arbitrary domains, and if the mails are forwarded to these you have big problem: an open relay.

$ swaks -f someone@example.net -t liquidat@example.com --server mail.example.com

Or do you need to know if a certain recipient is actually available?

$ swaks -f someone@example.net -t liquidat@example.com --quit-after RCPT

But you can also use Swaks to test a spam filter: If any of the bigger spam filters out there identifies the GTube sting in an e-mail, it will mark it as spam:

$ swaks -f someone@example.net -t liquidat@example.com --body /path/to/gtube/file

The same is true for anti virus programs and the Eicar file:

$ swaks -f someone@example.net -t liquidat@example.com --body /path/to/eicar/file

But Swaks can also be used to test user authentication and tls:

$ swaks -tls --server example.com -f liquidat@example.com -t someone@example.net  -ao --auth-user=liquidat

And this can of course be used to test authentication between servers:

$ swaks -tls -s example.com -f someone@example.net -t liquidat@example.com --ehlo $(host $(wget http://automation.whatismyip.com/n09230945.asp -O - -q))

The last bit makes sure your local test machine does provide a correct fqdn.

But in case your MTA setup does rely or use custom headers, how about adding some of these?

$ swaks -f someone@example.net -t liquidat@example.com --add-header "X-Custom-Header: Swaks-Tested"

If you have other interesting examples, don’t hesitate to drop them in the comments, I am happy to add them here.