Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
With the closure of IETF’s MARID group a month ago, many of us have left Microsoft’s Sender-ID standard for the dead. After being rejected by the Apache Foundation and the Debian Project over licensing issues, and causing the closure of MARID for some of the same issues (in addition to already long running technical ones), some thought that Microsoft may have just buried it and gone on to better things like IETF’s new MAILSIG group (in formation). But just like the ghost of Hamlet’s father it just refuses to die and now it looks like it is coming back to life in a new reincarnation. According to this story, Microsoft’s Sender-ID standard is back to life after being picked on by lawyers and techies. It has been revised to allow backwards compatability support with SPF, license tweaks to allow “no license required” use of Sender-ID for SPF-like MAIL FROM checking, and has also been resubmitted to the IETF for approval as an experimental RFC. There are also rumors of changes to the actual patent application but so far they remain unsubstantiated.
In any case, IETF’s drafts repository so far shows no signs of a new draft, neither does the IETF IPR page indicate any licensing changes but that takes a few days sometimes. HOWEVER, the FAQ [PDF] listed on Microsoft’s Sender-ID site has been updated with these two changes:
Based on industry feedback, the Sender ID Framework has been enhanced to include support for validating two different identities; the Purported Responsible Address (PRA) derived from message headers and the Envelope From Address (MAILFROM) obtained from the SMTP protocol MAIL command.
...
Q5: Who needs to execute a license with Microsoft? A: It s important to note that the license is only relevant to those organizations (ISP, large enterprises)who will be checking e-mails using the PRA check alternative of the Sender ID Framework need to secure a license. Those simply publishing their Sender ID records do not need this license.
A more surprising development happening this week concurrently is the related press release from AOL endorsing the “new” Sender-ID. It seems that the sticking point was backwards compatibility with SPF:
On September 15th, AOL announced that it would not move forward with the deployment of Sender ID technology, because we had reservations at that time about the specific version that had been submitted. Namely, the fact that Sender ID at that time lacked ‘backwards compatibility’, which meant that all of the development work AOL and many others had put into the email authentication testing process would be cast aside by the new version of Sender ID.
However, a previous statement from AOL’s spokesman specifically pointed to the licensing issue:
“Given recent concerns expressed by the Internet Engineering Task Force (IETF), coupled with the tepid support for Sender ID in the open source community, AOL has decided to move forward with SPF,” Nicholas Graham, AOL spokesperson, told internetnews.com via e-mail.
Sounds like the open source community is not much of an issue anymore to AOL, which was alluded in their earlier statement:
For AOL, the concerns of the open source community are an important but not critical reason for withdrawing full support of the Sender ID technology
However a more important issue at hand, is the last paragraph of AOL’s press release:
“AOL also looks forward to presenting these views and others at the Federal Trade Commission’s (FTC) email authentication summit in November, along with our industry partners.”
The FTC and NIST are holding a joint summit on email authentication in two weeks in Washington, DC (during the same week as IETF’s 61st conference). They hinted earlier this year that if the industry does not come up with a standard for authentication, the feds might impose one. If Microsoft comes to the FTC with AOL in tow, this may tip the balance in favor of Sender-ID as the “ultimate” industry standard. So Microsoft et al. just might be circling the wagons now in preparation for the summit.
And those pesky open source people? Some of the comments filed with the FTC in preparation for the summit have clearly indicated to the FTC that licensing is a major issue. That was also one of the questions asked by the commission in their original Federal Register notice:
8. Whether any of the proposed authentication standards are proprietary and/or patented.
9. Whether any of the proposed authentication standards would require the use of goods or services protected by intellectual property laws.
While Microsoft et. al. may choose to say “who cares about the open source camp anyway”, perhaps even to the FTC itself, let’s not forget an important point - as pointed out in one of my earlier articles, the four major MTAs that run majority of Internet’s email are all open source. Even non-MTA software used for fighting spam such as Apache’s SpamAssassin are used widely and even open source email clients like Mozilla’s Thunderbird are gaining support. So while the open source community may have been easy to ignore years ago, today open source influence is felt in every piece of Internet’s infrastructure from the desktop to the server.
So as the ghost of Sender-ID rises from its earlier grave, we may be tempted to ask Microsoft about its future plans for this standard. Having being snubbed by the IETF through MARID closure, why is it that Microsoft is insisting on pursuing this standard without giving in an inch to the open source community on licensing issues? Perhaps the software patents issue has gone so far that companies are taking out defensive patents for the sake of patents, and Microsoft is just doing this to defend itself? Or perhaps having failed to ram Sender-ID through the IETF, Microsoft is now using its extensive lobbying power to convince the FTC to mandate Sender-ID? We may never know, but one thing is for certain - this battle is not over yet.
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byVerisign
Sponsored byDNIB.com
A World-Renowned Source for Internet Developments. Serving Since 2002.
About a month ago, I posted the following message to the MARID list:
http://www.imc.org/ietf-mxcomp/mail-archive/msg05135.html
It appears that my predictions are coming true. Meng, MS and the IETF shut down the MARID WG so that they could more easily push the patent encumbered SenderID through. They no longer have to deal with a WG last call.
Expect more steps to happen after IETF-61 when the individual drafts will be “reviewed”.
The IETF has failed the entire community during this process. They have literally slept while Rome has burned - the spam problem is far from new.
I predict adoption of both SPF and Sender-ID by most ISPs and enterprises over the next 18 months. Cryptographic methods like DomainKeys may follow.
The ISPs need a solution now. The MTA vendors will build in whatever works, IETF-impramateur or not. I’m normally a fan of the OSS movement, but I believe that, in this case, they have sorely overestimated their influence.
Daniel,
You might be underestimating the OSS community here specifically because of their large influence over the Internet infrastructure. Majority of so called “MTA vendors” are actually open source products: Exim, Postfix, Qmail and Sendmail, of which only one, Sendmail, is really commercial. The rest are open source, and some such as Exit are under the GPL which is not compatible with Microsoft’s patent license even according to Microsoft lawyers. Additionally, players such as the Apache Foundation and the Debian Project, play a very large role as well with projects like Apache’s SpamAssassin.
Additionally, as many of the MARID, SPF, etc. participants have been discussing for months, sender authentication does not solve the spam problem, rather it provides a foundation on which to build on to reduce it.
As for the IETF, it is not necessarily their responsibility to solve the spam problem. As I wrote in one draft on this issue, the IETF is a standards organization and its role here is limited to standards. Unfortunatly, the spam problem is entirely standards related. While some of the issues are definetly related to security lapses in the SMTP protocols, other non-technical reasons play a very large role. Things like refusal by ISPs to monitor their own users (port 25 filtering and throttling for ex), lack of security on home computers, lack of cooperation among ISPs, etc. are all things that contribute very largely to the spam problem and none of which can or should be solved by the IETF. After co-chairing the ASRG for over a year, I saw the limits of IETF’s role and influence in this area.
It takes 2 to tango! ALOAHA promotes SPF and Sender ID as complementary technologies!
ALOAHA SPAM Rejecter is the first recognized Windows based AntiSPAM Solution which makes SPF and Sender ID available as freeware for all windows based Servers such as Microsoft Exchange, Lotus Notes, iMail and others.
ALOAHA, a Madrid, SPAIN-based email protection organization, has begun shipping free versions of SPF (Sender Policy Framework) and Sender ID as well as a POP3 Connector as part of its larger AntiSPAM Framework which is able to protect basically all Windows based Mailserver.
?I applaud Aloaha for releasing a solution which supports both SPF and Sender ID. Sender authentication promises to be a major advance in the war on spam, and Aloaha’s timely support for these emerging standards leverages the existing base of hundreds of thousands of existing records to offer better spam protection for their customers,? said Meng Weng Wong, CTO and Founder of Pobox.com and author of SPF
To get the freeware modules, companies must download the free, 30-day trial version of Aloaha. However, modules like SPF and RBL Lists will continue to be fully operational for free even if no licenses are being purchased after 30 days.
ALOAHA and its Modules work on every Windows based Mailserver such as Microsoft Exchange, Lotus Notes and iMail. Due to its innovative transparent proxy design Aloaha rejects SPAM before it reaches the SMTP Server. Optional the customer can also opt to use it as a SINK Plug-in in Microsoft Exchange or Internet Information Server. According to Aloaha CEO Frank Hellmann, Aloaha includes a number of anti-spam features in addition to the SPF and other DNS based modules. For example, incoming emails are checked against Active Directory or other Databases to verify if the recipient exists in the organization. Aloaha brings along also other innovative technologies like relaxed greylisting to the Mailserver.
“With thousands of downloads we will contribute our share to help to stop the global SPAM Problem” Hellmann said. “Of course we hope that some of these downloads actually will become paid installations” he added later.
Contact Information:
Frank Hellmann
Aloaha
email: .(JavaScript must be enabled to view this email address)
hmm. An unsolicited advertisement in the comments! What delicious irony :)
Yakov,
I guess that when I think of “Internet infrastucture”, routers come to mind, not mail servers :) At any rate, there are plenty of OSS MTAs out there. There are also plenty of commercial MTAs (Exchange, Lotus) especially at enterprises. All the OSS MTAs have or will have SPF and Sender-ID plug ins, if not now, soon. This will sidestep the OSS licensing issues. ISPs in particular will impliment SPF and Sender-ID on their mail platforms, period. Its happening right now. (AOL, Earthlink, MSN, RBOCs, MSOs, PTTs)
SPF and Sender-ID won’t stop Spam. But sender authentication is a vital part of the effort. Without it, reputation services, the true magic bullet, won’t really be possible. White/black lists and other anti-spam technologies improve markedly when you know who the sender is (for some definition of “know”). Checking 2822 headers is an extremely important aspect of this, and vital to stopping phishing.
Its not the IETF’s sole responsibility. However, the underlying standards are. Once those are in place, ISPs will start moving (as is happening now with the Anti-Spam Technical Alliance). The AOL Postmaster issued some (quite sensible) threats at the last NANOG meeting to those who didn’t filter port 25 and perform smtp-auth.
My comments are directed towards those who reject Sender-ID. This is a reasonable technology for doing SPF-style checks on RFC2822 headers now - not at some murky point in the future when someone develops some alternative with less legal baggage. We shouldn’t expect Microsoft to roll over for their competitors - the OSS crowd. They are already doing their part by freely licensing the PRA method.
IMHO, the IETF’s prevalent model of consensus breaks here. The market will now decide the matter. On that note, I sincerely doubt that the FTC will take any strong position - it would be a real departure for them.
Daniel, I am almost lost for words. Sender-ID may be a reasonable technology for checking email headers—I won’t argue that point. I am, however, quite boggled by how lightly you dismiss the legal baggage associated with it. By your own admission, Microsoft is using this technology as leverage against its competitors: to back Sender-ID with its current encumbrances is therefore to be a Microsoft tool. Fair trade for an anti-phishing mechanism, you think? Not if Microsoft’s agenda and your own differ sufficiently. Given as how I benefit greatly from the existence of free software, I consider it a lousy trade: Sender-ID with encumbrances is nothing but a rod for my own back in the long run.
I find this conclusion staggeringly obvious, so much so that I think you can’t have missed it. What’s your angle, then? That cooperating with Microsoft’s hostile intentions is harmless for some reason? That free software in general is of less value than Sender-ID in particular? Please explain.