19-10-2010, 10:03 AM
This article is presented by:Barry Leiba
IBM Research
Hawthorne, NY
Jim Fenton
Cisco
San Jose, CA
ABSTRACT
Email protocols were designed to be flexible and forgiving, designed in a day when Internet usage was a cooperative thing. A side effect of that is that they were not designed to provide protection against falsification of a message’s address of origin, referred to today as “spoofing”. DomainKeys Identified Mail (DKIM) defines a mechanism for using digital signatures on email at the domain level, allowing the receiving domain to confirm that mail came from the domain it claims to. In conjunction with the forthcoming DKIM sender signing practices specification, the receiving domain may also have more information for deciding how to treat mail without a valid signature. The use of DKIM signatures and signing practices gives sending domains one tool to help recipients identify legitimate messages from their domain, and a reliable identifier that can be used to combat spam and phishing.
INTRODUCTION
Early antispam filtering involved “blacklisting” the senders of spam – refusing to accept or deliver mail from email addresses known to send spam. Unfortunately, the Internet standards for email do not prevent the sender from lying about his identity, at the protocol level [8], in the mail “headers” [14], or both. This “spoofing”, as it’s called, not only allows spammers to get around email-address blacklists, but also to lend credibility to their messages by spoofing a reputable domain. Initially a way simply to convince recipients to open the messages, rather than to delete them, spoofing reputable domains has evolved into a con-game called “phishing”, resulting in estimated losses in 2004 of between one and two billion dollars [15],[9]. Clearly, something must be done to curtail spoofing; the ability to send messages while purporting to be another sender is in most cases undesirable. While curtailment will not stop phishing, and while spoofing cannot be stopped entirely without significant (and arguably undesirable) effects on Internet email as it is known today, making spoofing more difficult and providing domains with ways to protect their names and reputations are important steps against spam and phishing. There have been two broad mechanisms proposed for domain validation – verifying that mail did or did not come from the domain it claims to have come from. One uses IP address; the other uses digital signatures. In the former category are SPF (Sender Policy Framework [16]), and Sender ID [11], related techniques that differ in some details. CSV (Certified Sender Validation [4]) also falls into this category. In the second category are techniques that have the sender, or the sending domain, place a digital signature on the message. The signature can be verified later, by the recipient or by the receiving domain, and the verified signature can be used as evidence that the mail originated from where it says it does. The two categories each have advantages, and are not in competition. It is important to note, in this discussion, that the use of many techniques, together, is the most effective way to combat spam and related maladies (phishing, viruses and worms, and other malware distributed through email) [10]. Discussion of the advantages and disadvantages of the two categories is outside the scope of this paper, which will focus on the design and deployment of one particular specification: DomainKeys Identified Mail. The remainder of this paper will give an overview of DKIM, will discuss details of the mechanisms used and some of the choices made, and will show some practical deployment experience. 2 AN OVERVIEW OF DKIM
The concept behind DKIM is simple: If you receive a message from me bearing a valid digital signature, then you can be sure that it actually came from me. There are signature techniques already standardized for applying signatures to email, such as S/MIME [13] and OpenPGP [3], although the meaning of these signatures is subtly different from that of a DKIM signature.
For more information about this article,please follow the link:
http://citeseerx.ist.psu.edu/viewdoc/dow...1&type=pdf
IBM Research
Hawthorne, NY
Jim Fenton
Cisco
San Jose, CA
DomainKeys Identified Mail (DKIM):
Using Digital Signatures for Domain Verification
Using Digital Signatures for Domain Verification
ABSTRACT
Email protocols were designed to be flexible and forgiving, designed in a day when Internet usage was a cooperative thing. A side effect of that is that they were not designed to provide protection against falsification of a message’s address of origin, referred to today as “spoofing”. DomainKeys Identified Mail (DKIM) defines a mechanism for using digital signatures on email at the domain level, allowing the receiving domain to confirm that mail came from the domain it claims to. In conjunction with the forthcoming DKIM sender signing practices specification, the receiving domain may also have more information for deciding how to treat mail without a valid signature. The use of DKIM signatures and signing practices gives sending domains one tool to help recipients identify legitimate messages from their domain, and a reliable identifier that can be used to combat spam and phishing.
INTRODUCTION
Early antispam filtering involved “blacklisting” the senders of spam – refusing to accept or deliver mail from email addresses known to send spam. Unfortunately, the Internet standards for email do not prevent the sender from lying about his identity, at the protocol level [8], in the mail “headers” [14], or both. This “spoofing”, as it’s called, not only allows spammers to get around email-address blacklists, but also to lend credibility to their messages by spoofing a reputable domain. Initially a way simply to convince recipients to open the messages, rather than to delete them, spoofing reputable domains has evolved into a con-game called “phishing”, resulting in estimated losses in 2004 of between one and two billion dollars [15],[9]. Clearly, something must be done to curtail spoofing; the ability to send messages while purporting to be another sender is in most cases undesirable. While curtailment will not stop phishing, and while spoofing cannot be stopped entirely without significant (and arguably undesirable) effects on Internet email as it is known today, making spoofing more difficult and providing domains with ways to protect their names and reputations are important steps against spam and phishing. There have been two broad mechanisms proposed for domain validation – verifying that mail did or did not come from the domain it claims to have come from. One uses IP address; the other uses digital signatures. In the former category are SPF (Sender Policy Framework [16]), and Sender ID [11], related techniques that differ in some details. CSV (Certified Sender Validation [4]) also falls into this category. In the second category are techniques that have the sender, or the sending domain, place a digital signature on the message. The signature can be verified later, by the recipient or by the receiving domain, and the verified signature can be used as evidence that the mail originated from where it says it does. The two categories each have advantages, and are not in competition. It is important to note, in this discussion, that the use of many techniques, together, is the most effective way to combat spam and related maladies (phishing, viruses and worms, and other malware distributed through email) [10]. Discussion of the advantages and disadvantages of the two categories is outside the scope of this paper, which will focus on the design and deployment of one particular specification: DomainKeys Identified Mail. The remainder of this paper will give an overview of DKIM, will discuss details of the mechanisms used and some of the choices made, and will show some practical deployment experience. 2 AN OVERVIEW OF DKIM
The concept behind DKIM is simple: If you receive a message from me bearing a valid digital signature, then you can be sure that it actually came from me. There are signature techniques already standardized for applying signatures to email, such as S/MIME [13] and OpenPGP [3], although the meaning of these signatures is subtly different from that of a DKIM signature.
For more information about this article,please follow the link:
http://citeseerx.ist.psu.edu/viewdoc/dow...1&type=pdf