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.
4 responses to “MAIL FROM vs From vs Sender – exploiting SPF”
You have raised a very interesting point, and something I would love to discuss further with you. I am having exactly this problem to figure out how to legitimately send emails from a webserver on behalf of someone else. Given someone who has put in restrictions such as you have, I can’t see any valid way.
For example, I have a website http://www.website.com that will send an email to an individual on your behalf (your_behalf@email.com) when you click on a particular button.
So if I simply put the From: as your_behalf@email.com and specify the sender as being webemail@website.com, by default the mail server will use the From: as the envelope address (MAIL FROM). This obviously will fail on SPF check as an SPF record for email.com will show that they are not permitted from website.com mailserver. So the next bet would be to modify the envelope address to be from webemail@website.com.
So now we’re at the stage where you have the following that should pass SPF:
MAIL FROM: webemail@website.com
From: your_behalf@email.com
Sender: webemail@website.com
However, based on your additional filtering, this type of email would be rejected.
Any ideas, thoughts, and/or suggestions how to accomplish this “legally”?
If you want, you can email me directly as well.
Thanks,
Eric
Hi Eric,
Thanks for the note. It did bring up some good points.
In the context of my filtering solution, note that I discard messages
only from the business domain where the MAIL FROM and From: header
don’t match. As the sysadmin for the company, I can vouch for the
fact that they use only the internal e-mail system. I can’t guarantee
what other companies are doing, so messages from all other domains are
filtered according to standard RFC4408. So, in your case, your message
would get through just fine, unless you were sending mail To:
ourcompany.com using a From: ourcompany.com, which simply should not
be taking place.
I think the first question that comes to mind is *why* you would need
to send an e-mail on behalf of another user on another domain? If you
consider that the administrator of a domain has put strict SPF records
on a domain, then chances are good that implies that they don’t want
servers sending e-mail for their domain other than the ones they have
allowed in the SPF records.
Using your example, I don’t understand why website.com can’t simply
send out an e-mail with something like the following:
From: “Website on behalf of John Doe”
Reply-To: john_doe@company.com
The above example is perfectly conforming to RFC822, breaks no rules,
and makes no presumptions to be someone it’s not.
If, for some reason, the business purposes of John Doe absolutely
required that he send e-mail via website.com as john_doe@company.com,
then it should be a trivial matter for John Doe to get his systems
administrator to add company.com’s mail relays his spf records.
I’d love to continue this discussion if the above doesn’t help. Just
let me know.
Sincerely,
-Mathew Eis
Nice, and old article.
Now we have DMARC does the exact same job for you. Only 7-8 years later 😀
Note for people stumbling on this page still… in response to ZUL, the last comment, DMARC is just a combination of SPF and DKIM with another configurable policy. It works IN ADDITION to everything mentioned in this article, not as an alternative.