Security Advisor
The Solution to Spam
Roberta Bragg looks at Sender ID, the new anti-spam technology being developed by Microsoft.
- By Roberta Bragg
- 11/01/2004
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.
 |
| 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.