Spoofing: are you who you say you are?

Just like regular mail, email has an envelope. The email envelope includes the sender’s address. Just like regular mail, the sender can write anything they want on the envelope, there is no verification. Even worse, in email a sender can include a human-friendly name that is displayed by the email client. (Oh, so that’s why my email application quarantine contains so many emails that appear to have been sent by myself!)

Spammers have pretty much free rein on what they put in the ‘From’, ‘Mail From’, ‘Reply-to’, ‘Sender’ and ‘Re-Sent-From’ fields. Most email clients will display the From field content, and may sometimes only display the friendly name used. You will not be surprised to find out that spammers do not include the real address in these fields. This is what is known as email or domain spoofing.

To our aid come a set of well-defined Internet Standards: Sender Policy Framework (SPF), Sender ID and Domain Keys Identified Mail (DKIM). Their goal is to let an email system detect spoofing and then have the system determine what the appropriate course of action is. This action may vary between something very strict, such as blocking the message (probably not a good idea), to something more moderate, like tagging the message for further scrutiny.

SPF and Sender ID are quite similar: they verify whether the incoming server IP address is allowed to send email from the reported domain. They request information from the domain which includes the IP addresses that are allowed to send email claiming to be from that domain. DKIM is a little more complex: each message is signed by a private key owned by the domain, while the domain also makes available a public key for decryption and verification. Since IP addresses are not involved, this verification can take place at any level, not just at the periphery.

Do these standards help block spam? Well, not quite. They help identify email and domain spoofing. It is up to an email system to determine how to treat these messages and use the information to contribute to a decision on whether the message is spam.

What’s the big deal then, couldn’t a spammer just spam from a domain with a valid SPF record? Well, yes, but that would also mean that the spamming domain would be clearly identified. This combined with a secondary tool like a reputation service or statistical content analysis of messages from that domain would result in identifying the spamming domain.

Some email systems give these standards a bad name, by routinely deleting the messages that do not comply. This is an extreme practice, and is not recommended by the standards. A better policy might be to view these in a more positive sense, and consider whitelisting verified mail from proven domains and IPs. Regardless, the best practice is without a doubt to use the anti-spoofing information in conjunction with other information to make a better decision.

Does your system use these standards? How does it use them? Do you find them effective, or more trouble than they are worth?