CircleID

Geez John, here you go again.  Lots of unsubstantiated claims against SPF.  You are the chair of the IRTF's Anti-Spam Research Group, why don't you do some research?

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.

Are you trying to claim that people have stopped publishing new SPF records in significant numbers?  When was this "magic anti-spam silver bullet stage"? 

Both Andy Newton and I have periodically done surveys of all domains in several TLDs (.com, .net, etc.).  We know the answer to the first question, and the answer is that many new SPF records are being published.  The data I have shows that the percentage of email covered by SPF records is increasing. 

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.

I have researched into the number of SPF records that have been added, deleted and changed a couple of times over the last year or so.  That kind of discounts your claim that people in the SPF community aren't eager to know this. 

I know the answers to your speculation, but before I give out the latest data, I want to ask you "what do you consider to be 'small'"?

Also, remember that SPF records were designed so that they wouldn't require that much maintenance.  The many SPF records like "v=spf1 mx -all" are still going to be valid today, even if they have changed the MX records.

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.

Actually, none of what you have said is true.  There have been discussions between the SPF community, the IESG and Microsoft for months about this.  These discussions are easy to find.  I'll let you do the research to find them.  I'll give you a hint though:  If Microsoft had said they would change the spec, we wouldn't have felt the need to file an appeal now, would we?

I realize that you don't like SPF.  That's fine.  But your many claims over the months that SPF isn't being used, or that it is losing mindshare appears to me, based on actual data I have collected, to be just wishful thinking on your part. 

My, aren't we touchy.  I expect that if Wayne had numbers that supported his arguments, he would tell us what they are, so I'll let people draw their own conclusions.

Yeah John, maybe I am being a little touchy.  I guess, as your position as the ASRG chair and such, I expect a lot more from you and for you to back up your claims.

As far as having numbers backing me up, I simply don't want to fall into the trap of saying "X% of the SPF records were updated between <date1> and <date2>", and then you claiming that "see!  X% is small", no matter what the value of X is.

The rest of the stuff I didn't research for you can be found by using google.  It would be pretty silly of me to claim that this stuff hadn't been discussed before unless I knew that it could be easily found.

Note: this is a repost comments that originally were made on NANOG mail list, see http://www.merit.edu/mail.archives/nanog/2005-08/msg00891.html

Some corrections to what is said in John's article:
1. The appeal is against publication of SID draft (3 SID drafts, although only one is actually mentioned in appeal they go together) as experimental RFC(s) in current form. This does not imply that SPF draft would not be published by itself as article's title suggests (although it maybe delayed if there is another attempt to reconcile the differences). In article text John does not say that SPF draft would not be published because of this appeal, so I'm unsure why such a title…
2. The appeal is made to IETF Chair Brian Carpenter. According to IETF system he can choose to have appeal decided on by IESG or can choose to decide on it himself (in which case his decision can still be appealed to IESG). So far he has not said if IESG as a whole will consider the appeal. In either case, saying that IESG received this appeal is probably not quite correct (they were CCed however).
3. During MARID itself it was decided that new record version would be used (SPF2.0 prefix), which is opposite to what John says in the article about there being decision as part of MARID to reuse existing v=SPF1 records.
4. Nobody knows how many records had been published exclusively for SID because of Microsoft, probably a lot lot less then for SPF. But I don't think maintaining records is such a big deal (rather having to decide what goes into initial record is a lot more of a problem) and this probably would not be the reason why SPF2 SID records would not published if separation happens.
5. As far as last two paragraphs in the article, first of all appeal is being made after people already asked if MS is willing to make a change and they said no. And as far as solution to this that lets "Microsoft save face", it probably can involve using positive results of SID test with v=SPF1 record, but not negative results of such check unless its SPF2 record (which it not say that everyone at SPF "camp" would support this, but it is probably better then now). But I'd not be surprised if instead MS chooses to disregard IESG and IETF and proceed with SID even if its not approved for RFC, nor would I be surprised if IESG is afraid to say no to MS even when it knows this is bad engineering (which would further undermine believe in IETF as being neutral standards body focused on technical excellence and not controlled by large vendors).

I thank William for confirming all of my important points.
In MARID they did invent a 2.0 record, but at the same time they decided to fall back to SPF1.

As far as Microsoft saying no, a headline saying "Microsoft blows off IETF" would gather more attention than "Microsoft blows off self-appointed guardians of SPF", so assuming the IESG agrees that there's a problem, MS might possibly want to reconsider.

And although the appeal was only against the Sender-ID draft, the problem is the interaction between the two, so if I were the IESG, I'd wait to see what the outcome was before publishing anything.

William wrote:

3. During MARID itself it was decided that new record version would be used (SPF2.0 prefix), which is opposite to what John says in the article about there being decision as part of MARID to reuse existing v=SPF1 records.

John replies:

I thank William for confirming all of my important points. In MARID they did invent a 2.0 record, but at the same time they decided to fall back to SPF1.

Sorry John, but again, William is right and you are wrong.  The whole purpose of creating the 2.0 record format in the IETF MARDI workgroup was so that there *wouldn't* be re-use or a fall back to SPFv1 records.