David MacQuigg
Each of the competing methods has strengths and weaknesses and different features. No one method is the best in all situations, and it is quite likely that a good setup will require two methods with complementary features. All methods depend on the integrity of the Domain Name System ( DNS ) to provide trusted information on an Identity registered in that system.
Sender Policy
Framework (SPF) http://spf.pobox.com
SenderID http://www.microsoft.com/mscorp/twc/privacy/spam/senderid/default.mspx
Certified Server Validation (CSV) http://mipassoc.org/csv
DomainKeys/IIM http://mipassoc.org/mass/
These methods use a digital signature to authenticate both the Identity of the sender and the entire contents of a message. Digital signatures can provide an "end-to-end" authentication that works in spite of insecure forwarders in the middle. Verification of a signature with a public key proves that it was generated by someone with access to the matching private key.
Signature methods don't work if you need to reject forgeries before transferring any data. Thus they are not the best choice for forwarders who need to quickly reject spam and minimize network traffic. They are normally applied only at the final destination, where a little extra processing time doesn't matter.
Signature methods offer no protection against replay. A spammer need send only one message through a legitimate MTA to get its signature, then replay the signed message to millions of new recipients. Signatures may be the ultimate protection against forgery, but we still need IP-based authentication to stop spam.
Two signature methods, promoted by Yahoo and Cisco, now combined into one. The Identity to be checked, and the message signature, are added to the message headers. The public key is kept in DNS records at a secure location specified by the message header.
These methods depend on the integrity of the Internet Protocol ( IP ) address system and routing structure of the Internet. The IP Address of a Mail Transport Agent ( MTA ) is determined by the Source Address in the TCP/IP connection with that MTA. Corrupting Internet routing tables is much more difficult than faking headers in an email.
All methods check the DNS records for an Identity to verify that the Identity authorizes the use of a particular IP Address as a Public Mail Server. They differ in how this Identity is determined from the information in an email, and in providing other checks in addition to the authorization check.
This method assumes the MAIL FROM (envelope) address as the Identity to be checked. DNS records for that Identity are expected to authorize not only its own MTA's but those of any forwarder who may send email on its behalf.
The main disadvantages of this method are:
1) The insecurity which results from more than one sender using the same forwarder. If each authorizes the forwarder's server, they can forge each other's name, and the receiver cannot directly authenticate each sender.
2) The risk of DNS abuse. The complexities of the SPF syntax can result in many DNS queries for each message at each MTA.
Note: These disadvantages are not inherent in SPF. It can be used more conservatively, but we list them as disadvantages, because we have to consider the worst-case when dealing with possible abuse.
This method is very similar to SPF, but instead of checking an envelope address, it checks the identities in the message headers. This may be useful in thwarting phishing scams, where the header identities seen by the user differ from the envelope identities actually used by the mail system.
Checking header identities requires transfer of the message data, putting a greater burden on the mail system than methods working with just the envelope identities. Many feel that header inconsistencies should be checked at the receiving end, and that earlier MTAs should check only the envelope information.
Which header to use as the verified identity is selected by a patented algorithm (PRA). Controversial claims of broad patent rights over email authentication methods have delayed efforts to develop a universal standard, and caused resistance to adoption of Sender ID.
Sender ID uses SPF records, and has the same risk of DNS abuse as SPF. The re-use of SPF records is also controversial, as it may introduce confusion as to which identity is intended by the SPF record.
How well Sender ID will handle the forwarding problem is not clear at this time.
The focus of this method is on reducing network abuse. It assumes end-to-end validation will be done by another method, and avoids the problem of authenticating forwarders.
This method assumes the HELO name as the Identity to be checked. This name is required to be the actual name of the server sending the email, traceable via DNS. Where the other IP-authentication methods say only: "We authorize that server to send mail.", CSV says in addition: "That server is a machine in our domain.". Thus there is no temptation to authorize unknown servers.
CSV also encompasses a step that other methods ignore, efficiently checking the accreditation of an Identity once it has been authenticated. This may be important in a situation where spammers are generating huge volumes of unregistered Identities.
Although not near as bad as the worst-case SPF scenario, the
large number of authentication records might make this method vulnerable to a
DoS attack. Caching is less effective when each mail server needs a
unique record. See Spam Scenarios –
The focus of this method is the fastest possible reject of forgeries, and the minimum possible load on the network and DNS. It has a very simple syntax that allows a quick reject of any messages that don't have an IP address "close" to an authorized address. Depending on how a domain organizes its IP blocks, this quick check could be all that is necessary for an MTA. QR1 also provides for the use of other methods, should the quick check be inconclusive.
Like CSV, QR1 leaves to other methods the problem of end-to-end authentication. Like SPF, one DNS record can authorize all the servers for an entire domain. This consolidation of information can greatly reduce the DNS load and risk of abuse.
The simple syntax of QR1 does not have the capabilities of SPF for redirecting queries to other domains, including other records, or constructing entirely new queries using a "macro language". While no method can prevent sloppy setups, QR1 is somewhere between SPF and CSV in discouraging domain owners from authorizing unknown servers they really shouldn't trust.
=== End of File ===