MAIL FROM vs From vs Sender – exploiting SPF

After 10 years of managing computer networks, I still learn something new almost every day. This week I inadvertently discovered that there were many more ways of “identifying” the sender of an e-mail that I had ever known (or in this case, of spoofing the sender an an e-mail).

Despite having multiple layers of SPAM protection, including strict SPF records and advanced content filtering, a particular set of SPAM was cleanly passing every layer of protection – this set of spam claimed, no less, to have originated internally (Clearly, this was not the case).

So, here’s how mail is identified:

A) MAIL FROM: (Also known as the envelope address)
B) Mail headers:
B1) From: (Generally what you see in your mail client)
B2) Sender:
B3) Reply-To: (Hitting “Reply” will usually go to this address)
B4) Resent-From:
B5) Resent-Sender:
B6) Resent-Reply-To:

The SPF specifications look explicitly at the envelope address; which is rarely ever seen by more than the e-mail relays. So, some clever spammer has been sending out a deluge of e-mail with forged mail headers that all match our own e-mail domain, but sending a different identity in the MAIL FROM – which conveniently passed SPF with flying colors. The e-mail client then looked at the forged headers, which contained our own (white listed) domain. The rest is history.

… or was, until I added a few lines of code to our mimedefang-filter. Any e-mails with headers claiming to be sent from our own domain are now cross-checked against the MAIL FROM:. If the domains don’t match; poof, the message is silently discarded.