Internet and e-mail policy and practice
including Notes on Internet E-mail


Click the comments link on any story to see comments or add your own.

Subscribe to this blog

RSS feed

Home :: Email

28 Aug 2005

Maybe the IETF won't publish SPF and Sender-ID as experimental RFCs after all Email

Yesterday, the IESG, the group that approves RFCs for publication received an appeal from Julian Mehnle to not to publish the Sender-ID spec as an experimental RFC due to technical defects. IESG members' responses were sympathetic to his concerns, so I'd say that a Sender-ID RFC has hit a roadblock.

The problem is simple: Although Sender-ID defines a new record type, called SPF 2.0, it also says that in the absence of a 2.0 record, it uses the older SPF1 record. Since SPF and Sender-ID can use the same records, if you publish an SPF record, you can't tell whether people are using it for SPF or Sender-ID. Ned Freed commented:

There is, after all, an "experiment" in "experimental". A conflict that stands a good chance of making it imposisble to get useful results from the experiment is something that clearly needs to be resolved prior to publication.

Mehnle's suggested fix is to one line in the Sender-ID spec, to make it say that the older SPF1 record should only be used for SPF checks, not Sender-ID checks. Technically this is easy to do, probably only a few lines of code in anyone's Sender-ID implementation, but it could present a big political problem for Sender-ID advocates (that is, Microsoft.)

One of the arguments in favor of SPF and Sender-ID has been that vast numbers of people have published SPF records, so there must be a groundswell of support for them. What I think actually happened was that early in SPF's career, during the magic anti-spam silver bullet stage, lots of people published SPF records, and then forgot about them when they found that their spam didn't stop. When Sender-ID came along as a hybrid of SPF and Microsoft's Caller-ID, after lengthy discussion on the MARID list, they decided that since many Sender-ID records would have the same contents as the corresponding SPF records, Sender-ID would use the existing large set of SPF records. As a way to kick-start a package that you want to rush into use, it's not a bad idea. But as part of an experiment, which is what the IETF considers SPF and Sender-ID to be, it's a clear mistake.

The political and practical problem of separating SPF and Sender-ID records is that the number of SPF records that actively maintained is probably a tiny fraction of the total, and only those are likely to be republished as Sender-ID's SPF 2.0 records. Fans of SPF and Sender-ID are not eager to know what that fraction is, because if it's as small as we suspect, it puts the lie to claims of SPF's or Sender-ID's popularity.

Since this question only came up yesterday, nobody has yet had a chance to ask Microsoft if they're willing to change the spec, much less get an answer from them. One possibility, which I consider vanishingly unlikely, is that Microsoft agrees to the change to separate Sender-ID from SPF. A second is that the IESG publishes the Sender-ID spec anyway, since it's been sitting around for months and everyone already knows what it says. A third is that the authors prepare a version of the spec for the IETF different from Microsoft's, which is unlikely since the primary author works for Microsoft. And the last is that the authors say, oh, never mind, and withdraw it.

At this point, I'd say that it's somewhat likely they'll publish it as is, and next most likely that it'll be abandoned. The discussion in the IESG has been quite clear that they don't care what the change is so long as it's possible to experiment with SPF and Sender-ID separately, so it's possible that someone will come up with a fiddle that satisfies the IESG and is sufficiently face-saving for Microsoft, but it's hard to see what that could be, particularly with Microsoft flogging people (via Hotmail) to support the current version of Sender-ID immediately.

Update: The SPF Council on whose behalf Mehnle sent in the appeal, a group that considers itself the keeper of the SPF flame, already asked Microsoft to change the Sender-ID spec, Microsoft not surprisingly said no, and this is basically an attempt to put pressure on Microsoft, perhaps on the theory that a headline ``Microsoft blows off IETF'' would be more newsworthy than ``Microsoft blows off some guys on a mailing list.'' I think they were taken by surprise when at least one well-known IETF member suggested that unless they can untangle the two, neither Sender-ID nor SPF should be published as Experimental.

One reasonable resolution would be to publish the SPF and Sender-ID specs as Informational rather than Experimental RFCs, since neither the SPF nor Sender-ID advocates consider their projects to be experiments, and neither wants to make changes that would allow independent experiments with the two to proceed, but Informational is even farther away from being a standard than Experimental. The SPF Council really wants the SPF specs to be published as Standards Track, but of course there's no chance of that happening since it'd require reconstituting MARID which would be no more likely to succeed now than it was a year ago.

posted at: 14:54 :: permanent link to this entry :: 3 comments
posted at: 14:54 :: permanent link to this entry :: 3 comments

comments...        (Jump to the end to add your own comment)

SPF Files Appeal Against Sender-ID
(This comes from John) It seems that the SPF Community just lodged a formal appeal at the IETF against publication of Microsoft's Sender-ID specs. The issue at hand appears to be the fact that Sender-ID uses SPF records as a...

(by NetWizard's Blog 25 Aug 2005 20:46)

last I checked, the IESG was silent on this..
On the public IETF list, a few former IESG members have posted but as of the last time I looked no currently sitting IESG members have so far commented on the appeal.

(by Bill 26 Aug 2005 00:17)

SPF Community Sinks To New Low
In the past couple of days, members of the SPF community have filed 11th hour appeals (here and here) with the IETF to block the publication of Sender ID as an RFC. Both John and Yakov have details. I have to say that I am both disgusted and disapp...

(by grumpOps 30 Aug 2005 20:26)

Add your comment...

Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.

Email: you@wherever (required, for confirmation)
Title: (optional)
Show my Email address
Save my Name and Email for next time


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

Domain Name Registration Data at the Crossroads
55 days ago

A keen grasp of the obvious
My high security debit card
521 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

© 2005-2018 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.