Google
 

SPF and Sender-ID RFCs Published

May 4, 2006 – 2:41 pm

After over two years of work and arguments, the IETF finally published the RFCs for SPF and Sender-ID. They are as follows:

RFC 4405 - SUBMITTER SMTP extensions to be used with Sender-ID
RFC 4406 - main Sender-ID draft
RFC 4407 - PRA algorithm (which is what Microsoft was trying to patent - also see this)

RFC 4408 - main SPF draft

Additionally, while stumbling around the US Patent Office system looking at Microsoft’s patent applications for Sender-ID, I found something rather interesting. The applications in question (10/683,624 and 10/684,020) were filed October 10th, 2003. HOWEVER, both of them claim descend from another provisional application # 60/454,517 filed on March 12th, 2003. Incidently the ASRG opened for business a mere two weeks before (February 26th, 2003) AND the first working message posted to the list was by Hadmut Danisch on March 3rd, 2003 who authored the RMX draft which was the first of all pre-SPF and Sender-ID drafts. His first draft is dated December 2002 and can be found here.

Now the interesting stuff start here (you might want to have a copy of the original application handy which can be found here). Basically looking through the application, on pages 18 and 20, and then again on pages 55 and 56 RMX is claimed and described, virtually identical in function to the Hadmut draft mentioned above.

The mind boggles the probability of a Microsoft employee independetly coming up with an identical scheme called by the same name virtually two weeks after the scheme in question was mention on a brand new anti-spam standards-related list on which Microsoft employees started posted a mere two months later. I will leave the rest for you folks to decide.

(For those wanting to check the original application, use this USPTO site with app # 60/454,517).

IETF Movements in Email Authentication

May 20, 2005 – 5:36 pm

While email authentication is no longer such hot topic as it was last year, nevertheless the two main proposals (SPF and Sender-ID) are moving slowly through the IETF process to become experimental protocols. Both just published new drafts (spf and sender-id [1], [2] and [3]). At the same time it is interesting to note that Sender-ID has been placed on the next telechat agenda for the IESG. While SPF has not been put on the IESG telechat, it will probably follow shortly.

What does this mean in simple non-IETF-speak terms? These two proposals may finally be approved by the IETF for experimental use - a long path that started way back in the ASRG two years ago. It still remains to be seen whether either one will be deployed and widely used, especially considering the pending patent applications that Microsoft has on Sender-ID and their GPL-incompatible license.

Something’s Cooking at the IETF with Email Authentication

January 16, 2005 – 11:27 pm

(This article was published by Circle-ID)

DISCLAIMER: I do not have any inside knowledge regarding this nor have I discussed this with any IETF folks. This is based purely on publically available information.

A few months ago, Ted Hardie (AD of Applications for the IETF) informed the MARID WG in the closure announcement as follows:

Given the importance of the world-wide email and DNS systems, it is critical that IETF-sponsored experimental proposals likely to see broad deployment contain no mechanisms that would have deleterious effects on the overall system. The Area Directors intend, therefore, to request that the experimental proposals be reviewed by a focused technology directorate. This review group has not yet been formed but, as with all directorates, its membership will be publicly listed at http://www.ietf.org/u/ietfchair/directorates.html once it has been constituted.

IETF Directorates are defined in RFC 2418 as follows:

In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area.

Now the directorates list does not YET list anything on this. However, now comes word from the SPF folks that something is cooking in this area. In an email to the SPF Discuss list Julian Mehnle wrote the following of the recent SPF Council meeting:

Wayne reported that within the IETF, the draft-schlitt-spf-classic-00[6] specification draft had been conveyed to the Directorate for DNS and Email Authentication (DEA), which is working in private by IETF standard policy. The DEA would contact the drafts’s authors, Meng and Wayne, for any questions and comments. Wayne also stated that he had informed all relevant IETF working groups about the draft and that the DNS groups had raised objections, mostly regarding the zone cut default mechanism, but the e-mail working groups had not expressed any disfavor. Wayne said that was working hard on another iteration of the draft.

A quick check at the IETF’s mailing list page reveals a new mailing list called “DEA-DIR” which stands for “Directorate for DNS and Email Authentication”. The list is currently private and being managed by the two ADs for the application area. The list is referenced in an email from Ted Hardie to the SPF-Council’s mailing list dated January 10th, 2005:

DEA-dir is the list Scott and I are using to as a directorate list for folks helping us review these experimental proposals. The list itself is basically there so we can get folks who have committed to reviewing the drafts to share their reviews with each other. There is no need for you two as authors to be on it; Scott and I already know where to find you to ask you questions on your draft. The dea-dir list is closed, so we can keep the discussion focused, but its members have no special status; comments from reviewers on the list and comments from outside the list are treated exactly the same in the standards process. Anyone with a comment on the drafts can send them to the ADs directly.

So, it appears that the IETF is keeping to its promise after all and is proceeding with evaluation of email authentication proposals on the experimental track via this directorate. Of course since very little public information is currently available it is hard to judge what is going on. Hopefully, the IETF will release more information and publish a list of members as promised originally. And while SPF is being reviewing by the IETF, there has been no word to whether Sender-ID is getting the same treatment.

2004: The Year That Promised Email Authentication

December 25, 2004 – 11:25 pm

(This article was published at Circle-ID)

As the year comes to a close, it is important to reflect on what has been one of the major actions in the anti-spam arena this year: the quest for email authentication. With email often called the “killer app” of the Internet, it is important to reflect on any major changes proposed, or implemented that can affect that basic tool that many of us has become to rely on in our daily lives. And, while many of the debates involved myriads of specialized mailing lists, standards organizations, conferences and even some government agencies, it is important for the FOSS community as well as the Internet community at large, to analyze and learn lessons from the events surrounding email authentication in 2004.
Read the rest of this entry »

Yahoo Begins to Use DomainKeys

November 14, 2004 – 1:44 pm

According to a CNET article, Yahoo will begin on Monday to sign all outgoing email with DomainKeys signatures:

Yahoo on Monday will begin attaching antispam technology to all of its outgoing e-mails, hoping that other providers will follow suit. Messages from its free e-mail service will include a “Domain Key,” a system that creates a digital signature for outgoing e-mail and then lets receivers verify that the message comes from where it claims. The technology tries to thwart spam “phishing” attacks where messages pretend to originate from a familiar address and then launch viruses or social engineering hacks when opened.

A quick check with my Yahoo account reveals a DK signature:

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
b=Of+zvGE5KtBaCJoAibkTIN05XZB9//gePjpw7TkjMJs0v2/Of42HsFMwoPw2jYGDTVOv/L1OUOuulwObD4S6065WWxXyvCcF6afHz5z4TtsHiVxK/Nrmbpka3egjjSCosKyHreqhWVBHaeAvk9f88+N/UJGNEbPCAAe94yvSFyA= ;

No word on whether they will be checking incoming email as well.

FTC, Microsoft and Sender-ID

November 9, 2004 – 8:38 pm

As FTC’s email authentication summit takes place today in Washington (together with IETF’s 61st meeting), several interesting things are afoot. First of all, the “industry” published a letter of support for Sender-ID including a signature from Meng Wong, the author of SPF. Declan McCullagh of CNET reported today on the issues surrounding the patent problems with Sender-ID and what took place at the summit. Meanwhile, PJ of Groklaw published two excellent articles on the whole mess (1 and 2).

Learning from Ebay to Fight Spam

September 23, 2004 – 11:23 am

While reading some mailing lists posts about email authentication and reputation an interesting thought occured to me. Ebay’s feedback system, while imperfect, does present a sucessful reputation system in the online world. Perhaps we can learn something from them.

Sender authentication moving ahead

May 21, 2004 – 1:31 am

A lot of things happened this week: MAAWG meeting took place, Yahoo submitted DomainKeys to the IETF and a Microsoft submitted Caller ID draft to the IETF and SPF is merging with Caller ID via an addition of an ESMTP parameter for MAIL FROM. Architechurally speaking, I liked the idea of using ESMTP for a long time, so it looks like they are moving in the right direction (to me at least). Of course the question of what you do once authentication is used will rear its ugly head very soon, which is where reputation and trust questions will need to be addressed.

At this point, I finally feel that I personally made a difference by helping with all of these various proposals in the ASRG, and the IRTF/IETF transfer process. With CID and DomainKeys finally published, SPF and CID participating in the IETF, and the ASRG’s reputation somewhat gotten better than it was when I joined, I feel a certain sense of accomplishment about my work in the ASRG. I am hoping that my small contributions made a difference in the long term future of the Internet, and will somewhat help reduce the overall spam problem.

Reputation systems: Learn from the Past

March 2, 2004 – 9:52 pm

Reputation systems: Learn from the past

As the IETF BoF on mail authentication gets closer, more media and corporate attention is being attracted to the problem. And many articles mention that authentication is not the answer but rather reputation based on authentication is what will help the problem. It seems that authentication combined with reputation is the new holy grail together with e-postage.

As I said at the NIST conference - “those who ignore history are doomed to repeat it”. Before rallying behind “the new new thing” look at existing reputation systems like blacklists - and then think why the same problems like lawsuits, lack of accountability, etc. will not be a problem with these proposed systems.