Subscribe to our Newsletter. The latest news and articles delivered to your Inbox!
Alexander Zammit has been developing server applications for over 15 years. Most of his works involve Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.
Since the release of SP2, Sender ID and SPF are in the limelight. But can't a spammer also publish an SPF record? And what happens when no SPF record is published?
SPF is not a new technology. Some anti-spam products have been supporting this for quite some time. SP2 now makes it available to the entire Exchange 2003 community, greatly broadening its reach.
This brings many newcomers who are eager to discover how to best harness its power. The classic newbie questions start to crop up. Some administrators are afraid of losing emails from senders who didn't publish an SPF record. Others believe that with Sender ID spam has its days counted. Yet others see little benefit once a spammer may also publish an SPF record. Today we put this technology into perspective. We go through some of the most classic questions in order to clarify the key benefits of this technology.
SPF stands for Sender Policy Framework and is a specification undergoing standardization. In very simple terms, SPF defines a mechanism to identify outbound email servers for a particular domain. This is done through the publication of a text record within DNS referred to as an SPF record.
Sender ID is an email authentication technology resulting from the merger of Caller ID and SPF. It provides a solution covering both sending and receiving ends. At the sending end, it makes use of SPF for identifying the legitimate sending hosts. At the receiving end, it covers the authentication procedure.
The receiving end authentication involves:
Extracting the email sender domain (this information may be spoofed).
Identifying the host from which the email originates.
Verifying if the host is allowed to send emails for the sender domain. This is where the SPF records, published by domain owners, close the circle.
The straight answer is YES. Spammers can (and do) acquire a new domain and publish an SPF record for it. They can then bombard the net with spam specifying their own sender domain. In this case, Sender ID checking will simply authenticate the sender as legitimate.
The above may easily lead one to believe Sender ID to be useless. This is not true. It is just a matter of understanding the scope of this technology and its role in combating spam and other email borne threats.
Sender ID has a very specific task to perform. It determines whether the sender information seen at the receiving end is true. In other terms Sender ID is primarily an anti-spoofing technology. If a spammer is not using spoofing then it is not the competence of Sender ID to trap.
In a previous article,
I looked at one of the recent phishing scams targeting eBay clients. In that case, the scammers spoofed the sender information in order to deceive their victim (i.e. sender address ended with @ebay.com). Now with SPF configured at the eBAY DNS and Sender ID setup at the receiving Exchange server, such an email could have been filtered.
Spoofing is one important trick in the hands of spammers. Disarming them from this weapon is an important step forward.
The Exchange 2003 implementation of Sender ID is very conservative. It only filters (deletes or rejects) emails where the sender is clearly spoofed. If an SPF record is unavailable email authentication cannot be performed. Thus Sender ID leaves the email through.
Sender ID may also be configured to always accept emails. In this mode it is combined with the Intelligent Message Filter for its final email classification and handling. This combination strengthens IMF and enables organizations to route spoofed emails to the Junk Email folder rather than blocking them at the server.
Yes it works. Publishing an SPF record is useful in order to protect your domain from being spoofed. Still this is not required in order to deploy Sender ID. The Exchange Sender ID implementation is only concerned with the authentication process performed at the receiving end.
Publishing an SPF record involves:
Creating the necessary text as specified by the SPF specifications.
Publishing it at the DNS server.
The first step is likely to pose the biggest challenge for a newcomer. Still today with the available online wizards this is easy to do. Microsoft is sponsoring http://www.anti-spamtools.org/ for this purpose. From here you can construct an SPF record with minimal knowledge of the specifications.
Sender ID Framework Overview
Sender Policy Framework
Making Sender ID a De Facto Standard
On-line SPF Record Generation Tool
Add New Comment...