Anti-spam measurements are working?

It has been a while, but it appears challenge-response spam filtering is back and now even more stupid.

If yes, it got caught as unsolicited email by our spam blocker. You can release the mail from spam quarantine by simply replying to this message. At the same time the spam blocker will recognize you as a trusted sender (from this email address) and automatically add you to my Allow list for this and any future communication.

Many illegal spammers forge email addresses to try to get past spam blocking software. These spammers send hundreds of millions of spam messages a day, clogging email servers and wasting people’s time. We regret that these spammers have forced us to send this message to you.

But why stupid? First of all no relevant data at all, only a source and target e-mailaddress and a company URL where you should be able to find how to clear it. Wasn’t able to find anything btw. When matching the timestamps it appears to be related to a posting I did on a mailinglist, a double opt-in mailinglist. And RFC 5230, section 4.6 has some nice hints for vacation responders that may also apply to these kind of spamfilters. Also my maildomain has a closed SPF-record in DNS, meaning you can identify if I’m really the sender. Which will not be the case as a mailinglist has a different return-path header. Also an indicator that the software isn’t using the right data from the headers.

Looking at the headers from their response it appears they know how to set an SPF record for their own domain, but validating incoming no. Also their software forgot to add a Date-field to the mail headers. For now I fed this e-mail from challenge@lightspeedsystems.com to the Bayesian filter and if it keeps coming back it will get it’s own line in my blacklist for SpamAssassin.

When do other banks start to publish SPF records?

In the past a lot of phishing was going towards customers of the Dutch bank Postbank. It continued for years and when the bank finally merged with ING the phishing attacks adopted the new name quickly. In both cases the bank was publishing closed SPF resource records in DNS so third party systems could determine of an e-mail really came from Postbank or ING. And with a few rules for SpamAssassin for example most of the phishing can be stopped.

The last months phishing attacks for both Rabobank and ABN Amro increased a lot. Most phishing e-mails from Rabobank are being caught by the bayesian filter for now, but for ABN Amro aren’t always detected. This makes me wonder why those banks don’t publish SPF resource records in DNS? Is it really that difficult? Or is the cost for fraude smaller, then for a denied e-mail?

SpamAssassin regels voor ING phishing

Was vroeger postbank.nl populair om bij gebruikers naar gegevens te hengelen, maar sinds de definitieve uitfasering in 2010 van het merk Postbank is de plaats ingenomen door ING. Heel toepasselijk waar alle klanten en diensten in zijn opgegaan en waar vroeger alleen postbank.nl een SPF-record in DNS had is dat nu ook zo voor oa ing.nl. En gelukkig worden veel berichten automatisch al als spam-gemarkeerd, maar niet alles helaas.

Om de laatste paar phishing e-mails voor ING als spam te laten markeren zijn voorlopig wat custom regels nodig voor SpamAssassin. Gelukkig is dat redelijk goed te doen met behulp van SPF en na al die jaren wordt toch langzaam duidelijk waar SPF en DKIM goed voor zijn. Wat wel opvallend is dat andere Nederlandse banken geen SPF-records publiceren in DNS zover te achter halen is. Dit terwijl de belastingdienst dit wel doet heel toepasselijk.

RFC 4408, vaarwel

RFC 4408, gaat over Sender Policy Framework voor wie hem niet direct herkende, is redelijk onmogelijk aan het worden. In de afgelopen jaren zijn veel records in DNS gezet als TXT resource record en later is er zelfs een eigen SPF resource record gekomen. Helaas gebruiken nog veel mensen de TXT variant, omdat mensen de records in DNS hebben gezet zonder te beseffen wat ze doen en ze ook niet te onderhouden.

Daarbij zijn er maar echt weinig partijen die ook daadwerkelijk zeggen dat hun record een -all geven om zo aan te geven dat de ontvanger de e-mail kan weigeren als het het niet matched tegen de regels in DNS. Misschien de bekendste partijen in Nederland zijn wel Postbank die door phishing aanvallen is gedwongen tot deze actie en de Belastingdienst. Buiten Nederlands blijven er alleen een paar open source communities over en het Duitse GMX, maar grotere partijen zoals Google en Microsoft blijven het alleen afdwingen voor inkomende berichten.

Sinds gisteravond 00h00 is er dus een einde gekomen aan een experiment dat sinds november 2006 liep. Er zal geen Received-SPF header meer worden toegevoegd door de mailservers. Hierdoor zullen e-mails gemiddeld 160 bytes kleiner worden en er zal per server een policy-server minder draaien. Alleen SpamAssassin blijft nog controleren wat ook zonder deze header kan en hiermee staan de SPF-checks bijna geheel op de automatisch-pilot door hun status binnen het SpamAssassin-project. Kortom, vaarwel RFC 4408 en gerelateerde RFCs.

DKIM verifiëren

DKIM aka DomainKeys Identified Mail is een alternatief op SPF aka Sender Policy Framework en hoewel het lastiger is op te zetten aan de verzenderkant is het wel goed te gebruiken als ontvanger. Zeker omdat oa grote partijen zoals Google en Yahoo het ook gebruiken om hun e-mail te versturen. Gelukkig zijn er ook steeds meer kleinere partijen die DKIM gebruiken.

Op Debian kan door het installeren van Mail::DKIM het oa worden gebruikt door SpamAssassin en Amavisd-new.

$ sudo apt-get install libmail-dkim-perl

Voor SpamAssassin om gebruik te maken van DKIM hoeft in het bestand /etc/spamassassin/v312.pre de volgende regel staan zonder #-teken ervoor.

loadplugin Mail::SpamAssassin::Plugin::DKIM

Je kan los een DKIM-proxy installeren om een header te laten toevoegen of de DKIM-signature voldoet, maar als je al al gebruikt maakt van Amavisd-new dan kan het al automatisch worden gedaan door Amavisd-new. Zorg dat in het bestand /etc/amavis/conf.d/50-user de volgende regel staan en herstart de daemon.

$enable_dkim_verification = 1;

Je zal nu zien dat de volgende regels zien verschijnen in /var/log/mail.log:

Dec 29 20:36:45 server amavis[7162]: Module Mail::DKIM 0.32
Dec 29 20:36:45 server amavis[7162]: DKIM code loaded

Als je bijvoorbeeld RoundCube gebruikt dat kan je met DKIM verification plugin de status automatisch laten weergegeven als de gebruiker zijn e-mail leest. Het zal je ook opvallen waar het voorlopig niet verstandig is om e-mail te rejecten op basis van een invalide DKIM signature. Bij sommige mailinglisten worden extra regels aan de body van de e-mail toegevoegd waardoor het signature niet meer valide is.