eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Editor’s Note: In this first installment of her three-part series on e-mail authentication, Knowledge Center contributor Ellen Siegel shares a comprehensive, high-level overview of e-mail authentication. In Part 2, Ellen delves into the functionality and implementation details of Sender Policy Framework (SPF) and Sender ID authentication. In Part 3, Ellen delves into the functionality and technical details of Domain Keys Identified Mail (DKIM).
E-mail authentication allows an organization that sends an e-mail to take responsibility for it; it associates a clear sender identity with each authenticated message that can be validated by the receiver. You can think of the authenticated identity as a driver’s license; it provides a reliable indicator of identity. Note that the responsible (authenticated) sender organization may not always be that of the author of the e-mail. Sometimes it may be an e-mail service provider (ESP) or a forwarding entity responsible for the transmission of the message.
This ability to perform identity validation wouldn’t be such an issue if e-mail was secure but, unfortunately, e-mail was not designed with security in mind (much like the postal mail service). In order to avoid any incompatibilities that would break existing e-mail deployments, e-mail authentication is designed and implemented as a set of extensions to the existing e-mail. This leaves individual deployments free to upgrade to the new capabilities on their own schedule.
The industry has converged on two basic approaches to authentication (and on two similar but distinct protocols for each approach). Sender Policy Framework (SPF) and Sender ID use a path-based approach that depends on the identity of the mail server that delivers the message to the receiver. Domain Keys Identified Mail (DKIM) and its precursor DomainKeys use end-to-end encryption.
Both approaches take advantage of the existing network infrastructure provided by the Domain Name Service (DNS) to publish authentication data. This works well because interaction with DNS is already an integral part of the e-mail transmission and delivery process.
Basic E-mail Authentication Flow
Basic e-mail authentication flow
The basic e-mail authentication flow is the same for both Sender ID and DKIM, with some minor differences in Steps 2, 3 and 4:
Step No. 1: The author composes a message and hits Send, which causes the message to be transmitted from the mail client to the sending mail server.
Step No. 2: The sending mail server identifies the recipient, processes the message, performs any necessary authentication, constructs the message headers and sends the message to the recipient’s mail server.
Step No. 3: The receiving mail server processes the incoming message. It then queries the sender’s DNS entry for any relevant authentication information.
Step No. 4: The receiving mail server uses the authentication information to validate the incoming message.
Step No. 5: The receiver’s back-end processing combines the results of the authentication with any relevant reputation data and content filtering to determine whether the message will be delivered to the recipient’s inbox, junk folder or whether it will be blocked completely.
Step No. 6: Finally, the recipient will be able to access the message the next time e-mail status is updated, assuming it has not been blocked.
Benefits of E-Mail Authentication
Benefits of e-mail authentication
Everyone has their own slant on the topic of e-mail authentication, but the bottom line is that it is good for everyone who cares about e-mail as a legitimate communication medium. It’s good for senders because it allows them to take clear responsibility for the e-mail they send, and it helps detect some types of forged e-mail claiming to come from their domains. From a sender’s perspective, the most immediate benefits of e-mail authentication today are the ability to reduce the incidence of certain types of forgeries and maintain their customers’ confidence in their e-mail (and in their company as a whole).
It’s good for recipients because it provides validated identities for which behavioral data, or reputation, can be collected. It also makes it easier for recipients to detect e-mail forgeries, which often come in the form of spoofing or phishing scams. For e-mail that is successfully authenticated, recipients have a verifiable identity for which they can build a reputation by collecting things such as incidence of bad addresses and complaint data from their customers. They can also augment their private reputation data by consulting with third-party reputation engines that monitor other aspects of sender behavior.
If authentication is your driver’s license, reputation is like your driving record: ISPs and other e-mail recipients can consult it to determine your delivery-much in the same way an insurance company would check your driving record to determine your rates. Reputation data provides a model of a sender’s behavior that, over time, becomes a fairly reliable predictor of future behavior. Thus, although spammers can also authenticate their mail, their bad reputations would rapidly ensure a negative impact on their future delivery.
It’s also good for recipients because they can have greater confidence that authenticated e-mail in their inboxes truly originates from the designated sender (that is, the designated sender is not forged). Recipients will also tend to have fewer legitimate messages that get lost in spam filters and fewer spam messages in their inboxes. They may also have a better experience in cases where authenticated mail from senders with good reputations gets special benefits (such as working links and images).
E-mail authentication is good for the industry in general. The E-mail Sender and Provider Coalition (ESPC) requires that its members-who represent a significant portion of the major ESPs-support e-mail authentication. In March 2008, the Messaging Anti-Abuse Working Group (MAAWG) published a white paper entitled “Trust in E-mail Begins with Authentication“, as well as a Sender Best Communications Practices document which strongly recommends that senders “adopt e-mail authentication for all types of messaging.”
Many senders also want to know how authenticated e-mail can help their delivery rates. This is a much more difficult question to answer. Because authenticated e-mail can help recipients filter out forged e-mail, and thus prevent some kinds of spoofing and phishing attacks, some recipients are already providing some small, positive weight in their filtering mechanisms for successfully authenticated e-mail. The effect is still fairly minor today, but most major ISPs are already supporting one or more authentication types. The weight given to authentication results will likely increase as authentication becomes more prevalent and as recipients build up their reputation databases for authenticated senders.
Conclusion
It’s important to note, though, that authentication alone is not a silver bullet. Just because you are authorized to send mail for a particular domain does not automatically mean that you are sending permission-based e-mail or that you’re not generating complaints from your recipients. The real long-term benefit of authentication is that it provides a verifiable identity to which recipients can attach reputation data. It’s the incorporation of that reputation data-that is, of the actual behavior of that verified identity over time-which should help stem the flood of spam, while enabling the vast majority of legitimate e-mails to be safely delivered to their intended recipients.
Editor’s Note: This was Ellen’s first installment of her three-part series on e-mail authentication, where she shared a comprehensive, high-level overview of e-mail authentication. In Part 2, Ellen delves into the functionality and implementation details of Sender Policy Framework (SPF) and Sender ID authentication. In Part 3, Ellen delves into the functionality and technical details of Domain Keys Identified Mail (DKIM).
Ellen is a board member and technical committee co-chair for the E-mail Sender and Provider Coalition (ESPC) and an active member of the Messaging Anti-Abuse Working Group (MAAWG). She can be reached at [email protected].