After a challenging week working with a client who had been badly hit by backscatter spam, which occurs when a spammer sends messages to invalid recipient addresses, I got the impression that not enough IT administrators know about the various initiatives that exist to try and combat email abuse. I decided an article looking at email authentication may help those of you tasked with managing your organisation's mail servers.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The arms race between spammers and the rest of us is currently being won by the spammers. According to a report carried out by Symantec Corp., unsolicited email made up 90.4% of messages on corporate networks in April this year.
The problem of email abuse all stems from the fact that SMTP, the TCP/IP protocol used in sending and receiving email, was designed in the early 1980s and provided for no formal verification of the sender.
Therefore, most efforts for spam prevention have focused on trying to detect it by analysing the message's content. Any defence based on a heuristic approach, which involves the detection of known sources, commonly used text phrases and transmission patterns, will only result in an ongoing arms race as spammers find ways to avoid the latest blacklisting and content filters.
There have been attempts to prevent spam through various laws. Sending spam or hiring someone to send it for you is illegal in many countries. In the European Union, the Privacy and Electronic Communications (EC Directive) Regulations 2003 forbid unsolicited emails to an individual subscriber unless prior permission has been obtained or unless there is a previous relationship between the parties. In the U.K., the Information Commissioner's Office is responsible for implementing these regulations, which can be enforced against an offending company or individual anywhere in the European Union. In the U.S., spam violates the CAN-SPAM Act of 2003 as does using false or misleading header information. Sadly spammers pay little regard to these laws.
A tactic that spammers often use to avoid being identified is email spoofing. The technique entails altering the email header so the message appears to have originated from one domain or source, but has, in fact, actually been sent from another. To try and combat this type of abuse, the Internet community has turned to email authentication. The basic objective is to provide enough verifiable information so that recipients can determine the validity of the sender's identity. The idea is very different from content filtering where one man's spam may be another's anxiously awaited message.
At present there are three major email authentication standards aimed at combating email forgery:
Sender Policy Framework (SPF)
SPF is used by many email providers, such as AOL, Google and Hotmail. The Sender Policy Framework basically offers a reverse mail exchange (MX) record in the domain name system (DNS), specifying which machines are authorised to send mail from the domain. Each domain that participates offers a description of their particular mail, including those authorized to send messages, and that information is represented in an SPF record, which is also published in DNS records. When a mail server receives an email, it can use these records to confirm the sending server is authorised to send it on behalf of that address.
The arrangement obviously requires everyone to create SPF records for their domains so that all senders can be verified. Unfortunately, many domains have a weak implementation of SPF in their published records, reducing its overall effectiveness. Interestingly, according to a study from CipherTrust Inc., when SPF was first introduced, spammers adopted it faster than most legitimate emailers, because if you comply with the protocol by not spoofing the sender address, messages don't get stopped by SPF.
Sender ID is a combination of Microsoft's Caller ID for Email and SPF and addresses the same problem: email forging. Using Sender ID, a mail server determines if the sender server's IP address matches that of its DNS record. The authentication protocol requires SPF in order to work and is a higher level protocol, validating different header fields. Since this a Microsoft-led initiative, Hotmail and Windows Live Mail are the largest users of this type of authentication.
DomainKeys and DomainKeys Identified Mail (DKIM)
DomainKeys and DKIM work a bit differently than SPF and Sender ID, using public-key cryptography as part of its authentication process. Although it can't reject a message until the whole body has been received, it is possibly the fastest growing of the three major standards. Yahoo is responsible for developing DomainKeys and is the largest email provider using it -- Gmail, AOL and Earthlink are some of the other big users.
Email authentication and a multi-layered approach
Email authentication is certainly a necessary component in a multi-layered approach to combating spoofing and phishing attacks. However, a valid identity by itself doesn't guarantee the message isn't spam, so mail servers still need to apply conventional content filters and consider past behaviour, traffic patterns and sender reputation when determining whether to deliver mail to the recipient or not.
As email authentication becomes more widely adopted, reputation services will be better placed to take the sender's identity and check it against a database of their sending practices, scanning for bounce rates, user complaints and unsubscribe practices. However, defenses that block email based on reputation call for subjective analysis, and they are always going to be a contentious process, loaded with technical, administrative and legal problems.
So if you are responsible for your organisation's mail servers, make sure you are up to speed on these different email authentication methodologies and correctly implement one or more of them to help in the global fight against email abuse. I would also suggest flagging unauthenticated mail to your users as potentially risky.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.