PayPal recently detailed an aggressive plan to help eradicate spam and phishing attacks. And it's no wonder, since PayPal is one of the most targeted companies when it comes to phishing attacks. The company's plan to delete phishing attacks permanently from the world's inboxes is multi-pronged. It includes, as it should, layers of law enforcement, better authentication technologies, shutting down phishing sites, and increasing customer awareness.
In this column, we'll focus on two of the signing technologies the company plans to use to improve sent email authentication: Sender Policy Framework, SPF, and DomainKeys. In effect, these would allow ISPs to drop each email that isn't verified to be from PayPal, or any other common phishing target for that matter.
These are not entirely new technologies. Yahoo!, Google, Microsoft, and AOL have been using SPF and DomainKeys for some time. PayPal claims to have blocked 50 million phishing-related emails since October, while using DomainKeys in partnership with Yahoo!.
Both SPF and DomainKeys aim to stop phishing -- and even simply unwanted Spam -- in slightly different ways. Most everyone is aware of how easily the “From” address in an email can be forged — and SPF prevents spammers from being able to forge the domain names in this way. However, while it allows an administrator of an Internet domain to specify which machines are authorized to transmit email from that domain, a spammer who legitimately has an account in that domain, or is the owner of the domain, still can send email.
SPF operates at the level of the Simple Mail Transfer Protocol (SMTP) of a mail transaction, and requires three pieces of information:
- The MAIL FROM: parameter of the incoming mail
- The HELO or EHLO parameter of the sending SMTP server
- The IP address of the sending SMTP server
At the heart of SPF is the Domain Name Service (DNS), which is used to resolve the domain names typed in browsers to the numeric addresses understood by the infrastructure of the Internet. DNS also is used to direct requests for other services, such as email. For every domain, there must be a Mail Exchanger (MX) record, which tells the email sender the location of the target server that is to receive email. SPF publishes "reverse MX" records in DNS, which tells the email sender which machines can send mail from the domain. As a result, the recipient of the email now can check these records to ensure that the email is, in fact, coming from a “trusted” sender of that domain.
While DomainKeys is a method of email authentication, it does not prevent abusive behavior, though it does make it possible to track misuse of the email system more easily. In fact, DomainKeys offers near end-to-end integrity from the signing of an email to a verifying Mail Transfer Agent (MTA). In most cases, the signing MTA acts on behalf of the sender and the verifying MTA on behalf of the receiver.
Unlike SPF, DomainKeys operates on transported mail data, header, and body, independent of the Simple Mail Transfer Protocol (SMTP) envelope. It works by adding a header named "DomainKey-Signature" that contains a digital signature of the contents of the mail message. The receiving SMTP server then uses the name of the domain from which the mail originated, the string _domainkey, and a selector from the header to perform a DNS lookup.
Both SPF and DomainKeys have their shortcomings. For instance, SPF breaks SMTP forwarding in which an MTA forwards email to someone else without changing the "from" address. But there is a solution to this problem: a technique called Sender Rewriting Scheme (SRS) that rewrites sender addresses when mail is forwarded in that way. Also, DomainKey signatures can be broken if the message is modified significantly en route by a forwarding mechanism such as a list server.
These are interesting technologies, but for them to work en masse, many parties (and technologies) will have to interact with them, such as the MTA for both senders and receivers, and in some cases the DNS administrator. One thing is clear: deployment of these technologies could go a long way to increasing trust in email, and certainly would help reduce spam from its current level of 70 percent of all email traffic.
