Security Advisor

The Solution to Spam

Roberta Bragg looks at Sender ID, the new anti-spam technology being developed by Microsoft.

Spam is loosely identified as any e-mail the recipient doesn't want. A number of efforts are underway to block this plague, but the one I think holds the most promise is Sender ID.

A new anti-spam technology being developed by Microsoft, Sender ID won't keep legitimate vendors from sending you advertisements, but will allow you to distinguish between legitimate vendors and those that continually send unsolicited commercial messages. It may also help correctly identify sources of e-mail you don't want to receive at all. Once the sender can be correctly identified, filters that reject known abusers or accept only known, approved sources will work better.

Sender ID is the result of a combination of two technologies: Sender Policy Framework (SPF), developed by Meng Wong, co-founder and CTO of e-mail service provider Pobox.com, and Caller ID for E-Mail, patented by Microsoft. While it isn't the only proposed solution to the spam issue (digital signatures and rate limiting are others), I believe it's the one that can be most rapidly implemented at the least cost to individuals and organizations.

Note that efforts to standardize on a single e-mail authentication solution are in flux. In September, the Internet Engineering Task Force (IETF) working group that was trying to devise a standard sent Sender ID back to Microsoft, citing intellectual property concerns. Shortly thereafter, the working group disbanded altogether, citing "fundamental disagreements" among members. Microsoft already owns a patent on some of the technology; they offer a free license for it, but require that any users obtain a license. Some open-source folks say they don't want to have to license it, even at no cost from Microsoft.

Microsoft's efforts are continuing, though, and major e-mail services and vendors are moving forward with plans to implement Sender ID capabilities for their domains and products. For example:

  • MSN has been testing Sender ID.
  • Verisign has announced intended support for Sender ID in its e-mail security service.
  • IronPort Systems has plans to integrate support of Sender ID in its C-series e-mail security appliances.

Both Microsoft's Caller ID and SPF check an e-mail's purported domain and its originating IP address to see if the IP address is authorized by the domain owner. Caller ID and SPF differ in how the e-mail is examined and its information extracted.

Sender ID provides an e-mail server with the ability to correctly identify who sent an e-mail and thus be able to more easily determine whether to accept or reject it. This method is different from merely determining on an organization-by-organization basis from whom you want to accept e-mail; it allows you to reject all mail that can't be identified as legitimately coming from an authorized source.

How Sender ID Works
When Sender ID is implemented, hosts or nodes will be identified in DNS records as the authorized message transfer agents (MTAs) for e-mails sent by those domains or networks. MTAs—the e-mail server software component that receives messages from and sends messages to other e-mail servers—can then identify whether incoming e-mail is coming from a legitimate source. While the process is subject to user configuration, here's how it works in general (illustrated in Figure 1):

1. An e-mail message arrives at your SMTP mail server. The server identifies the IP address from which the e-mail is received.

2. The mail server performs a check to determine whether the SMTP client—the server that sent the e-mail message to your mail server—is authorized to send the e-mail message. The server gleans the answer by:

a. Extracting the purported e-mail address (the one the message claims it comes from) from the e-mail header.

b. Extracting the purported domain address from the header.

c. Looking up the authorized mail server IP addresses for the purported domain and checking the IP address from step 1 against these addresses.

3. If the IP address in step 1 is among the authorized addresses listed for the purported domain from step 2b, the message is considered legitimate and is passed along. Messages with question marks undergo further checks:

a. If the message has a missing or malformed address or some other questionable condition, it is subject to heightened scrutiny by other means, such as spam filters or quarantining until it can be inspected.

b. If the checking function fails to operate, the e-mail may be rejected or provisionally accepted and subject to the same heightened scrutiny as in point 3a.

c. If the message definitively does not come from the authorized source for the domain from which it purports to come, it should be rejected—either deleted or quarantined until such time as it can be inspected.

The Sender ID Process
Figure 1. The Sender ID Process. (Click image to view larger version.)

Counter Hacks
Every protective mechanism deployed will spawn new attacks. The following attacks might be used to attack Sender ID-based spam solutions:

  • DNS attacks. Sender ID will only be as secure as DNS. Forging DNS records would be one way to make an end-run around Sender ID. Securing access to DNS servers, general DNS hardening, preventing DNS cache poisoning and securing dynamic DNS when it's deployed are ways to mitigate DNS attacks.
  • Mail server compromise. If the authoritative MTA for a domain can be hacked and used to send out spam, Sender ID will be of no use. Those responsible for the security of mail servers can't expect outside security mechanisms to protect them and must use all possible best security practices to defend the mail server.
  • Corruption of e-mail headers in messages. If MTAs are compliant with the IETF draft, these messages should be subject to further scrutiny as described above. It's possible that header corruption will work if that scrutiny isn't done well.

Call to Action
What should you do now, or will you be required to do in the future, to utilize Sender ID on your network? You must examine, and potentially modify, both outgoing and incoming mail processes.

Outgoing Mail Processes
In order to ensure Sender ID's success, it's important to register authorized MTAs in DNS records. The anti-spamtools.org site provides a walkthrough of the process in its Sender ID Framework DNS Record Creation Wizard. You may need to adjust this record should an IETF standard emerge.

  • If you simply use your own domain name in the headers of e-mail sent by your servers, nothing is necessary for compliance. You should, however, publish a record in DNS.
  • If you forward received mail to other addresses, you must add the Resent-From header that contains the authorized e-mail address.
  • If you're responsible for a mailing list server, you must add the Resent-From header that contains the authorized e-mail address.
  • If you're a third-party mailer and send mail on behalf of another user, you must add a Sender header to provide the authorized e-mail address.
  • If you develop mail client software such as Outlook, your software should display both the responsible address and the From: address if they're different.

Incoming Mail Processes

  • If you require Sender ID checks for incoming mail, you must update to Sender ID-compliant software for your mail servers.
  • If you're a consumer of ISP or other e-mail services, you don't need to worry about mail server updates; the ISP must update its mail servers.
  • E-mail clients may need to be updated to show information provided by Sender ID checks. Sender ID is currently in development/test mode at Microsoft, and no updates are yet available.

More Information

Why Sender ID Will Work

Spam is difficult to deal with for several reasons. Sender ID doesn’t resolve all of them, but it does provide a tool that can aid the development of processes that will. Because it will be the foundation on which these processes are built, you should be examining the following issues to learn how Sender ID defeats them, and why it will be hard to hack Sender ID:

  • Much spam is generated by taking advantage of security flaws in configuration and application software used in e-mail such as proxy, mail server and CGI scripts. Efforts to correct all of these flaws is impossible, since it would require perfect code security and perfect configuration. Then you’d have to define “perfection” for literally thousands of potential implementations. In other words, there are way too many people and processes involved to achieve perfection.

    In addition, a single user’s error can open the floodgates to thousands of spam messages that impact users whose systems are correctly locked down and configured. Sender ID relies in large part on the correct identification in DNS of authorized e-mail sources. While many versions of DNS are available, there is a limited number of DNS systems. In addition, DNS is typically configured by more experienced, trained administrators, and there is common agreement on how to secure DNS.
  • There is no easy way to determine if the sender is who he says he is. E-mail purportedly from financial institutions or other trusted entities was—in the past—accepted by most as legitimate. Not any more. “Phishing” attacks masquerade as legitimate requests for account or other sensitive information; they try to lure readers to spoofed Web sites.

    This could be the beginning of all kinds of malicious attacks: In addition to financial or identity theft, misinformation that results in some action may be the goal. For example, spoofed, bogus political messages, purported to be from a candidate’s campaign, might influence voting; spoofed reports from companies to shareholders might cause excessive buying or selling of stocks; spoofed instructions from software companies could cause incorrect configuration of operating systems. Be aware, though, that although Sender ID can determine if the message is coming from an authorized source, it can’t determine if the message content is correct.
  • Current spam filtering solutions rely on the effectiveness of filter algorithms, and the correct identification of what is unwanted mail. The problem is that ultimately, someone must determine which mail gets past the filter. That means determining what e-mail users want and what they don’t want.

    But this hit-and-miss method can lead to false positives. False positives occur when a legitimate e-mail is deleted due to a misidentification of its source as a known spam source, or even by the inclusion in the subject of a suspicious word.

    For instance, requested breast cancer information may be quarantined or dropped as suspected pornography, or an information security conference announcement may get banned for having the word “hardening.” Sender ID relies on the identification of legitimate mail servers for assigned Internet domains. It doesn’t seek to identify if the recipient wants to receive the e-mail; instead, it relies on providing the ability to reject any e-mail not coming from the authorized e-mail server for the domain.
  • We know DNS can be hacked. What will prevent spammers from simply sidestepping Sender ID? The use of DNS will work for a number of reasons. Since domain owners have authority to approve the information included in their DNS records, and since DNS can determine if a record comes from the authoritative source for a domain, the ability to spoof an authoritative source will be minimized. Attacks against DNS are possible, but many of these attacks can be mitigated using known DNS hardening techniques. They can be detected and corrected if appropriate monitoring and intrusion detection is performed.

Most agree that spam is an ugly problem in need of a solution. If Sender ID is that solution, it will still have to be adopted. Will we be able to obtain widespread adoption? There’s no way to know for sure, of course, but one example of a similar recent problem may provide some clues. The National Do Not Call Registry was designed to curb unwanted commercial phone solicitation and has been an unqualified success. In the first five weeks of its adoption more than 30 million people called or used the Internet to register their phone numbers. By June 2004, 62 million phone numbers were registered. And it works: Telemarketer compliance has been high. During the first year, fewer than half-a-million complaints were filed against 130,000 companies. Only 200 of these companies have more than 100 complaints each. The first surveys by the U.S. Federal Trade Commissions and Harris indicate consumers that added their phone numbers to the registry (http://www.donotcall.gov) are experiencing 82 percent to 92 percent fewer telemarketing calls, respectively. What would it be like if we could reduce the spam in our Inboxes by that much? —Roberta Bragg

About the Author

Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.

Featured

comments powered by Disqus
Most   Popular

Subscribe on YouTube