Spamassassin – Frank Leonhardt's Blog

Reply-To: gmail spam and Spamassassin

Over the last few months I’ve noticed huge increase is spam with a “Reply To:” field set to a gmail address. What the miscreants are doing is hijacking a legitimate mail server (usually a Microsoft one) and pumping out spam advertising a service of some kind. These missives only work if the mark is able to reply, and as even a Microsoft server will be locked down sooner or later, so they’ll never get the reply.

The reason for sending this way is, of course, spam from a legitimate mail server isn’t going to be blacklisted or blocked. SPF and other flags will be good. So these spams are likely to land in inboxes, and a few marks will reply based on the law of numbers.

To get the reply they’re using the email “Reply-To:” field, which will direct the reply to an alternative address – one which Google is happy to supply them for nothing.

The obvious way of detecting this would be to examine the Reply-To: field, and if it’s gmail whereas the original sender isn’t, flag it as highly suspect.

I was about to write a Spamassassin rule to do just this, when I discovered there is one already – and it’s always been there. The original idea came from Henrik Krohns in 2009, but it’s time has now definitely arrived. However, in a default install, it’s not enabled – and for a good reason (see later). The rule you want is FREEMAIL_FORGED_REPLYTO, and it’s found in 20_freemail.cf

Enabling FREEMAIL_FORGED_REPLYTO in Spamassassin

If you check 20_freemail.cf you’ll see the rules require Mail::SpamAssassin::Plugin::FreeMail, The FreeMail.pm plugin is part of the standard install, but it’s very likely disabled. To enable this (or any other plugin) edit the init.pre file in /usr/local/etc/mail/spamassassin/ Just add the following to the end of the file:

# Freemail checks
#
loadplugin Mail::SpamAssassin::Plugin::FreeMail FreeMail.pm

You’ll then need to add a list of what you consider to be freemail accounts in your local.cf (/usr/local/etc/mail/spamassassin/local.cf). As an example:

freemail_domains aol.* gmail.* gmail.*.* outlook.com hotmail.* hotmail.*.*

Note the use of ‘*’ as a wildcard. ‘?’ matches a single character, but neither match a ‘.’. It’s not a regex! There’s also a local.cf setting “freemail_whitelist”, and other things documented in FreeMail.pm.

Then restart spamd (FreeBSD: service spamd restart) and you’re away. Except…

The problem with this Rule

If you look at 20_freemail.cf you’ll see the weighting is very low (currently 0.1). If this is such a good rule, why so little? The fact is that there’s a lot of spam appearing in this form, and it’s the best heuristic for detecting it, but it’s also going to lead to false positives in some cases.

Consider those silly “contact forms” beloved by PHP Web Developers. They send an email from a web server but with a “faked” reply address to the person filling in the form. This becomes indistinguishable from the heuristic used to spot the spammers.

If you know this is going to happen you can, of course add an exception. You can even have the web site use a local submission port and send it to a local mailbox without filtering. But in a commercial hosting environment this gets a bit complicated – you don’t know what Web Developers are doing. (How could you? They often don’t).

If you have control over your users, it’s probably safe to up the weighting. I’d say 3.0 is a good starting point. But it may be safer to leave it at 0.1 and examine the results for what would have been false positives.

19-October-1520-October-15

New botnet spammed malware – Peals.F!plock

This is a big one, coming from hitherto unlisted botnet addresses – and it’s coming right now. I’m cross referencing the blacklisted addresses now to see if I can see who’s had an expansion lately. Spamassassin isn’t that great at picking it up, with about 10% getting straight through and about 90% failing to reach five points.

It’s a Microsoft Word document, apparently containing controversial malware Peals.F!plock. Little is known about this, other than Security Essentials flagging it but others say it’s a false positive. Well someone’s gone to a lot of trouble to sent it a “false positive”.

The messages all claim to come from “Stephanie Greaves”, sgreaves at btros.co.uk, with a fixed subject of COS007202, which is unusual. You’d have thought that if you’re using a clean botnet you’d randomise things a bit. This is a genuine domain name (with no SPF – come on guys!) and for all I know, Stephanie Greaves is the name of a genuine victim. Their MX is a virtual server and they’re probably wondering why it’s been heavily loaded since 9am.

Whoever’s doing this has a pretty comprehensive spamming list, containing nearly all of my honeypots.

Update:

This same malware is now being sent out claiming to be from customerservices@ocado.com with the subject “Your receipt for today’s Ocado delivery”, and an HTML message looking like an Ocado receipt (as far as I can tell – I shop for my own groceries!) Again, Ocado doesn’t seem to have SPF set up.

The message text is:

HERE’S YOUR RECEIPT

Hello

Your receipt for today’s delivery is attached to this email. I’ll be delivering your 12:00-14:00 order and, so you’ll know it’s me, I’ll be driving the Lemon van.

Your order doesn’t have any substitutions, everything’s there.

See you later,

Paul

The fake bombardier one reads:

Good morning,
Please see attached purchase order.
Kind regards,
Stephanie Greaves
cid:image002.jpg@01D01077.BAC48BA0
Administration Apprentice
Bombardier Transportation (Rolling Stock) UK Ltd
Electronics, Cabling, & Interior Division
Litchurch Lane, Derby, DE24 8AD

Update: 20-Oct-15 11:22

The malware spam now looks like this:

From: Shaun Buzzard <shaunb@hubbardproducts.com>
To: <to_addr}}>  <-- Note error
Subject: Order

Hi ,

Please find attached order.

Kind regards.

Shaun Buzzard

23-June-1523-June-15

Spam From Amazon SES

Spam has always been a problem with Amazon’s email service (SES). They make an effort to filter the outgoing missives transmitted by their customers, but it’s not perfect. And Amazon is no respecter of laws outside the good ‘ol US of A, where the right to free speech is a license to spam any kind of junk you like; whether the recipient asked for it or not.

Here’s a case in point:

Received: from a8-55.smtp-out.amazonses.com (a8-55.smtp-out.amazonses.com [54.240.8.55])
	by xxx.xxx.xxx.uk (8.14.4/8.14.4) with ESMTP id t5NHpefn075543
	for <spambait@xxx.xxx.uk>; Tue, 23 Jun 2015 18:51:40 +0100 (BST)
	(envelope-from 0000014e218bf8a9-07659756-debc-452c-9a9f-1b0ecedf709d-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1435081898;
	h=From:Date:To:MIME-Version:Message-ID:Reply-to:Subject:Content-Type:Feedback-ID;
	bh=jCdtb+gUf4FAvUudtcIKxlX0IOnQHEd/YxIGxHXLcQ4=;
	b=cNIs7cNe5LzyxYvGWw/LdIeA7epknAFAoeQYjiyf9b5mTKRYLAW9KLvUTSGtlsr7
	WWy52wd3Tz9o9vQryvK/Q5l5okAFxgZCZa5uSbXMor7sa/1dU02kwjCyACnb7viR1np
	BlEytfbGEBUlAfBBrrJueagmdzwa+IXNZsBo4w2Y=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=lfgclj2zbjygv5i5rirpal2v2zj3dquy; d=uebaps.com; t=1435081898;
	h=From:Date:To:MIME-Version:Message-ID:Reply-to:Subject:Content-Type;
	bh=jCdtb+gUf4FAvUudtcIKxlX0IOnQHEd/YxIGxHXLcQ4=;
	b=bZZSEICBkHU8HkdFtiYg9fp+qxzmxJlfNj6UclS3B4dtaKBMTf1oSCSQR5jm0XXE
	0JxmIdNWKsgumLUcf8XnZGZFVfwe2f7cVOCiA1EcHX7oHn0weHQjoce+nxwVClgCQYz
	m0OlXn/YvNBE1MwSvpQR3PfoSCyTVQQpBWjgD8dQ=
From: Ray-Ban Sale <enews@uebaps.com>
Date: Tue, 23 Jun 2015 17:51:38 +0000
To: "spambait@xxx.xx.uk" <spambait@xxx.xx.uk>
X-MessageID: OXx8fHwxMzY3MXx8fHxmcmFuazJAZmpsLmNvLnVrfHx8fDEwfHx8fDF8fHx8MA%3D%3D MIME-Version: 1.0
Message-ID: <0000014e218bf8a9-07659756-debc-452c-9a9f-1b0ecedf709d-000000@email.amazonses.com>
X-Priority: 3
Reply-to: Ray-Ban Sale <enews@uebaps.com>
Subject: Spambait: Keep Calm and Get 80% Off Ray-Ban!
Content-Type: multipart/alternative; boundary="b1_b18fea4f74280e521923210f4d5c61eb"
X-SES-Outgoing: 2015.06.23-54.240.8.55
Feedback-ID: 1.us-east-1.E00ipiLUCdDBKP1kTeYjtCc2E2c3DbfGjCtoi1emL2E=:AmazonSES 
--b1_b18fea4f74280e521923210f4d5c61eb
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: base64
SGksRnJhbmsgTGVvbmhhcmR0OiAjUl9Ub3BfVGl0bGUjLg0KQm9ybiBmcm9tIGEgbWVzaCBiZXR3
ZWVuIHR3byBvZiBSYXktQmFuJ3MgbW9zdCBpY29uaWMgYW5kIHBvcHVsYXIgc3VuZ2xhc3NlcyAt
IHRoZSBDbHVibWFzdGVyIGFuZCBXYXlmYXJlciAtIFJheS1CYW5DbHVibWFzdGVyIE92ZXJzaXpl

As you can see (if you’re used to reading email headers), this looks very legitimate – send from a correctly configured server. However. these characters are as guilty has hell. The email body, once decoded, claims that the spambait email address belonged to a past customer of theirs, and was used for placing an order (in the USA). This is, of course, physically impossible.

If this had been sent in Europe they’d have been breaking the local law that implemented the EU Privacy and Electronic Communications Directive, 2002. But they’re sending it from the USA. Other text in the email suggests it’s not from an English-speaking country (not even the USA), and it’s probably a scam. But Amazon doesn’t t seem to mind – they don’t even have an abuse reporting system for ISPs plagued by this stuff.

It’s tempting to simply block all Amazon SES IP addresses, but this will cause collateral damage. Spam filtering isn’t likely to detect it any other way, as the sending server is set up correctly, with SPF records and so on, so the Bayesian filter in a spam classifier will be over-ruled. However, this correctness can be used against it…

Let’s be clear here – it’s easy enough to block the whole of SES. You can get its address range just by looking at it’s SPF records:

%nslookup
> set type=TXT
> amazonses.com
Server: 127.0.0.1
Address: 127.0.0.1#53
amazonses.com text = "v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 -all"

I suspect this may cover more than SES, but SES is certainly covered by it. However, blocking it will, as I mentioned earlier, block some innocent stuff that you do want. This is a job for Spamassassin.

I’m experimenting by adding the following to SA’s local.cf file:

header AMAZON_SES Received =~ /amazonses.com/
score AMAZON_SES 3.5
describe AMAZON_SES Sent from Amazon SES - often used by spammers

The the appropriate score to weight it by is an interesting question. By default good SPF records are ignored anyway; if they were not then it would obviously be a good idea to negate a positive score here. So I’ve picked 3.5 as this matches a clear Bayesian score rather than for any good statistical reason. Check back later to see how well it works.

29-August-1114-February-13

Spamassassin, spamd, FreeBSD and “autolearn: unavailable”

I recently built a mail server using FreeBSD 8.2 and compiled spamassassin from the current ports collection, to run globally. spamd looked okay and it was adding headers, but after a while I noticed the Baysian filtering didn’t seem to be working in spite of it having had enough samples through.

A closer look at the added headers showed “autolearn: no”, or “autolearn: unavailable” but never “autolearn: ham/spam”.

What was going on? RTFM and you’ll see spamassassin 3.0 and onwards has added three new autolearn return codes: disabled, failed and unavailable. The first two are pretty self-explanatory: either you’d set bayes_auto_learn 0 in the config file or there was some kind of error thrown up by the script. But I was getting the last one:

unavailable: autolearning not completed for any reason not covered above. It could be the message was already learned.

I knew perfectly well that the messages hadn’t already been learned, so was left with “any reason not covered by the above”. Unfortunately “the above” seemed to cover all bases already. There wasn’t any clue in /var/maillog or anywhere else likely.

I don’t much care for perl scripts, especially those that don’t work, so after an unpleasant rummage I discovered the problem. Simply put, it couldn’t access its database due to file permissions.

The files you need to sort are at /root/.spamassassin/bayes_* – only root will be able to write to them, not spamd – so a chmod is in order.

A better solution is to move the Bayesian database out of /root – /var would probably be more appropriate. You can achieve this by adding something like this to /etc/spamd.cf (which should link to /usr/local/etc/mail/spamassassin/local.cf):

bayes_path /var/spamassassin/bayes/bayes bayes_file_mode 0666

I suspect that the lower-security Linux implementation avoids these problems by setting group-write-access as default, but FreeBSD, being a server OS, doesn’t. It’s also a bug in the error handling for the milter – it should clearly report as a “failed” and write something to the log file to tell you why.

You should be able to restart spamd after the edit with /usr/local/sbin/spamdreload, but to be on the safe side I use the following after shutting down Sendmail first.

/usr/local/etc/rc.d/spamass-milter restart /usr/local/etc/rc.d/sa-spamd/restart

I don’t know if Sendmail can cope well with having spamass-milter unavailable, but why take the risk?