CircleID recently interviewed Meng Weng Wong, the lead developer of Sender Policy Framework (SPF) and founder of Pobox.com. As one of the leading anti spam authentication schemes, SPF is used by companies such as AOL, Earthlink, SAP and supported by anti spam companies such as Sophos, Symantec, Brightmail, IronPort, Ciphertrust, MailArmory, MailFrontier, Roaring Penguin Software, and Communigate Pro. Last month, Microsoft announced its agreement to merge Caller ID, its own proposed anti spam authentication scheme, with SPF — the joint standard is called 'Sender ID'.
In this two-part interview, Meng Wong explains how SPF got started, where it is today and what could be expected in the future of email. (To read Part I, click here)
CircleID: John Levine, a member of the Internet Research Task Force's Anti-Spam Research Group, and a popular critic of SPF has been quoted saying:
"...implementing that idea [SPF] would require changes to the Simple Mail Transfer Protocol (SMTP) standard that is the foundation for the e-mail system, and updates to existing mail software packages for every e-mail sender and recipient who want to participate… SMTP has worked the same way for 20 years… If the solution is that we get to change the way SMTP works, there's a long list of other things we'd like to change about it, too," he said."
What is your position regarding this concern?
Meng Wong: He's right. To explain, I need to talk about forests.
Normally, healthy forests have lightning strikes that lead to fires every few years. Those fires don't kill trees; the leaves of mature trees are out of reach, so the fires just burn up the dead matter sitting on the forest floor. Small, frequent fires are good for forests. The burned matter reenters the ecological cycle, and new seeds sprout. But wildfires are bad for forests: when fires are suppressed for too long, dead matter builds up for decades, and when it does burn it destroys entire ecosystems.
SMTP is past due for change. If we had been able to change the protocol every three years, maybe spam wouldn't be such a big problem today. Spam has overrun the internet the way an out-of-control wildfire blazes through a forest. SPF is the first controlled burn in a long time: there will be more to come.
It's true that changing standards is not easy. But not changing is even worse. There's a war on — a war against spammers. We have to be quicker to react and quicker to adapt if we want to win it. If things go on, how many years until people just stop using email altogether? They're not going to give us another twenty.
CircleID: There have been some concerns expressed regarding the incompatibility of SPF with some email forwarding services and websites that use mail-forwarding features. For instance, online greeting card services and news sites use email-forwarding features to allow readers to send email cards and articles to friends. How are such issues being addressed?
Meng Wong: The incompatibility with forwarding and web-generated email is SPF's single biggest source of fear, uncertainty, and doubt. At first we thought it would be a huge problem. A year later, it turns out that we were wrong. It turned out to be less of a problem than we thought for three reasons.
First, many greeting card sites have actually taken the initiative and voluntarily come into compliance. Contrary to popular belief, these "innocent bystanders" have been monitoring SPF quite closely. They realized that what we asked of them was entirely reasonable, and not that hard to do. One small greeting card site told me that SRS was something they actually wanted to do anyway, to better manage the error messages that go to users. And Evite, one of the biggest "legitimate forgers" of return-paths and "From:" headers, has also changed. Their practices used to cause a lot of problems for spam filters. Last week I got an evite and all their headers were perfect.
Second, the same has been happening for forwarders. Major forwarders like GMX in Germany and Pobox.com in the US have voluntarily implemented the SRS workaround. Other forwarders are sure to follow. (SRS stands for Sender Rewriting Scheme; it encapsulates the original return path so that outbound forwarded mail becomes SPF compliant.) There are three Open Source libraries out there that implement SRS. Forwarders who run their own in-house MTAs are welcome to use any one of them. Folks who run an Open Source MTA such as Postfix, Qmail, Exim, and Sendmail can download SRS patches. In the next few weeks, expect to see packaged MTAs available in RPM, .deb, and similar formats. Those SPF-enabled MTAs will have both SPF and SRS built in and ready to run.
Third, we worked around! Wayne Schlittt is the head of the Nebraska chapter of the SPF community and a major contributor to the SPF effort. In a heroic effort, he tracked down all the major forwarding service providers and put them into a whitelist at trusted-forwarder.org. By default, SPF plugins will query that whitelist. That means that even though forwarders like acm.org and ieee.org have not yet implemented SRS, mail from them will not be rejected.
The vast majority of publishing domains define the strictest form of SPF: their default "-all" means "reject if authentication fails". And millions of messages covered by SPF records are delivered every day. But how many false positives have been reported to the mailing list? None that I've seen.
CircleID: As you are very well aware, Yahoo! has also recently submitted a draft of DomainKeys, its own anti-spam authentication method, to the Internet Engineering Task Force (IETF) to begin its standardization process. How does Yahoo!'s DomainKeys compare to SPF/CallerID anti-spam authentication method?
Meng Wong: They are complementary and can work hand in hand. SPF and SenderID represent the designated sender school of thought. DomainKeys represents the cryptographic school. Both approaches are valuable. SPF/SenderID is easier to get running, and it is rolling out quickly today. DomainKeys is less mature, more complex, and more long-term. If all goes well, SPF and DomainKeys will meet in the middle and squash spammers like a bug.
In any case, DomainKeys needs SPF/SenderID. SPF is really two things in one: it defines a set of designated sender mechanisms, but it also defines a language in which alternative mechanisms can be specified. Cryptographic mechanisms are the alternatives we had in mind when we designed SPF. If a sender uses DomainKeys, they publish an SPF record that states that fact.
CircleID: Going back to the implementation of the merged SPF/CallerID plan, what sorts of updates or changes are going to be needed by ISPs, email application providers, spam filters, etc.?
Meng Wong: We're ready to rally the troops.
We have worked long and hard to get agreement from major players, and we have finally built up critical mass.
In the coming months I expect industry to start moving. We'll be publishing SPF records and upgrading to SPF-enabled MTAs that can implement SenderID and SPF Classic. Forwarders will need to firm up their plans for SRS. ISPs will need to support SMTP AUTH on 587 and start rate-limiting outbound mail servers, and implementing other recommendations seen in the ASTA document. We're still working out deadlines for "who needs to do what by when" on the spf-deployment mailing list. Industry leaders who want to help set the schedule before the train leaves the station are welcome to join that mailing list.
CircleID: Is there a possibility (and added benefit) for the eventual merging of all these standards? In other words, are we witnessing the initial stages of a collaborative industry move towards the adoption of a single standard?
In the same way, I think that in ten years "The New Email" will be a single thing with many parts: IP-based authentication, crypto-based authentication, reputation services, accreditation services. All of these parts will fit together better than they do today because their rough edges will be worn smooth with use.
And at the borders of email we'll see gateways to other messaging systems, like Jabber and SMS and video. We might also see things like micropayments and bonded mail (http://www.vanquish.com).
CircleID: Are there any other comments that you would like to share with readers?
Meng Wong: SPF is a success because we followed the Open Source model: we released early and we released often. We listened to feedback. When competing requirements fought, we tried to find a solution that made both sides happy. "Rough consensus and running code" was our guide. Every so often we took a step back to think about what we were really trying to accomplish. When we did that, we usually discovered deep and simple truths that lit up our design from the inside.
I am personally grateful to the hundreds of volunteers who have put thousands of hours of hard work into SPF. It is because of them that we are where we are today: hundreds of millions of SPF-approved messages are sent every day, checked by thousands of MTAs running a dozen different implementations. We're catching spam and viruses. This stuff is really working.
So now I'd like to ask for money. Changing the world is an expensive job! Flying around the world to get to conferences hasn't been cheap. The conferences themselves aren't cheap either. (Expect to pay $500 to attend the San Diego IETF.) According to some reports, spam is a $1 billion problem. It's costing us all a lot of money. And if we want to fix it, it's going to cost a little more.
If the work we're doing is worth money to you or your organization, we ask that you calculate what you would save each month if spam went away, and donate 10% of that number to the SPF project. Yes, we take PayPal.
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»
Afilias - Mobile & Web Services