|
|
|
Click the comments link on any story to see comments or add your own. Subscribe to this blog |
28 Aug 2005
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.
|
TopicsMy other sitesOther blogsCAUCE A keen grasp of the obvious Related sitesCoalition Against Unsolicited Commercial E-mail |
||||||||||||||||||
© 2005-2020 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.
