CircleID

About a month ago, I posted the following message to the MARID list:

http://www.imc.org/ietf-mxcomp/mail-archive/msg05135.html

The war, of course, is not over. The IETF (Ted, and maybe the former co-chairs?), Meng, and MS (Harry, Jim, Bob, et al) appear to have learned nothing from what has happened. They have done an end-run around the working group last call by closing down the working group, but they are still pushing ahead with the PRA under the current license. Apparently, they think that when the "individual" I-Ds are submitted to the IESG and there is an IETF-wide last-call, things will go better. I don't see it.

One definition of insanity is doing the same thing again and again and expecting different results. Under this definition, Ted, Meng, Harry, Jim, et al, are acting quite insane.

I see four choices:

1) Forget about getting a de-jure standard.

2) Drop the PRA.

3) Change the PRA license to be compatible with F/OSS MTAs.

4) Find one or more widely accepted alternative to the PRA that covers the 2822.From: identity so that people can reasonably choose between the PRA and the alternatives.

Ted, Meng, Harry, Jim et al: PLEASE! Wake up and smell the coffee! We need a anti-forgery system that protects the 2822.From: identity, we don't need another two-week blowup when the IESG last-call happens.

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:

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.