Although legitimate emailers are starting to quickly adopt SPF, apparently spammers are adopting it faster. A recent study by CipherTrust (www.ciphertrust.com) showed that 34% more spam is bypassing SPF checks than legitimate email. This means that a spam message is three times more likely to pass an SPF check than to fail it, as long as the address is registered. As long as spammers comply with the protocol, register their SPF records, and don’t spoof the sender address, their messages will not be stopped. What this really means is that one email authentication solution alone will not stop the tide of spam; it’s just one part of a fraud and spam prevention program.
Unfortunately, several major issues arose during the operation of the Sender ID working group, MTA Authentication for DNS (MARID), which led to its demise. Technical questions arose as to whether Sender ID would work as specified. Most of these questions were rooted in the basic differences between path authentication and message authentication and remain unresolved.
Microsoft also filed for patents on parts of Sender ID, making the developer community unhappy about the strict licensing and ownership control Microsoft exerted, such as requiring Sender ID implementers to sign a license agreement to protect undisclosed and unspecified patents. Although the actual patent application was eventually published toward the end of the life of MARID, it came too late.
Another factor in MARID’s demise was that eager technology reporters fre- quently reported email authentication as the final cure for spam. This created great expectations for email authentication, which were dashed once the hard truth settled in that email authentication did not stop spam.
As a result, any useful work of the MARID group slowed to a crawl with the IETF eventually shutting down the group. Recently AOL has withdrawn its support and is falling back on Sender Policy Framework (SPF). Evidently AOL has technical concerns that Sender ID may not be fully backwardly compatible with the original SPF specification.
Domain Keys to the Kingdom
In 2004, Yahoo! started signing all its outgoing email with DomainKeys headers, and EarthLink is testing DomainKeys prior to deployment. DomainKeys is a Yahoo!-proposed system for verifying the domain of an email sender. DomainKeys prevents forged emails from claiming to be from a domain it’s not. DomainKeys is an attempt to give email providers a mechanism for verify- ing both the domain of the email sender and the integrity of the messages sent. Once the domain can be verified, it can be compared to the domain used by the sender in the From: field of the message, to detect forgeries.
DomainKeys uses public key encryption technology at the domain level to verify the sender of email messages. If it’s a forgery, it can be dropped without impact to the user. If it’s valid, the domain is known, so a persistent reputation profile can be established for that sending domain that can be tied into anti- spam policy systems, shared between service providers, and even exposed to the user.
Sending Domain-key email: DomainKeys begins by performing a secure hash of the contents of a mail message using the SHA-1 algorithm, encrypting the result using a private key with the RSA algorithm and then encoding the encrypted data using Base 64.
The resulting string is then added to the email as the first SMTP header field with the key Domain-keys:, thereby adding a digital signature to the email. It doesn’t encrypt the actual message; it just adds a digital signature to the header.
Helping Your Organization Avoid Phishing 157
The sending process is as follows:
1. Setup: The owner of the email-sending domain first generates a public/ private key pair to digitally sign all outbound email. The private key is distributed to outbound email servers and the public key is made available.
2. Signing: After an email is created, the server uses the stored private key to generate the digital signature, which is attached as an email header and sent.
Receiving Domain-key email: The receiving server uses the name of the domain from which the mail originated to perform a DNS lookup, getting that domain’s public key. The receiver then decrypts the hash value in the header field and recalculates the hash value for the mail body that was received. If the two values match, this proves to a very high degree of confidence that the mail did in fact originate at the purported domain and has not been tampered with in transit.
One advantage of using DomainKeys is that it doesn’t require the cumber- some signing of the public key by a certificate authority (CA). DomainKeys allows for multiple public keys to be published in DNS at the same time, thereby allowing companies to use different key pairs for the various mail servers they run. It’s also easy to revoke, replace, or expire keys at a company’s convenience, permitting the domain owner to revoke a public key and shift to a new key pair at any time.
Yahoo hopes that DomainKeys will help stop spam by
■■ Allowing receiving companies to drop or quarantine unsigned email that comes from domains known to always sign their emails with DomainKeys.
■■ Allowing email service providers to begin to build reputation databases that can be shared with the community and applied to spam policy. ■■ Allowing server-level traceability by eliminating forged From:
addresses.
158 Chapter 6