[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] Sort spam mails to the junk folder in Zarafa

Groupware setups like Zarafa often leave the spam scanning to external tools – but still has to sort the tagged mails. This article shows two ways of sorting and filtering tagged spam mails in Zarafa.

Imagine the pretty common setup where the actual spam filtering is done on a separate MTA. In such cases the spam is scanned and tagged, but the groupware system, here Zarafa, has to sort the mail to the appropriate folders. For example, an e-mail header spam tag created by Spamassassin looks like:

X-Spam-Flag: YES
X-Spam-Score: 64.448
X-Spam-Level: ****************************************************************
X-Spam-Status: Yes, score=64.448 tagged_above=-999 required=6.2
	tests=[ADVANCE_FEE_2_NEW_MONEY=0.992, ADVANCE_FEE_3_NEW=2.734,
	ADVANCE_FEE_3_NEW_MONEY=0.001, ADVANCE_FEE_4_NEW=0.001,
	ADVANCE_FEE_4_NEW [...]

The question is how the groupware can auto-sort such mails – Zarafa knows (at least) two ways to accomplish that aim.

The first is to use Procmail, Maildrop or similar tools to check the mails for such tags: all mails are delivered from the separate MTA to Procmail, which forwards all mails to the zarafa-dagent. However, while normal mails are just forwarded to the normal zarafa-dagent without any options, spam mails are forwarded with the option zarafa-dagent -j. That way, zarafa-dagent knows that the mails are spam, and sorts them into the Junk folders. The Procmail configuration for that is for example:

:0 w
* ^X-Spam-Flag: YES
| /usr/bin/zarafa-dagent -j $1
EXITCODE=$?

:0 w
| /usr/bin/zarafa-dagent $1
EXITCODE=$?

The second way – which I prefer – is to tell zarafa-dagent to look for the spam tag itself. The Dagent can be configured to search for a spam tag flag sorting these mails into the Junk folder automatically. The configuration is done in /etc/zarafa/dagent.cfg:

spam_header_name = X-Spam-Flag
spam_header_value = yes

Please note that the values are case-insensitive.

Which method you use highly depends on your actual groupware setup: in case you already have a Procmail/Maildrop/Whatnot setup you might want to use the first method since it can easily be integrated with the existing setup. In case you do not have or do not want to introduce another layer like Procmail, you should go with the latter method. Also, the latter method is independent of the rest of the setup – so even with a working Procmail setup you might want to use the latter method to have it out of your mind.

[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.