In a February 14, 2006 article, I described the new Goodmail CertifiedEmail solution. Goodmail provides a service to senders of marketing email that allows messages to bypass the normal spam filtering processes of email service providers like AOL. The sender is charged a fee. The objective of this for-fee service is to authenticate senders.
Sender ID is an free standard that also meets the objective of sender authentication. Developed by Microsoft, Sender ID is enjoying increasing acceptance by email and email filtering vendors. It also provides significant flexibility to receivers when making automated decisions about what to do with unauthenticated messages. In this article I examine the two primary contenders for email authentication standard, how Sender ID works, what senders must do to be considered “safe”, and what the emergence of this standard means to businesses and individuals.
What is User Authentication?
In today’s Internet messaging environment, it’s anybody’s guess what kinds of messages might attempt to gain entry into your network or PC. The dangers of email use range from infection with a harmless though frustrating virus to the theft of intellectual property and personal identities. The level of risk has risen so high that many Internet users are making the decision to either minimize email use or discontinue it completely. Last but not least is the never-ending flow of spam that clogs enterprise email systems and home mailboxes.
Email authentication helps protect users from these risks and frustrations associated with Internet email. Through the use of one of the two major contenders for an actual IETF standard, recipients of email can be reasonably protected from unwanted or malicious email.
There are two basic approaches to email authentication. The first is the use of DomainKeys (DKIM). Based on Yahoo!’s email authentication technology and Identified Internet Mail developed by Cisco, DKIM authentication is based on an asymmetric key methodology. A secure hash is calculated using the contents of the message to be sent. The hash value is encrypted using the sender’s private key. The resulting cipher text is added to the message header.
When the email is delivered, the recipient uses the name of the domain from which the message originated to perform a DNS lookup. The domain’s public key is returned, and the hash value is unencrypted. The receiving system then recalculates the hash and compares it’s result to the unencrypted result. If they’re the same the receiver can be certain that the message originated from the domain indicated in the message header, and that the message was not tampered with as it traveled over the Internet.
The second approach is the use of Sender ID. Sender ID, a combination of SPF and Microsoft’s ”caller ID,” is an extension of the SMTP protocol. The rest of this article is dedicated to describing this emerging email authentication standard.
The basic underlying functionality of the Sender ID method is a DNS lookup of the sending domain’s SPF record. The SPF (Sender Policy Framework) consists of a text DNS record located on the sending organization’s DNS server. The entry contains, at a minimum, the IP addresses of the servers authorized to send email on behalf of the sending domain. Let’s use Figure 1 (http://www.microsoft.com/mscorp/safety/technologies/senderid/technology.mspx?pf=true) to step through the message receiving process.
1. A message is sent to the receiver
2. The receiver’s inbound mail server receives the message
3. The inbound server obtains the name of the domain from which the message was supposedly sent. It uses this information to check the SPF record for that domain. If the sending IP address in the message matches any one of the outbound addresses included in the SPF record, the message is authenticated and delivered. If no address match is possible, authentication fails and the message is not delivered. Once the message is authenticated, the receiver can process the message based on sender specific rules.
The questions asked and acted upon by these rules might include:
1. Is the sender known to the receiver?
2. Does the sender have a history of sending legitimate email?
3. Is the sender a trusted entity?
In order to operate effectively in a Sender ID environment, senders will have to begin adding SPF records to their DNS servers. This process isn’t too bad. In fact, there are many sites where a domain owner can use a wizard to create the necessary SPF entry string. Although Sender ID is still moving through adoption and approval processes, it’s a good idea for senders to post a SPF record soon.
The following is a list of some of the organizations that have accepted and are implementing Sender ID in their products and services:
- Microsoft (Exchange Server 2003)
Email authentication is becoming a reality. Is it perfect? No. But it’s better than the chaos that pervades the messaging world today. It also doesn’t matter which standard wins out; they’re not mutually exclusive, and they can easily coexist. So don’t stand in a corner waiting for a winner. Anything you do today will work in the future. Just be sure to take the appropriate steps to protect your enterprise from the increasing risks of messaging.
Author: Tom Olzak