Removing SPF Resource Records

With the creation of RFC 4408 also new a record type 99 for DNS was created to identify SPF Resource Records. It was advised to have both TXT and SPF records in DNS with the same content.  RFC 4408 was obsoleted by RFC 7208 in 2014 with paragraph 3.1 stating the following:

SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only.  The character content of the record is encoded as [US-ASCII].  Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued.

Now that the SPF Resource Record has been discontinued for  a while, the time has come to remove it from DNS (if not done already) and make sure it never comes back. Luckily most code libaries already preferred the TXT variant, but still this is one to put on the maintenance checklist to remove it for any application code and/or infrastructure.

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 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 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 een SPF-record in DNS had is dat nu ook zo voor oa 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.