REDMOND, Wash., Oct. 25, 2004 — After several years of fighting the problem of spam, the technology industry has made great strides in cutting back the volume of unwanted e-mail making its way into user’s in-boxes.
Despite this progress, certain types of spam e-mail are much more destructive and intrusive than ever before. Spammers, wielding an increasingly dangerous breed of scams called “phishing” and “spoofing,” have found new ways to exploit the e-mail delivery system, and rob individuals of their security, privacy, financial assets, and perhaps most important to the e-mail ecosystem — their trust. Overcoming this problem is the next big hurdle in the fight against spam.
Ryan Hamlin, General Manager, Safety Technology&Strategy Group
Today Microsoft and others in the industry took the next step in that fight by publishing the revised Sender ID Framework (SIDF) specification to the Internet Engineering Task Force (IETF) standards body. As part of the announcement, PressPass sat down with Ryan Hamlin , general manager of Microsoft’s Safety Technology and Strategy Group, to find out more about SIDF and how it fits in with the industry’s overall efforts to counter spam.
PressPass: First of all, what are phishing and spoofing?
Hamlin: Phishing and spoofing really go hand in hand. Spoofing is the common spammer practice of altering the e-mail’s “From” address and making it appear to come from a legitimate sender. Phishing is the practice of attempting to trick e-mail recipients into divulging personal information, such as credit-card numbers or account passwords, by sending e-mail pretending to be from a legitimate source, such as a user’s bank, credit-card company or online Web merchant. The vast majority of phishing attacks come from e-mail in which the From address has been spoofed. A spoofed address makes the “phished” e-mail look even more authentic.
PressPass: What is Sender ID, and how does it work to counter those attacks?
Hamlin: Sender ID is a royalty-free e-mail-authentication technology that helps address the problem of spoofing and phishing by verifying the domain name from which the mail is sent. Sender ID validates the origin of an e-mail by verifying the IP address of the sender against the purported owner of the sending domain. It is a fairly straightforward approach, and while it does not explicitly prevent spam or phishing scams from being initiated, it does make them much easier to detect because it provides a more reliable answer to the question “Who actually sent the message?”
However, Microsoft and the industry recognize very clearly that there is no single solution to the spam problem. This is not the end of the journey, but it is a significant step forward in taking away the biggest “trick” that spammers and phishers use to deceive end users. Sender ID is one piece of the overall puzzle, but a critical piece. We hope it will help provide a foundation for a larger solution to create an effective dragnet that stops spammers and Internet con artists from claiming more victims.
PressPass: What has been changed to improve this revised spec?
Hamlin: After sitting down with other industry leaders, critics and companies in the open-source community to get their feedback, we revised the specification to ensure its compatibility with anyone who has published previous Sender Policy Framework, or SPF, records, and to provide these organizations with a range of choices. This revised specification now accepts the 60,000 or so domains out there that have already published their records, and allows companies to choose between the simple From address verification or what is called a PRA (Purported Responsible Address) verification, which some companies prefer, including Microsoft. So we see this revised specification as a big step forward, and one that is really going to help facilitate deployment by allowing mail receivers to choose the method they would like to use.
PressPass: Who has taken an active role in the Sender ID Framework?
Hamlin: Fortunately, many in the industry have jumped on board from the beginning. AOL in particular has helped us work through some issues that were a concern for them. SendMail, one of the largest providers of open source e-mail software, has also given input into the new specification. In addition, we are seeing numerous other leading organizations take steps to support and implement Sender ID as well, including Barracuda Networks, CipherTrust, Cloudmark, Constant Contact, the E-mail Service Provider Coalition, GoDaddy.com, Interland, IronPort, Metamail, Port25 Solutions, Sendmail, TRUSTe, Tumbleweed and VeriSign, to name a few.
PressPass: How can organizations get started using Sender ID?
Hamlin: The call to action is really for companies first to publish their Sender ID record. There is a tool on our site (www.microsoft.com/senderid) that will help create that record. Once created, companies need to publish that information in the text record in DNS. For senders, this is the only thing they need to do.
Mail receivers, including Internet service providers (ISPs) and mail transport agents (MTAs) have one more step to complete. They need to make sure that their software is compliant and has been updated. Many of the MTAs and ISPs have already made this change or are in the process of making the change for their customers.
PressPass: How is Microsoft implementing Sender ID?
Hamlin: We are already publishing our records and will be rolling out a PRA check later this year for MSN mail and Hotmail. Our system will check the sender domain, to see if there is an SPF record, and perform the PRA check on it. The results of the PRA check will go into our SmartScreen filter, which is our machine-learning technology that will give the e-mail a “score.” If the domain has a Sender ID record, the e-mail is less likely to be judged as spam. If it doesn’t, there will be a higher probability it will be judged as spam. Over time, as the deployment of Sender ID gets wider, the weighting associated with the PRA check will change.
PressPass: Why is Microsoft making the decision to do the PRA check instead of the mail from check?
Hamlin: Well, there are pros and cons of course, which is why the specification allows for the choice. We believe the PRA check provides a more reliable indication of where the mail is coming from and really helps to solve the phishing problem. The other reason is that 10 percent of mail is legitimately forwarded, and PRA provides an easier deployment to allow for those forwarded e-mails.
PressPass: You mentioned that this specification is only one piece of the puzzle. What other technologies out there are showing promise to help combat spammers?
Hamlin: There are other authentication technologies, such as signing technologies, that will complement and enhance this specification and provide a more comprehensive solution, and we support the development of additional authentication technologies that can be used in conjunction with the Sender ID framework. We’ve been working with two promising proposals in particular, Yahoo!’s domain keys and Cisco’s Identified Internet Mail. We believe these solutions combined will provide a stronger level of authentication while offering a range of deployment alternatives.
What’s important to understand is that there is no one single solution. Sender ID is not the be-all end-all. We believe and hope that a range of alternatives and technologies will evolve over time that will complement and in some case replace others. No one company can do this alone. It requires an intense amount of collaboration, probably unsurpassed in the industry.
The other part is that no technology can solve this problem alone either. The technology is a critical piece, but it must be combined with strong legislation, enforcement, education and other efforts to really be effective in ridding our e-mail infrastructure of the problem of spam.
u
