Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9)

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Feb 2012 11:47:37 -0800

Hello,

Empirical evidence so far seems to indicate that there is a 
significant amount of DNS queries for the SPF RR (TYPE 99) and some 
sites publish it.  We have seen arguments in favour of removing the 
feature, and in favour of retaining it.

Our charter says this:

       Changes to the SPF specification will be limited to the correction
       of errors, removal of unused features, addition of any enhancements
       that have already gained widespread support, and addition of
       clarifying language.

Therefore, the WG Chairs would like to close Issue #9 with the 
conclusion that the SPFBIS WG does not have consensus to remove the feature.

Objections to this determination of consensus need to produce 
evidence that the feature is not used, or that the removal of TYPE 99 
is an enhancement that has already gained widespread support.  Please 
remember that the desirability of the removal of the feature is not 
enough: the charter restricts our freedom to do what we want here.

Best regards,
Andrew Sullivan & S. Moonesamy, SPFBIS WG Chairs

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 15:17:52 -0500

>enough: the charter restricts our freedom to do what we want here.

Personally, I think Type SPF could be removed as a mistake, so I don't think we are inherently limited by the charter.

If it stays in, there will be a derivative issue about query order. 4408 says SHOULD do Type SPF queries first if they are done sequentially. It should be the other way around. The query most likely to be successful should be done first.

Scott K

---

From: Dotzero <[email-masked]>
Date: Fri, 24 Feb 2012 15:24:25 -0500

> If it stays in, there will be a derivative issue about query order. 4408 says SHOULD do Type SPF queries first if they are done sequentially. It should be the other way around. The query most likel…

I don't have a strong position about keeping itor dropping it but I
agree with Scott that if we keep it we should minimize overhead by
specifying the query most likely to be successful (TXT) should be done
first.

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 15:31:34 -0500

Dear colleagues,

On Fri, Feb 24, 2012 at 03:17:52PM -0500, Scott Kitterman wrote:
> >     Changes to the SPF specification will be limited to the
> >    correction of errors,

> Personally, I think Type SPF could be removed as a mistake, so I
> don't think we are inherently limited by the charter.

Speaking with my hat on, I think the meaning of "correction of errors"
in the charter means corrections of errors in the specification and
not in the design.  That is, this is the basis for incorporation of
errata.  I believe the charter is designed precisely to limit changes
in functionality.  I'd be very much interested if people disagree with
that interpretation, and would like to hear as much if so.

If my interpretation is right, then "mistake" in your sense wouldn't
qualify, because you're arguing that it was a mistake in the design,
and not a mistake in the way the RFC describes things.
 
> If it stays in, there will be a derivative issue about query
> order. 4408 says SHOULD do Type SPF queries first if they are done
> sequentially. It should be the other way around. The query most
> likely to be successful should be done first.

Do you think (or not think) that that is also a substantive change in
functionality, and therefore would qualify as an "enhancement"?

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Feb 2012 20:32:06 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dotzero
> Sent: Friday, February 24, 2012 12:24 PM
> To: Scott Kitterman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9)
> 
> > If it stays in, there will be a derivative issue about query order.
> > 4408 says SHOULD do Type SPF queries first if they are done
> > sequentially. It should be the other way around. The query most likely
> > to be successful should be done first.
> 

I agree that this is at least worthy of discussion.  Please open it as a new issue so we can discuss it at some point.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Feb 2012 20:34:36 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, February 24, 2012 12:32 PM
> To: [email-masked]

I think it qualifies under the clause "addition of any enhancements that have already gained widespread support", if we can show that most of the SPF record publications use TXT.  We are thus guided by the implementation we observe.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Feb 2012 16:01:12 -0500

Dotzero wrote:

>> Scott wrote:
>> If it stays in, there will be a derivative issue about query order. 4408 says 
>> SHOULD do Type SPF queries first if they are done sequentially. It should be 
>> the other way around. The query most likely to be successful should be done first.
>>
>> Scott K
>>
> 

I think it would be a mistake if we do not consider these are 
extremely important points with was always a common design goal to 
reduce and minimize all DNS related overhead concerns.

I believe the original intent which included short term concerns and 
long term expectations for adoption was right on and the time spent to 
measure it now has shown the correct RFC engineering expectations has 
materialized.  SPF always had several thorns on it side within the 
IETF and one of them was its high DNS dependency and the "Kludge 
Effect" of using a TXT record.  Personally, this is one of those "feel 
good" outcomes that took a long time to see it done right.

I believe what is important now, could be viewed at the 2nd phase 
which is to begin to study and recommend the methods available from 
the worst to the ideal and preferred method for dual type queries. 
The 2nd phase also includes moving towards the publishing of SPF type 
only records which will also take many years, but it will never happen 
unless SPF-BIS prepares and encourages it.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 16:05:15 -0500

>functionality, and therefore would qualify as an "enhancement"?

The maturity level of the design related to Type SPF and it's interaction with Type TXT SPF records was substantially less than the rest of RFC 4408.

The rest of the SPF design was built on years of running code and operational experience. The Type SPF parts were a paper design with literally days to do minimal experimentation.

As long as we aren't changing the design in an incompatible way, there ought to be more wiggle room for changes due to error in this area.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Feb 2012 16:08:53 -0500

>> don't think we are inherently limited by the charter.

Pete is the AD responsible for this WG, so I'll defer to him, at least
for now, if he disagrees with me, but I think the situation is as
Andrew said, and that trying to declare the definition of an SPF RR an
"error" in order to remove it is an attempt to sneak past the charter
restrictions.  Not acceptable.

> functionality, and therefore would qualify as an "enhancement"?

If "nearly all" existing implementations query TXT first, then the
charter allows this change, as an enhancement that has gained
widespread support.  I would also be willing to be convinced that it's
a "clarification", though it would take some convincing.  (And I don't
see where RFC 4408 says anything at all about which "SHOULD" be
queried first; perhaps someone can point to the section and paragraph
they think says that.)

Let's please tread carefully here, lest someone win this one, and then
find himself on the losing end of a different issue wherein people are
trying to tweak the spec beyond what the charter was meant to allow.
I suggest that we stick to the intent of the charter, which is to move
what's currently there to standards track, and to consider these sorts
of changes afterward, as an update at PS or during advancement to IS.

Barry, incoming App AD

---

From: Commerco WebMaster <[email-masked]>
Date: Fri, 24 Feb 2012 14:20:52 -0700

> functionality, and therefore would qualify as an "enhancement"?

I agree with your interpretation as regards specification documentation 
errors vs. design refinements.

In SPF v1, there seems at least a case for keeping and supporting the RR 
specifically allocated for SPF by the good folks who shepherd the DNS RR 
allocations.

While others argue that the TXT record is currently the most widely 
published and that the SPF is not always selected first, perhaps that 
comes from the history of the implementation of SPF, which started 
before the SPF RR was ever approved and implemented in BIND DNS and 
later in other such DNS server software.

Going forward, I think that it makes sense to keep to the implementation 
recommendations in the SPF experimental draft (i.e., one should check 
for SPF RR then TXT RR).  Over time, I think it was the hope of the 
earlier group working on the specification that folks would transition 
to the SPF RRs when that recommendation was made.  While that may not 
have happened in a broad sense as quickly as had been hoped within the 
SPF publishing or implementer community, perhaps with this SPFbis, we 
are reinforcing what we think is a best practice behavior in 
implementing SPF as a publisher.

Another point brought forward is that often it takes time to get folks 
to move forward on upgrading software versions and making changes to DNS 
authoritative host zone files.  While that is true, it should not negate 
the responsibility of those putting together specifications to point 
folks in the right direction as regards the implementation of SPF RRs in 
their DNS host zone files.

Operationally, I think that keeping the TXT and SPF RRs in sync is not 
really all that hard to do.

Best,

Alan M.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Feb 2012 21:22:06 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, February 24, 2012 1:09 PM
> To: [email-masked]
> see where RFC 4408 says anything at all about which "SHOULD" be queried
> first; perhaps someone can point to the section and paragraph they
> think says that.)

My own read of the accumulated data to date (which I don't assert is the consensus view, though it might be) is that most implementations query SPF and then TXT, or query them approximately simultaneously; meanwhile, most SPF records that exist are of type TXT.  This at least lends support to advocating a client optimization that takes advantage of this, perhaps in an informative statement.  We are, after all, basing this advancement on interoperability experience gained in the last six years.  I think the charter permits that.

One could also acknowledge that that's just how things appear today, and there could be some shift in the direction of publishing type SPF records for some reason as this work and related work evolve.  But that's pretty hard to predict.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Feb 2012 21:24:09 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Commerco WebMaster
> Sent: Friday, February 24, 2012 1:21 PM
> To: [email-masked]

This brings up an interesting question: Although we (as experienced folk) find doing so operationally easy, there are examples of cases where this isn't done.  It is of course hard to determine whether those operators did so intentionally.  Nevertheless, we might think it's hard, but maybe the layperson disagrees.  The question, then, is how that should influence what we produce here.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Feb 2012 13:35:00 -0800

On 2/24/12 1:24 PM, Murray S. Kucherawy wrote:
> > On Friday, February 24, 2012 1:21 PM, Commerco WebMaster wrote:
> >
> > Operationally, I think that keeping the TXT and SPF RRs in sync is
> > not really all that hard to do.
>
>  This brings up an interesting question: Although we (as experienced
>  folk) find doing so operationally easy, there are examples of cases
>  where this isn't done. It is of course hard to determine whether
>  those operators did so intentionally. Nevertheless, we might think
>  it's hard, but maybe the layperson disagrees. The question, then, is
>  how that should influence what we produce here.

Dear Murray,

The suggestion of creating recommendations similar to those found in Dan 
Wing's and Andrew Yourtchenko's draft is good.  This type of advice 
could cover Name and No Data errors generally, while addressing resource 
type selection.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 16:41:22 -0500

No hat, and this is not strictly on topic.

On Fri, Feb 24, 2012 at 09:24:09PM +0000, Murray S. Kucherawy wrote:
> it's hard, but maybe the layperson disagrees.  The question, then,
> is how that should influence what we produce here.

Frankly, a lot of the reason for difficulty with DNS administration
(in this case, keeping SPF and the corresponding TXT records in sync,
but there are lots of other issues, such as proper zone transfer
hygeine, SOA serial handling -- anything you like) just comes down to
the same miserable toolchain that people have for maintaining DNS
zones.

Large numbers of operators still, as far as I can tell, use manual
entry and cut and paste and so on as the main tools for maintaining
their zones.  A surprising number of people don't even have automatic
check-ins to revision control in order to go back if something is
broken.  And a terrible number of DNS interfaces are just web pages
with forms in them: you _couldn't_ do good change control even if you
wanted to.

With that being the way zones are maintained, it is no wonder that
people don't use the SPF (or any other specialized) record.  It is,
however, also a possible reason why just falling back to TXT records
are dangerous: because TXT can't possibly have strong error-checking
rules attached to it in a general-purpose DNS maintenance system, it's
easy to break things with TXT where it should be hard if you have
well-defined data types.

The overall situation for "layperson" DNS operators is, frankly,
depressing no matter which way you turn.  Boo hiss.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Philip Gladstone <[email-masked]>
Date: Fri, 24 Feb 2012 17:00:50 -0500

On 2/24/2012 2:47 PM, S Moonesamy wrote:
> Objections to this determination of consensus need to produce evidence 
> that the feature is not used, or that the removal of TYPE 99 is an 
> enhancement that has already gained widespread support.  Please 
I agree with the conclusion as it is based on real data.

Philip

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 17:42:16 -0500

On Friday, February 24, 2012 08:34:36 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Andrew Sullivan Sent: Friday, February 24, 2012 12:32 PM
> > To: [email-masked]
> > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE
> > (issue #9)> 
> I think it qualifies under the clause "addition of any enhancements that
> have already gained widespread support", if we can show that most of the
> SPF record publications use TXT.  We are thus guided by the implementation
> we observe.

I think we've already established that.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 17:47:27 -0500

> queried first; perhaps someone can point to the section and paragraph

There aren't any. The ones that query TXT "first" query only TXT because 
there's no point in a second query for Type SPF.  Domains that don't publish 
Type TXT won't be publishing Type SPF, so to expend remote resources to 
respond to such pointless queries borders on abusive.

> of changes afterward, as an update at PS or during advancement to IS.

I think this one is unique because it has no negative interoperability 
impacts.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 17:49:40 -0500

On Friday, February 24, 2012 09:22:06 PM Murray S. Kucherawy wrote:
> > Of Barry Leiba Sent: Friday, February 24, 2012 1:09 PM
> > To: [email-masked]
> > >> order.
> My own read of the accumulated data to date (which I don't assert is the
> consensus view, though it might be) is that most implementations query SPF
> and then TXT, or query them approximately simultaneously; meanwhile, most
> SPF records that exist are of type TXT.  This at least lends support to
> advocating a client optimization that takes advantage of this, perhaps in
> an informative statement.  We are, after all, basing this advancement on
> interoperability experience gained in the last six years.  I think the
> charter permits that.
> 
> One could also acknowledge that that's just how things appear today, and
> there could be some shift in the direction of publishing type SPF records
> for some reason as this work and related work evolve.  But that's pretty
> hard to predict.

This is why I suggest specifying the query most likely to succeed be done first 
if they are done is series.  Today that would clearly be the TXT query, but it 
is not impossible that this would change in the future.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 17:50:50 -0500

On Friday, February 24, 2012 09:24:09 PM Murray S. Kucherawy wrote:
> > Of Commerco WebMaster Sent: Friday, February 24, 2012 1:21 PM
> > To: [email-masked]
> > (issue #9)
> This brings up an interesting question: Although we (as experienced folk)
> find doing so operationally easy, there are examples of cases where this
> isn't done.  It is of course hard to determine whether those operators did
> so intentionally.  Nevertheless, we might think it's hard, but maybe the
> layperson disagrees.  The question, then, is how that should influence what
> we produce here.

It depends on the goal of the working group.  Do we want something that's 
architecturally pure or something that can reasonably be deployed at internet 
scale?

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 17:57:26 -0500

On Fri, Feb 24, 2012 at 05:47:27PM -0500, Scott Kitterman wrote:

> there's no point in a second query for Type SPF.  Domains that don't
> publish Type TXT won't be publishing Type SPF, so to expend remote
> resources to respond to such pointless queries borders on abusive.

As a matter of clarification: by "won't be publishing", do you mean to
be predicting the future, to be claiming what they do now (which seems
to be the evidence we have), or to be claiming what they ought to do?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 18:00 -0500

> to be the evidence we have), or to be claiming what they ought to do?

I'm trying to describe present practive.

There's zero value in a Type SPF query after a Type TXT query.

Scott K

---

From: Paul Midgen <[email-masked]>
Date: Fri, 24 Feb 2012 23:27:13 +0000

If I take the meaning of "unused features" to be applied to an aspect of SPF that does not factor materially into the successful daily operation of SPF, having had 6+ years to establish such a presence, a preliminary survey of 1000 domains randomly chosen from Hotmail's SPF record cache does not find a single DNS type 99 record.

In the interest of being thorough, I'm running three tests:

- two sets of 10,000 domains chosen at random from a Sept'11 snapshot of the SenderID cache, and one from today's snapshot

- the top 10,000 domains by sending volume as seen by Hotmail today

Where the test consists of identifying which domains publish TXT, SPF, or both. It should be done by Monday (I have to fly under the radar or corp IT will boot me off the network).

Regardless of software support for querying type 99 records, if they aren't published I have a hard time qualifying the feature as "used".

-p

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
Sent: Friday, February 24, 2012 11:48 AM
To: [email-masked]
Cc: [email-masked]
Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9)

Hello,

Empirical evidence so far seems to indicate that there is a significant amount of DNS queries for the SPF RR (TYPE 99) and some sites publish it.  We have seen arguments in favour of removing the feature, and in favour of retaining it.

Our charter says this:

Therefore, the WG Chairs would like to close Issue #9 with the conclusion that the SPFBIS WG does not have consensus to remove the feature.

Objections to this determination of consensus need to produce evidence that the feature is not used, or that the removal of TYPE 99 is an enhancement that has already gained widespread support.  Please remember that the desirability of the removal of the feature is not
enough: the charter restricts our freedom to do what we want here.

Best regards,

_______________________________________________
spfbis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spfbis

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Feb 2012 18:50:58 -0500

A major point missing is that there was a period where it wasn't 
feasible to do type 99, not because their not be a record behind it, 
but simply because it just won't get through!

See RFC3597.  This issue was well known and guess what? Microsoft was 
a major part of volume of servers that did not support SRV, IXFR 
needed for AD or any new RR types in DNS 4.0.  AD would not taken off 
until DNS 5.0 came and people started to migrate it.  Ask any of the 
MVP for DNS/AD like Ace Fekay about it.

Even if we wanted to use SPF type with SPF published records, it just 
wouldn't work - period. What I am missing here?

Not until DNS servers updated would it can conceivable to work, and in 
the Windows world people needed to move from DNS 4.0 to 5.0 and even 
then, nor SRV or AD force the issue until one of the past infamous 
port 445 DoS attacks occurred and with no MS answer for 4.0, only then 
did you many DNS 4.0 operators, perhaps reluctantly, finally make the 
switch - I was one of them. No DoS. No Switch.

But after the switch, only then was it possible to consider AD, XMPP 
installation worked better now. Only then did the ideas of once again 
exploring new protocols with SRV and other types did it become more 
feasible to consider.

If it wasn't for the DoS, I just guessing, we might be having a 
different set of events here. :)

---

From: Paul Midgen <[email-masked]>
Date: Sat, 25 Feb 2012 00:42:21 +0000

The salient point is that lacking widespread customer demand, some enterprise software vendors will not implement a thing. That is correct, but that isn't the point.

If the feature is truly unused, it may still make sense to include a provision for a proper SPF record because it is architecturally correct/right/responsible to do so, and that will imply the need for language in the spec reflecting the WGs opinion on the matter, how to properly query both types, and so on.

By my proffered definition of "unused", the data I've seen so far doesn't support inclusion. I leave it to those with more experience/subject matter expertise to make the appropriate architecture (DNS, internet, etc.) based call.

-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Friday, February 24, 2012 3:51 PM
To: Paul Midgen
Cc: S Moonesamy; [email-masked]; [email-masked]
Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9)

A major point missing is that there was a period where it wasn't feasible to do type 99, not because their not be a record behind it, but simply because it just won't get through!

See RFC3597.  This issue was well known and guess what? Microsoft was a major part of volume of servers that did not support SRV, IXFR needed for AD or any new RR types in DNS 4.0.  AD would not taken off until DNS 5.0 came and people started to migrate it.  Ask any of the MVP for DNS/AD like Ace Fekay about it.

Even if we wanted to use SPF type with SPF published records, it just wouldn't work - period. What I am missing here?

Not until DNS servers updated would it can conceivable to work, and in the Windows world people needed to move from DNS 4.0 to 5.0 and even then, nor SRV or AD force the issue until one of the past infamous port 445 DoS attacks occurred and with no MS answer for 4.0, only then did you many DNS 4.0 operators, perhaps reluctantly, finally make the switch - I was one of them. No DoS. No Switch.

But after the switch, only then was it possible to consider AD, XMPP installation worked better now. Only then did the ideas of once again exploring new protocols with SRV and other types did it become more feasible to consider.

If it wasn't for the DoS, I just guessing, we might be having a different set of events here. :)

---

From: Philip Gladstone <[email-masked]>
Date: Fri, 24 Feb 2012 19:54:05 -0500

> Where the test consists of identifying which domains publish TXT, SPF, or both. It should be done by Monday (I have to fly under the radar or corp IT will boot me off the network).
When I did my tests, I didn't fly under the corporate radar and I got 
asked by our IT guys whether I was doing some DNS testing or whether my 
machine was infected with malware (I was looking up records belonging to 
malware C&C domains).

Philip
>
> -- 
> Philip Gladstone
> Distinguished Engineer
> Product Development
> [email-masked]
> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
> Google: +1 978 800 1010
> Ham radio: N1DQ

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Feb 2012 21:54:36 -0500

> By my proffered definition of "unused", the data I've seen so far doesn't support inclusion. I leave it to those with more experience/subject matter expertise to make the appropriate architecture (…

That would be pretty much be all of us.  The infrastructure based call 
was made to help lower the impact SPF received may have by using TXT 
records by using its own RR record.  All the short term hiccups were 
acknowledged and long term engineering considerations were made. All 
done in the name of improvement its implications on DNS, and I don't 
mind saying, to help win IETF endorsement where there was and probably 
still is much resistance with whats considered a "Kludge" solution. 
So all the engineering was considered and what we are finding out now, 
we were right on.

So I have a sense that if we negate all these infrastructure goals by 
dropping type 99, I somehow feel we are not doing SPF a service come 
the IETF/IESG reviews and endorsement among the DNS community.

I don't know, how to read these guys these days. People change, more 
empathetic, settle on thing and may just feel - don't break what seems 
to be working.  :)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Feb 2012 03:28:54 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Friday, February 24, 2012 6:55 PM
> To: Paul Midgen
> Cc: [email-masked]; [email-masked]; S Moonesamy
> > By my proffered definition of "unused", the data I've seen so far
> > doesn't support inclusion. I leave it to those with more
> > experience/subject matter expertise to make the appropriate
> > architecture (DNS, internet, etc.) based call.
> 
> That would be pretty much be all of us.

I'm sorry, but this is two things: false and rude.

Let's all take a moment to re-read the co-chairs' "comportment" message, please.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Feb 2012 03:30:13 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Gladstone
> Sent: Friday, February 24, 2012 4:54 PM
> To: [email-masked]
> > Where the test consists of identifying which domains publish TXT,
> > SPF, or both. It should be done by Monday (I have to fly under the
> > radar or corp IT will boot me off the network).
> 
> machine was infected with malware (I was looking up records belonging
> to malware C&C domains).

Funny; in running mine, I've noticed that after the first chunk of the test space is run, it gets a lot slower.  I wonder if somewhere upstream I'm being DNS rate-limited.

Slightly off-topic, I know, but curious that we all have the same issue.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Feb 2012 22:43:55 -0500

> Let's all take a moment to re-read the co-chairs' "comportment" message, please.

Wow. I must completely stupid because I didn't think it was false nor 
rude. I really don't and I would like to hear it from people like 
Barry Leiba to explain to off list how I was rude. I seriously and 
honestly don't see how I was out of line with that.

I am sorry to see that I continue to be a target of yours.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Feb 2012 06:08:56 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Midgen
> Sent: Friday, February 24, 2012 3:27 PM
> To: S Moonesamy; [email-masked]
> If I take the meaning of "unused features" to be applied to an aspect
> of SPF that does not factor materially into the successful daily
> operation of SPF, having had 6+ years to establish such a presence, a
> preliminary survey of 1000 domains randomly chosen from Hotmail's SPF
> record cache does not find a single DNS type 99 record.

That sample size might be enough to avoid seeing any instances.  The active polling I'm doing has checked 29088 domains so far and found only 29 type 99 records, so as luck would have it your ratio is approximately such that one more might've found a single hit.  :-)

Can you characterize the cache at all in terms of size or duration caps?  Or is it basically a DNS cache?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Feb 2012 06:43:21 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, February 24, 2012 2:50 PM
> To: [email-masked]

I'd prefer to see it removed.  I agree with the idea of trying to advance a cleaner specification, and removing something only half of the installed base (and a very specific half at that) is using after all this time seems to me like it should qualify.

However, if the ruling is that even client-only use of a feature "counts" in terms of being in use, or if in any case we don't have consensus to make that change, then I think adding some good operational advice like this in an appendix is a reasonable path forward on this issue.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2012 07:21:15 -0000

>Personally, I think Type SPF could be removed as a mistake, so I don't
>think we are inherently limited by the charter.

I agree.  Looking at my logs, most queries for type SPF records come
from a handful of large mail systems which also look for TXT, notably
Yahoo and Godaddy.  I see no evidence that anyone queries SPF who
doesn't also query for TXT, either at the same time or or if the type
99 fails.

We know of two bad things about type 99 records: they offer an
opportunity to screw things up if somone's SPF and TXT records don't
match, and for many clients they double the DNS traffic.  We don't
know of anything good about them in practice, since everyone has to
publish TXT records anyway.

My preference would be to deprecate them.  You can publish them or
query them if you really want, but our new advice is that you SHOULD
just publish TXT and you SHOULD just query for TXT.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 25 Feb 2012 11:08:34 +0100

On 24/Feb/12 22:20, Commerco WebMaster wrote:
> to move forward on upgrading software versions and making changes to
> DNS authoritative host zone files.  While that is true, it should not
> negate the responsibility of those putting together specifications to
> point folks in the right direction as regards the implementation of
> SPF RRs in their DNS host zone files.

We should realize that seven years has been plenty of time for the
real world out there to give a response.  Actually, it did.  The
outcome of this experiment was already clear to those who specified
DKIM, ADSP, VBR, and similar, based on SPF experience.  SPF is not
famous for its ease at getting standardized, and I see no reason why
it should be the one protocol that takes upon itself the burden of
questing this DNS conundrum, most likely at the expenses of its own
success.

> really all that hard to do.

Defining RRs for helo names is even easier.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 25 Feb 2012 19:39:14 +0100

Hi, Murray,

On 2/25/12 7:08 AM, Murray S. Kucherawy wrote:
> That sample size might be enough to avoid seeing any instances.  The active polling I'm doing has checked 29088 domains so far and found only 29 type 99 records,

and all 29 have both type 99 _and_ TXT records, I presume?

/rolf

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 25 Feb 2012 11:19:13 -0800

> Let's all take a moment to re-read the co-chairs' "comportment" message, please.

I'd rather see a moment taken to enforce it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Feb 2012 14:23:40 -0500

On Saturday, February 25, 2012 11:19:13 AM Dave CROCKER wrote:
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Hector Santos Sent: Friday, February 24, 2012 6:55 PM
> >> To: Paul Midgen
> >> (issue #9)>> 

I think it was unintentional.  I didn't interpret it in a negative way when I 
first read it.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 25 Feb 2012 11:24:11 -0800

> That sample size might be enough to avoid seeing any instances.  The active polling I'm doing has checked 29088 domains so far and found only 29 type 99 records,

I'm not very good at math, but I do think yours and Paul's research involves 
sufficiently large sample size to be reasonably suggestive of what is true for 
the "population" of relevant DNS names.  (As I recall, for regular surveys about 
a single objective, binary characteristic, a sufficiently random sampling only 
needs about 113 data points to represent the population of the US.)

I believe the summary of your findings is that the SPF record is present in:

     0.0 - 0.1%

of the domains.

d/
-- 

   Dave Crocker

---

From: S Moonesamy <[email-masked]>
Date: Sat, 25 Feb 2012 11:27:02 -0800

Hello,

This case is unusual.  There has been comments about what is an unused feature.

  (i)   Is the DNS RR of type SPF, code 99, an optional feature in
        implementations of RFC 4408?

  (ii)  Is the DNS RR of type SPF, code 99, optional for a SPF-compliant
        domain name?

  (iii) Is there an interoperability problem when the DNS RR of type SPF,
        code 99, is used?

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Paul Midgen <[email-masked]>
Date: Sat, 25 Feb 2012 20:10:01 +0000

For what it's worth, and not intending to contradict the 113 data-points statement, we've learned (internally) that the minimum bar for a statistically reliable sample is 10,000 messages, where 100,000 is viewed as unimpeachable but generally total overkill.

Two of my queries completed overnight and support your conclusion.

Of 19729 domains surveyed:

Neither	: 8174
SPF-only	: 14
TXT-only	: 11332
Both		: 209

In terms of percentages:

Neither	: 41.43% of surveyed domains
SPF-only	: 0.07% of surveyed domains; 0.12% of publishing domains
TXT-only	: 57.44% of surveyed domains; 98.07% of publishing domains
Both		: 1.06% of surveyed domains; 1.81% of publishing domains

Given the nature of this sample (randomly chosen domains, no additional bias) the "publishing domains" values should be given more weight.

The potential errors in the data are that the domain list was not scrubbed to remove long-tail  or "bad" senders such as low-volume, spam hosts, bots, etc., and there is no comparison (yet - hoping the chairs leave this open long enough to get that data) with a top-10k domain list based on delivered volume (e.g. "mail that matters").

-p

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Saturday, February 25, 2012 11:24 AM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9)

On 2/24/2012 10:08 PM, Murray S. Kucherawy wrote:
> That sample size might be enough to avoid seeing any instances.  The 
> active polling I'm doing has checked 29088 domains so far and found 
> only 29 type 99 records,

I'm not very good at math, but I do think yours and Paul's research involves sufficiently large sample size to be reasonably suggestive of what is true for the "population" of relevant DNS names.  (As I recall, for regular surveys about a single objective, binary characteristic, a sufficiently random sampling only needs about 113 data points to represent the population of the US.)

     0.0 - 0.1%

of the domains.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 25 Feb 2012 12:22:26 -0800

i've changed the Subject since this at least somewhat off topic.

> For what it's worth, and not intending to contradict the 113 data-points statement, we've learned (internally) that the minimum bar for a statistically reliable sample is 10,000 messages, where 100…

My training was for psych experimentation and I can't find a citation that says 
anything like the 113 number I quoted.

I did find something with numbers of the /type/ I meant:

    <http://www.measuringusability.com/survey-sample-size.php>

where psych research tends towards the 5% margin of error.  The URL points to 
381 for that.

But I'm more interested that it says 9600 for 1%.  That sounds suspiciously like 
10,000...

On the other hand, it does not really permit reporting fractions of a percent 
for the result.  Maybe halves of percent, but not, IMO, as fine as tenths of a 
percent.

I suspect that requires a sample size of at least 30,000, if I'm reading the 
trending on the table correctly...

d/

-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Sat, 25 Feb 2012 13:27:18 -0800

At 12:10 25-02-2012, Paul Midgen wrote:
>The potential errors in the data are that the domain list was not 
>scrubbed to remove long-tail  or "bad" senders such as low-volume, 
>spam hosts, bots, etc., and there is no comparison (yet - hoping the 
>chairs leave this open long enough to get that data) with a top-10k 
>domain list based on delivered volume (e.g. "mail that matters").

Thanks for the data.  Even if an issue is closed, it can be reopened 
if there is new data which points to an incorrect conclusion.  It's 
up to the WG participants to consider the data and draw their 
conclusions.  I try to get a sense of the consensus.

As an off-topic note, I have seen some comments on this thread which 
are non-technical.  If you consider a comment as inappropriate, you 
can send a private message to the WG Chairs ([email-masked]).

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Sat, 25 Feb 2012 20:28:36 -0500

My opinion:

Since type 99 is still now part of the SPF-BIS process, I believe it 
promotes any issue (currently cataloged or needs to be created) that 
relates to the SPF-BIS recommended dual type look up algorithm to be 
codified in the spec.  I think issue #25 currently comes close to 
that, but it may need a new issue proposal for a new specific section.

SM wrote:
> Thanks for the data.  Even if an issue is closed, it can be reopened if 
> there is new data which points to an incorrect conclusion.  It's up to 
> the WG participants to consider the data and draw their conclusions.  I 
> try to get a sense of the consensus.
> 
> As an off-topic note, I have seen some comments on this thread which are 
> non-technical.  If you consider a comment as inappropriate, you can send 
> a private message to the WG Chairs ([email-masked]).
> 
> Regards,
> S. Moonesamy
> SPFBIS WG co-chair
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Feb 2012 01:39:15 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
> Sent: Saturday, February 25, 2012 10:39 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Hi Rolf,

> and all 29 have both type 99 _and_ TXT records, I presume?

With over 87000 domains checked in this run, so far I have 47970 publishing type 16 and 83 publishing type 99, with zero publishing both.

At this rate it'll probably take a few more days to check all of the domains it plans to check.

The interesting thing I forgot to mention thus far is that the set of domains it's checking is basically "any domain for which at some point in the last 18 months I got an SPF 'Pass' result."  It's curious that about half of them now aren't showing records at all.

(Well, maybe it's spammers, in which case it's not that curious.)

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Feb 2012 06:48:35 +0000

> Sent: Saturday, February 25, 2012 11:27 AM
> To: [email-masked]

The implementation I did with a colleague back in about 2006-2008 never checked type 99 records because the "T_SPF" mnemonic in the UNIX include file <arpa/nameser.h> wasn't defined.  At the time we chose only to query things for which the nameserver code apparently included native support.  RFC4408 says you do one, the other, or both, and if doing both, you MAY do them in parallel.  Thus, this choice was compliant with the specification.

A quick look at the online source repository for FreeBSD and a recent Linux installation shows they still don't define T_SPF or the newer variant (ns_t_spf), years later.

>   (ii)  Is the DNS RR of type SPF, code 99, optional for a SPF-compliant

Section 3.1.1 of RFC4408 says:

   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.  A compliant domain name MUST have a record of at least one
   type.  If a domain has records of both types, they MUST have
   identical content.  

Your question used "optional", which of course is an RFC2119 word.  :-)  Using it in its English sense and not that sense, yes, it's optional; you're still compliant if you don't use it.

>   (iii) Is there an interoperability problem when the DNS RR of type SPF,

Barring errors, clients that query for them almost always get an RCODE 3 reply.  This causes them to add a negative cache entry, whether or not the TXT query was done in parallel.  This seems wasteful since we know it's almost never there; such cache entries would better serve other purposes.  The clients then fall back to TXT queries, which works fine and is actually there in all the other cases where the domain publishes something.

The few servers that do post them do get good interoperability, of course, but apparently this is very unusual, probably because of the weak provisioning systems Andrew and John alluded to earlier.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Feb 2012 06:55:39 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Saturday, February 25, 2012 10:49 PM
> To: [email-masked]
> The implementation I did with a colleague back in about 2006-2008 never
> checked type 99 records because the "T_SPF" mnemonic in the UNIX
> include file <arpa/nameser.h> wasn't defined.  At the time we chose
> only to query things for which the nameserver code apparently included
> native support.  RFC4408 says you do one, the other, or both, and if
> doing both, you MAY do them in parallel.  Thus, this choice was
> compliant with the specification.

This raises an interesting question, now that I think of it.

RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and MUST use at least one type.  It also (Section 4.4) says that clients can query one type, the other type, or both.

Doesn't that mean that a server that publishes only TXT, and a client that queries only for SPF, or vice-versa for that matter, are both fully compliant but will never actually interoperate?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Feb 2012 06:59:46 +0000

> enough: the charter restricts our freedom to do what we want here.

Respectfully, I think we need a little more time to talk about this.

The curious thing is that the question of "used" in our processes is ambiguous.  Type 99 is very clearly used widely by clients and very clearly not used widely by servers.  Does it count as "used" when clients are asking but the servers aren't answering?  Is the relatively tiny intersection of the two enough to establish a statement of interoperability and sufficient deployment to warrant keeping it?

I'm trying to think of any examples of other protocols that have faced this question in the past and use them to guide our own resolution, but I can't come up with any yet.

I believe Dave pointed out that if we were to try to advance a protocol from Proposed Standard under those conditions, there would likely be some challenges raised.  Whatever we decide, we should be prepared to answer them.

I just brought up a couple of related issues elsewhere in this thread as well.

Thanks,
-MSK

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Feb 2012 03:11:29 -0500

My opinion:

This is the sort of items that needs to be cleared up in SPF-BIS. I 
always thought it was well understood is was a migration issue. If its 
not already stated somewhere in the spec, a domain using SPF type 
published records only would not get widest support due the well known 
RFC3597 issues. It will surprising to me to see if there are a high 
number of SPF type only records.

It would be similar with DKIM's SHA1 vs SHA256 migration issue and we 
will need the same type of language.  Technically, a signer that only 
used SHA256 did not reach the widest support because some early 
desktop OSes like Windows XP with the CAPI API, did not offer it 
(SHA256) until much later after the chinese SHA1 exploit was published 
and Microsoft finally added  SHA256 support under a security patch.

Regardless, I think the same type of migration language as you have in 
DKIM is needed for SPF-BIS for the dual type supported client.

Borrowing DKIM text:

    SPF Publishers MUST implement and SHOULD use SPF RR Type
    SPF Verifiers MUST implement both SPF and TXT RR type queries.

I think you get the idea and you would be better at structuring the 
text with the recommended order and perhaps expanding a little about 
using async or parallel methods but I believe async needs to match how 
two sync sequential calls should work.

The query MUSH|SHOULD start with SPF type first. If it fails (what is 
fail here?) fall back to TXT.  Whether its done sync or async, IMO, 
the end result we want needs to be the same.

Finally, on the flip side, like DKIM, because of this, some just don't 
bother and just use SHA1 and that will give 100% verifier support.

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Feb 2012 03:15:29 -0500

This is and always was a migration consideration in my opinion.

I will treat the issue in the same way done with DKIM in regards to 
SHA1 vs 256.  The publisher is expect to do the most optimal thing for 
migration and the client need to be prepared for both.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Feb 2012 03:20:50 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>Behalf Of Murray S. Kucherawy
>RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and
>MUST use at least one type.  It also (Section 4.4) says that clients
>can query one type, the other type, or both.
>
>Doesn't that mean that a server that publishes only TXT, and a client
>that queries only for SPF, or vice-versa for that matter, are both
>fully compliant but will never actually interoperate?
>
That is exactly what it means.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Feb 2012 03:31:54 -0500

>the end result we want needs to be the same.

This is based on wishful thinking.

MUST/SHOULD Type SPF first is a wasteful design approach meant use a spec to push people to do something operationally suboptimal in order to satisfy some theoretical architectural construct.

The reason some domains publish Type SPF only is that RFC 4408 gives them absolutely no hint that's a bad idea.  For 4408bis we should be honest and provide realistic guidance.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Sun, 26 Feb 2012 10:49:17 -0500

Murray says...
> MUST use at least one type.  It also (Section 4.4) says that clients can
> query one type, the other type, or both.
>
> Doesn't that mean that a server that publishes only TXT, and a client that
> queries only for SPF, or vice-versa for that matter, are both fully
> compliant but will never actually interoperate?
>

 Scott says...

> The reason some domains publish Type SPF only is that RFC 4408 gives them
> absolutely no hint that's a bad idea.  For 4408bis we should be honest and
> provide realistic guidance.
>

These two statements make a pretty compelling case that there is, indeed,
an error in RFC4408.  There are, of course, multiple ways to resolve it,
and I have no immediate opinion on which is best.

Barry, participant

---

From: Dotzero <[email-masked]>
Date: Sun, 26 Feb 2012 11:10:14 -0500

On Sun, Feb 26, 2012 at 10:49 AM, Barry Leiba <[email-masked]> wrote:
> These two statements make a pretty compelling case that there is, indeed, an
> error in RFC4408.  There are, of course, multiple ways to resolve it, and I
> have no immediate opinion on which is best.
>
> Barry, participant
>

+1

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Feb 2012 16:23:32 +0000

> Sent: Sunday, February 26, 2012 12:32 AM
> To: [email-masked]
> >fail here?) fall back to TXT.  Whether its done sync or async, IMO, the
> >end result we want needs to be the same.
> 
> MUST/SHOULD Type SPF first is a wasteful design approach meant use a
> spec to push people to do something operationally suboptimal in order
> to satisfy some theoretical architectural construct.

It is indeed the case that the DKIM SHA1/SHA256 stuff was intended a transition mechanism.  We've also seen that even newer signers use the old way (gmail.com, for instance, uses rsa-sha1 last I checked).

But also I don't think the DKIM analogy works because both variants of DKIM signing are contained within a single communication mechanism, i.e., the signature header field.  A verifier always gets the signature, and then in analyzing the signature parameters, decides it can't complete the action.  But some interoperability did occur, because there was information exchange at least to that point.  The same is not true for the SPF vs. TXT discussion, where the answer waiting is never seen because a different question is asked.

Changing the normative text but keeping both types would also not address the problem of DNS provisioning systems that can't handle type 99 records.

> The reason some domains publish Type SPF only is that RFC 4408 gives
> them absolutely no hint that's a bad idea.  For 4408bis we should be
> honest and provide realistic guidance.

Any solution we select should include at least that, in my opinion.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 26 Feb 2012 17:10:44 -0000

>Doesn't that mean that a server that publishes only TXT, and a client that queries only for SPF, or vice-versa for
>that matter, are both fully compliant but will never actually interoperate?

Sounds like a bug in the spec to me.  I'd suggest opening an issue,
but the fix is obvious once we decide about type 99.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 26 Feb 2012 09:19:45 -0800

On 2/24/2012 11:47 AM, S Moonesamy wrote:
> Empirical evidence so far seems to indicate that there is a significant amount
> of DNS queries for the SPF RR (TYPE 99) and some sites publish it. We have seen
> arguments in favour of removing the feature, and in favour of retaining it.
...
> Therefore, the WG Chairs would like to close Issue #9 with the conclusion that
> the SPFBIS WG does not have consensus to remove the feature.
>
> Objections to this determination of consensus need to produce evidence that the
> feature is not used, or that the removal of TYPE 99 is an enhancement that has
> already gained widespread support. Please remember that the desirability of the
> removal of the feature is not enough: the charter restricts our freedom to do
> what we want here.

The charter permits removal of unused features.

SPF is widely deployed and has become integral to anti-abuse activities.  It is 
a successful service.

However the SPF RR feature is unused.

Empirical data is consistently showing that it is widely used by clients 
(queriers) but virtually unused by servers (publishers).

A protocol that has essentially nothing but clients is not a 'used' protocol. It 
takes two to tango for this mechanism.

A protocol that has been unused after 6 years and is showing no signs of 
becoming used is not a viable protocol.

Whatever problems are feared about the use of the TXT form of SPF record, they 
have not been demonstrated in six years.

A widely used service, with six years of history, is a stable service.  There is 
no evidence that its current form of use will change, nor any factors 
encouraging that change.

The SPF RR is an unused capability. Removing it is a simplification that is 
straightforward and entirely justified.

Having two mechanisms for the same purpose encourages bugs in code and 
variability in responses.

I object to the characterization that the feature is used.  I object to the form 
of the consensus call.

Remove the feature.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Feb 2012 12:44:03 -0500

John Levine wrote:

>> Doesn't that mean that a server that publishes only TXT, and a client that queries
>> only for SPF, or vice-versa for that matter, are both fully compliant but 
>> will never actually interoperate?
> 

+1.

> and I have no immediate opinion on which is best.

I don't quite see the error part of this, but rather the spec left it 
open ended in how to apply the new "infrastructure based decision" RR 
type being considered.  Seems to be like the right SPF-BIS material to 
write

But right now, I think the question is related to the DNS 
"optimization" decision to even consider it in the first place and 
whether if we should continue to consider it. I don't agree it should 
be solely based on "goal searching" basis of low usage where there is 
clear evidence it is.

In other words, I personally would like to see what the overall IETF 
and DNS community mindset is regarding the general consideration of 
using specific RR types.  It seems the mindset has changed to one that 
using TXT records is perfectly ok to use, coupled with concerns that 
using RR types is just too problematic (not seeing myself how outside 
RFC3597)

If that is the case, then I personally agree, go for the simplicity 
and nix it.

But if the ideal is still there, then I think the maturity of using it 
should continue.

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Feb 2012 13:08:23 -0500

Dave CROCKER wrote:
> SPF is widely deployed and has become integral to anti-abuse 
> activities.  It is a successful service.
> 
> A protocol that has essentially nothing but clients is not a 'used' 
> protocol. It takes two to tango for this mechanism.

If this is the case, then the migration expected is on par; first get 
clients to support it and then declare it safe for publishers to drive 
the (new) road:

       "Ok Folks, the BAR is OPEN, start publishing SPF type records."

---

From: S Moonesamy <[email-masked]>
Date: Sun, 26 Feb 2012 10:17:42 -0800

Hi Dave,
At 09:08 26-02-2012, Dave CROCKER wrote:
>Empirical data is consistently showing that it is widely used by 
>clients (queriers) but virtually unused by servers (publishers).
>
>A protocol that has been unused after 6 years and is showing no 
>signs of becoming used is not a viable protocol.
>
>Whatever problems are feared about the use of the TXT form of SPF 
>record, they have not been demonstrated in six years.
>
>A widely used service, with six years of history, is a stable 
>service.  There is no evidence that its current form of use will 
>change, nor any factors encouraging that change.
>
>The SPF RR is an unused capability. Removing it is a simplification 
>that is straightforward and entirely justified.
>
>Having two mechanisms for the same purpose encourages bugs in code 
>and variability in responses.
>
>I object to the characterization that the feature is used.  I object 
>to the form of the consensus call.
>
>Remove the feature.

Andrew and I will discuss about the objections you raised above.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Feb 2012 20:58:54 +0000

> Sent: Sunday, February 26, 2012 8:10 AM
> To: Barry Leiba
> Cc: [email-masked]
> > These two statements make a pretty compelling case that there is,
> > indeed, an error in RFC4408.  There are, of course, multiple ways to
> > resolve it, and I have no immediate opinion on which is best.
> 
> +1

Assuming we agree on that, then is it reasonable to assume the argument against changing due to the need to touch the installed base is no longer valid?  That is, if we agree there's a bug, then we agree they'll need to upgrade (once we decide what the fix is).

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Feb 2012 17:20:38 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>Behalf Of Dotzero
>Assuming we agree on that, then is it reasonable to assume the argument
>against changing due to the need to touch the installed base is no
>longer valid?  That is, if we agree there's a bug, then we agree
>they'll need to upgrade (once we decide what the fix is).

It's clear there's a bug. I don't think there's any basis for assuming the fix will affect the installed base that have published records that can be expected to be interpreted reliably.

I think anyone publishing Type SPF only is doing it wrong. They were likely led astray by this bug in the spec.

That's not at all the same as removing features that are in use and working as designed.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Feb 2012 18:13:16 -0500

Murray S. Kucherawy wrote:
> It is indeed the case that the DKIM SHA1/SHA256 stuff was intended a transition 
> mechanism.  We've also seen that even newer signers use the old way (gmail.com, 
> for instance, uses rsa-sha1 last I checked).

Yes, and so have many others as well. SHA1 has the widest 
(guaranteed?) support, but overall simpler, lesser overhead.

>  But also I don't think the DKIM analogy works because both variants of DKIM 
> signing are contained within a single communication mechanism, i.e., the 
> signature header field.  

The similarity I believe is the idea of a publisher just using SHA256 
signatures. For the same concerns regarding the expected short term 
dearth of supportive clients , DKIM had a less than desirable "higher 
bandwidth and complexity overhead" consideration for using two 
signatures for operations that looked for the highest security with 
the widest backward compatible lower security support.  Only with 
direct targeting could the single SHA256 signature be effective.

> Changing the normative text but keeping both types would also not address 
> the problem of DNS provisioning systems that can't handle type 99 records.

Would help if you can take a moment to explain this.  Does this relate 
to the known RFC3597 issues, more probable and expected in 
yesteryears?  Is the known early short term issue to be corrected with 
the expected updating of DNS server still a problem today, at the same 
numbers?

If so, then to me, this is a no brainer. If no one expects or believes 
there would also be a significant # of DNS servers that will never 
support the passthru processing of unnamed types, then I believe it 
makes this idea of nixing it much more plausible.

> Any solution we select should include at least that, in my opinion.

Isn't this what SPF-BIS is looking for? To codified the parts that 
isn't well understood or needs to better explain all trade offs?

For me Murray, I would like to see if you can find out what is the 
general IETF/DNS community attitude today about using specific RR 
types for new protocols because I thought one of the reasons for 
considering it was to help with the IETF/DNS endorsement with the 
"presumed, perceived" idea it would fit better for large scale DNS 
usage.  Has that changed?

Just seems to me what we expected has materialized, getting the 
clients to support both new and old types first was a prerequisite 
because the spec can comfortable begin suggesting that using SPF type 
published record was technically feasible.  I was really surprise to 
even see there was significant dual type support by the client.  But 
what expected had materialized and I believe SPF-BIS should now go to 
the next step to prepare for the publishing migration.

For the record, I go with either way. Just wish to see a reason that 
is no longer preferred as opposed that no one expected to published 
SPF type records at this point.

Thanks

---

From: Stuart Gathman <[email-masked]>
Date: Sun, 26 Feb 2012 20:08:19 -0500

Long ago, Nostradamus foresaw that on 02/26/2012 12:19 PM, Dave CROCKER
would write:
>
> A protocol that has been unused after 6 years and is showing no signs
> of becoming used is not a viable protocol.
>
You are correct about prospects of active use in v=spf1.  However, I
support keeping it in spfbis for two reasons:

 1) those 1% of publishing domains (including mine) help to keep the
record type healthy and working for v=spf3. 

 2) minimal changes to the SPEC

---

From: Dotzero <[email-masked]>
Date: Sun, 26 Feb 2012 20:40:57 -0500

> Assuming we agree on that, then is it reasonable to assume the argument against changing due to the need to touch the installed base is no longer valid?  That is, if we agree there's a bug, then we…

I think it would be reasonable to make this assumption. It would also
be reasonable to assume that we will see un-upgraded implementations
for quite some time.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 26 Feb 2012 18:29:41 -0800

> support keeping it in spfbis for two reasons:

Just to establish a stable platform: you are agreeing that the RR is 
(essentially) unused.

> record type healthy and working for v=spf3.

I've no idea what you mean by "keep the record type healthy".  Absent some 
indication that this small usage is actually essential to some market segment, 
the nearly-nil adoption means it is not healthy now.

As for v=spf3, there is no such work envisioned, and nothing need be done now, 
to permit adding it later.  Keeping the current SPF RR does not "reserve" or 
"preserve" anything substantive.

>   2) minimal changes to the SPEC

You are invoking a rule that would mean only making changes to things that are 
causing serious problems.  Sometimes, such a rule is appropriate, but this is 
not one of them.

Making the specification cleaner and clearer, by removing (essentially) unused 
features is at least as beneficial as minimizing changes.

d/
-- 

   Dave Crocker

---

From: Stuart Gathman <[email-masked]>
Date: Sun, 26 Feb 2012 22:41:43 -0500

Long ago, Nostradamus foresaw that on 02/26/2012 09:29 PM, Dave CROCKER
would write:
> I've no idea what you mean by "keep the record type healthy".  Absent
> some indication that this small usage is actually essential to some
> market segment, the nearly-nil adoption means it is not healthy now.
>
> As for v=spf3, there is no such work envisioned, and nothing need be
> done now, to permit adding it later.  Keeping the current SPF RR does
> not "reserve" or "preserve" anything substantive.
Support for SPF RR has just appeared in RHEL6 in the last year. 
Adoption of support in server platforms has been slow.  (Yes, you could
use the kludgy TYPE99 in earlier bind versions and code the bytes in
HEX, and I've been doing that with a script to copy SPF TXT records -
but no production shop is likely to do that.)  If you stop the pressure
now, then when we get around to v=spf3, there will *still* be no
supported RR available, and it will be back to TXT records again.  I
would really like to have v=spf3 specify MUST use SPF RR and MUST NOT
use TXT record.

Given that server support is just now appearing in conservative
platforms, it is only now that publishing support could start to pick
up.  And if we drop the RR, all the progress is for naught. 

So I support keeping the SPF RR in spfbis, even if the main benefit is
to have it ready and SUPPORTED for v=spf3.

---

From: "John Levine" <[email-masked]>
Date: 27 Feb 2012 04:19:45 -0000

>up.  And if we drop the RR, all the progress is for naught. 

You're right, but so what?  There are a lot more important RRs than
SPF for the DNS crowd to worry about.

And as I noted several messages ago, even if your DNS server has type 99
support, your provisioning system probably doesn't.

In any event, I thought we were still making the list of issues.  I
know what I think the right thing to do about type 99 is (deprecate
it), but I don't see us coming to agreement now.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Sun, 26 Feb 2012 23:18:48 -0800

Hello,

There are 65 messages posted on this thread.  Let me give you some 
feedback of what I see from the quoted text.  This message is not 
intended to say that X is wrong or Y is right or that argument A is 
correct or B is incorrect.

At 07:49 26-02-2012, Barry Leiba wrote:
>Murray says...
>RFC4408 (Section 3.1.1) says the server side SHOULD use both types, 
>and MUST use at least one type.  It also (Section 4.4) says that 
>clients can query one type, the other type, or both.
>
>Doesn't that mean that a server that publishes only TXT, and a 
>client that queries only for SPF, or vice-versa for that matter, are 
>both fully compliant but will never actually interoperate?
>
>
>  Scott says...

I read the errata posted for RFC 4408 and I added them to the tracker 
as issues.  I did not see any report of an error in Section 3.1.1 of 
RFC 4408.  It is up to this working group to make a compelling case 
that there is, indeed, an error in RFC 4408.  I read the comments 
posted by Murray [1][2] in reply to the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00638.html 
The message by John Levine [3] mentions:

   "Sounds like a bug in the spec to me.  I'd suggest opening an issue,
    but the fix is obvious once we decide about type 99."

Reading that over again, I see that I should have asked him whether 
to open an issue from the above.  I read the message posted by Scott 
Kitterman [4].  For what it is worth, there is also Issue #25 [5] 
where SPF and TXT RRs are mentioned.  As I don't have the faintest 
idea at the moment about Issue #25 (it is not open yet), I cannot 
provide any feedback.  There are some parts of the quoted text on 
which I cannot provide feedback on for now due to the pending objections [6].

Pete Resnick posted a message on February 1 which had an interesting line:

  "Please review the below and see if there is anything that makes 
your head explode."

I should have asked him about that. :-)

He also mentioned [7]:

  "The fact of the matter is that if you all come up with an interpretation
   of this sentence:

     The working group will produce a document describing the course of
     the SPF/Sender-ID experiment, thus bringing that experiment to a
     formal conclusion."

   "If we come up with a reasonable interpretation of that 
deliverable, we'll be
    fine and I will defend it to the hilt."

   "with the caveat that the shepherd and/or I will be doing a 
document writeup,
    and (like the rest of the WG and the chairs, I hope) we will want 
to be able
    to document that the WG did its due diligence to come up with a 
justification
    for the conclusion of the experiment."

My task, in collaboration with Andrew, is to determine consensus not 
override it.  If it is the consensus of this working group that the 
sky is green, that's what goes in the document.  I would like to be 
able to ask for a justification for that conclusion so as to be 
prepared for the questions which will be asked.  If you see me asking 
a question, it is not because I doubt what you are saying.

Regards,
S. Mooneamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00645.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00646.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00657.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00651.html
5. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/25
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00658.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Feb 2012 13:37:48 +0100

On 27/Feb/12 04:41, Stuart Gathman wrote:
> Adoption of support in server platforms has been slow.  (Yes, you
> could use the kludgy TYPE99 in earlier bind versions and code the
> bytes in HEX, and I've been doing that with a script to copy SPF
> TXT records - but no production shop is likely to do that.)

I'd guess they followed the rule to not fix something that is not
broken.  And the protocol works quite well without type 99.

> If you stop the pressure now, then when we get around to v=spf3,
> there will *still* be no supported RR available, and it will be
> back to TXT records again.  I would really like to have v=spf3
> specify MUST use SPF RR and MUST NOT use TXT record.

Or will spf3 use _spf labels?  Possibly, next version of DKIM will
save space by letting data have binary format in its own RR type as
well.  Or maybe not.  That is a DNS issue, not an SPF or DKIM one.

> to have it ready and SUPPORTED for v=spf3.

If DNS will have been fixed by then, it will be easier and more joyful
to conceive a newborn type than to resuscitate a dead one.
(That's a fact of nature :-)

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 10:48:49 -0500

From what I see, the question is really about if we deem the original 
consensus of exploring a new RR type was valid to begin with as an 
IETF/DNS Community endorsement appeasing and technologically better 
fit for DNS large scale usage.

If we still don't believe that goal is no longer valid, that DNS is 
very robust today to any all the TXT junk and the reality is seen as 
such that there are too many RFC3597 servers out there, then perhaps 
we should nix type 99 on this basis.

But the current view is to use highly subjective "Low Usage" and 
"Right Set of Users" and predictions "No one will use SPF type 
records" reasons to nix it.  Thats will always be a form of friction.

Either way, removal means change - moving it into a new state of 
unknowns, chaos, and new instability - using the "right set of users" 
concept to determine the triage impact.

I don't think that will be a proper measurement here. SPF has gain 
world wide support as a NON-IETF developed protocol and its influent 
is strongly due to the super wide support by hobbiest to small 
operations. It was the bigger outfit that got on the bandwagon, not 
the other way around and I suspect that any decision based on "Who's 
Who" in the SPF world, well, is going to create a tremendous amount of 
bad PR for the IETF and contention with the SPF Council.

Its going to be very tough to change and also mandate change by trying 
to retrofit SPF via SPF-BIS to work with AUTH-RES, DMARC, DKIM, 
REPORTING stuff, etc.  Its already a tough challenge to attempt to 
integrate all of this.  So I recognize the challenge it presents.

In regards to the new RR type, I would like to know if that is still a 
valid approach for the sake of lowering SPF impact on DNS and also for 
getting IETF/DNS community endorsement.

If not, then nixing it make its more plausible and comfortable to 
consider, for me.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 27 Feb 2012 10:24:04 -0800

Hi Dave,

There are currently 25 issues listed in the SPFBIS tracker ( 
http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ).  It would take 
at least 50 weeks to process the issues if there is a two-weeks 
consensus call on each and every issue.  The Chairs are of the 
opinion that the working group would not meet the first milestone 
mentioned in the Charter if that path was followed.  However, as the 
Chairs are also responsible to ensure that the working group operates 
in an open and fair manner, we can run a Consensus Call to determine 
whether the working group would like to proceed with a consensus call 
on each issue in the tracker.

Does the above address your objection about "the form of the consensus call"?

Regards.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 13:36:18 -0500

> Does the above address your objection about "the form of the consensus

You've arranged the way the group is to work by serializing the discussion of 
issues.  There are only a handful that are likely to have serious discussion 
or doubt about where the consensus lies, but if the current process is too 
slow for you, have a look in the mirror.

Scott K

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Feb 2012 14:26:43 -0500

Scott Kitterman <[email-masked]> wrote:
>> consensus call on each and every issue.

   (Actually, I'd be happy if I believed this issue would take _only_
two weeks...)

>> The Chairs are of the opinion that the working group would not meet
>> the first milestone mentioned in the Charter if that path was followed.

   That logic _seems_ unassailable...

>> However, as the Chairs are also responsible to ensure that the working
>> group operates in an open and fair manner, we can run a Consensus Call
>> to determine whether the working group would like to proceed with a
>> consensus call on each issue in the tracker.

   Please don't!!!

>> Does the above address your objection about "the form of the consensus

   That is for Dave to say.

> You've arranged the way the group is to work by serializing the discussion
> of issues.

   (This would appear to be addressed to the WGCs, but it might as well
be addressed to Dave, or many of us.)

> There are only a handful that are likely to have serious discussion 
> or doubt about where the consensus lies,

   Speaking for myself, I not merely doubt _where_ consensus on issue #9
lies -- I doubt there _is_ a consensus.

   Understand, I do not doubt how a _vote_ would go: I doubt there is a
"consensus" in the IETF sense -- roughly speaking, "that all opinions
have been fairly presented and considered". I continue to hear new
material presented, and I continue to see many folk claiming it's not
worth considering ideas contrary to their own.

   We can, of course, continue this until we reach "consensus by
exhaustion". IMHO, consensus-by-exhaustion this early in a WG's work
is a recipe for disaster, but I suppose YMMV.

   Or we could move on.

   I have a very simple suggestion for moving on. I've even shared it
with the WGCs, who had no problem with it. I was expecting to post it
today.

   But it doesn't look like we're _willing_ to move on. We seem to
believe that this issue is so important that the other 24 will fall in
place if we just resolve this one.

   I don't understand that belief. Please feel free to enlighten me --
but in private email please.

> but if the current process is too slow for you, have a look in the mirror.

   Again, I suggest it's not only the WGCs that should look in the mirror.

--
John Leslie <[email-masked]>

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 14:52:53 -0500

Well said Mr. Leslie.

It seems to me what is in conflict is the "criteria" used to make a 
decision.

- Evidence of usage, keep it.
- The Wrong set of people using it,  drop it.

and what appears to be a lonely opinion:

- Does DNS say its no longer necessary to consider as envisioned in MARID
   with the idea to lower SPF impact on DNS and increase IETF/DNS 
community
   endorsement.

I would like see this based on DNS based technical merit rather than 
highly subjective ideas that its not used by the right "who's who" in 
the SPF market.

Before the evidence was provided in the WG, I was all for dropping it 
because I thought it was still a RFC3597 problem.  Now, with the 
evidence I am very eager to support it, but if the DNS community 
believes special RR types is still a problem and will always be 
problem, then lets drop it.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 15:09:14 -0500

> - The Wrong set of people using it,  drop it.

I don't know what this means.  I think that it's reasonably clearly 
established that the current usage of Type SPF records is effectively zero and 
there would be no interoperability impact for dropping it.

I think it's fair to argue that it should be kept because we haven't waited 
long enough and that eventually it will get deployment, but I don't think 
there's an argument for an impact to the current SPF userbase.

> community endorsement.

MARID is irrelevant.  It ended without producing any output.  If MARID 
consensus counted for anything, Microsoft would not have been able to push a 
Sender ID design through the IESG that used SPF records for PRA assessment 
(the MARID consensus was not to do that, but to use it from mfrom only).

The appeals of the Sender ID RFCs made it clear even then, that MARID 
consensus is irrelevant.  It hasn't gotten more relevant with age.

> problem, then lets drop it.

There is no support in the commercial DNS market (as far as I know) for 
publishing Type SPF records.  Even though most DNS resolvers support it, the 
provisioning tools that most domains use to manage DNS don't.  That makes it 
effectively not useful on a broad scale.  

I think Type SPF is stuck with a Catch 22.  There won't be broad support in 
provisioning tools until it's broadly deployed and there won't be broad 
deployment until it's in the tools.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Feb 2012 20:10:36 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Leslie
> Sent: Monday, February 27, 2012 11:27 AM
> To: Scott Kitterman
> Cc: [email-masked]
>    Speaking for myself, I not merely doubt _where_ consensus on issue
> #9 lies -- I doubt there _is_ a consensus.

This is why I think we need more time to discuss it.  This is a complicated topic deserving consideration from many angles.  I think we might have enough data, but it's unclear that we've considered fully all the implications of it yet.

If the intent of the "intermediate consensus" call (a new term to me, at least) is to say "OK, let's park this topic and come back to it", I'd be fine with that, but that's not how I read the chairs' message.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Feb 2012 15:35:37 -0500

Dear colleagues,

On Mon, Feb 27, 2012 at 03:09:14PM -0500, Scott Kitterman wrote:
> MARID is irrelevant.

This is exactly right, and I think we've said it before.  The outcome
of MARID and the feelings that led to it are just not topics for this
WG, please.
 
Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Feb 2012 15:37:48 -0500

> If the intent of the "intermediate consensus" call (a new term to me, at least) is to say "OK, let's park this topic and come back to it", I'd be fine with that, but that's not how I read the chair…

I'm sorry that that wasn't clear.  That was exactly what was intended.
We can't determine consensus right now, so the state of consensus is
indeterminate.  It seems clear that the issue requires more time,
especially since there appears to be a serious interoperability issue
in the text as it stands in RFC 4408.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 15:44:25 -0500

On Monday, February 27, 2012 03:37:48 PM Andrew Sullivan wrote:
> > If the intent of the "intermediate consensus" call (a new term to me, at
> > least) is to say "OK, let's park this topic and come back to it", I'd
> > be fine with that, but that's not how I read the chairs' message.

I think that's reasonable.  I totally didn't get that either.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 16:21:46 -0500

> of MARID and the feelings that led to it are just not topics for this

This is not helping.

Please do not focus on reference MARID, but rather what the GUTS was 
in regards of what the main point was.

    The ORIGINAL GOAL and INTENT of using a new RR type.

Before you can even consider abandoning this, it is PRUDENT that 
original intent was in fact wrong.

Its ashame that you wish to FOCUS on something, ignoring what the 
fundamental point being stated to use continue to use this as a form 
of DISSEMINATION.

Please look at what was STATED and answer that fundamental question. 
It was a MARID decision to produce what we have now - RFC4408, to 
ignore all the engineering insight, time and energy put into it is 
well, I can't described nothing short but fundamentally wrong.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 16:28:53 -0500

> well, I can't described nothing short but fundamentally wrong.

No.  It wasn't.  RFC 4408 was an individual submission.

The only reason Type SPF was included was the DNS mafia of the day would have 
prevented the RFC from being published otherwise.  AFAIK there was not 
detailed analysis or other engineering effort to determine if it was needed.  
Reusing TXT was architecturally impure, so we got RFC 4408 approve  by 
pretending the use of TXT was merely transitional.

If we have to play let's pretend about Type SPF again to get 4408bis approved, 
I'm OK with that, but let's be honest amongst ourselves about what's going on.

There is not and never was a case to make the transition happen.  Despite tons 
of effort going into code to support transition, no transition is happening and 
there's no reason to believe that will change.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 16:33:31 -0500

Scott Kitterman wrote:

> MARID is irrelevant.  It ended without producing any output. 

Not true, but less forget MARID.  Read what I stated. The fundamental 
issue
is:

     The original goal and intent to consider new RR type.

You are totally ignoring that fundamental and extremely important 
consideration and until you show IETF/DNS community universal proof it 
is no longer desirable, your criteria for abandoning type 99 is highly 
subjective with no evidence it is correct, when in fact the MARID 
generated decision to include it with all its expected short term 
migration path issues has 100% materialized.

To ignore this extremely important point, well, is exclusion of input 
you don't wish to consider.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Feb 2012 16:39:51 -0500

Hector,

On Mon, Feb 27, 2012 at 04:21:46PM -0500, Hector Santos wrote:

> It was a MARID decision to produce what we have now - RFC4408

No, it was not.  That's exactly why we chairs determined that
discussion of what went on in MARID is not on-topic for this
discussion.

We are _not_ doing a -bis on a WG document.  RFC 4408 is not the
product of any WG.  It's true that MARID did some work on something
similar to what became RFC 4408, but the RFC is not the product of
the working group, as a formal matter of history.  If you don't
believe me, please examine the IETF datatracker data:
https://datatracker.ietf.org/doc/rfc4408/history/.  

I understand the temptation to draw analogies with discussions that
happened in MARID.  In my capacity as co-chair, I'm asking you and
every other participant in this WG not to give into that temptation.
If people can't heed that request, I will have to take it up more
formally; but I would prefer that people govern themselves.

Thanks,

A 

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 16:43:34 -0500

Scott Kitterman wrote:

> prevented the RFC from being published otherwise.  

And where did the DNS "MAFIA" exist? - MARID!  Please, this is getting 
really shamefully chaotic with this denial going on.

To suggest MARID did not have a direct influence in all the RFC 
delivery is simply not true, including, as you admit the "DNS MAFIA" 
force the issue.

So again, forget MARID if you wish, but lets NOT forget the 
fundamental technical valid reasons and considerations was added in 
the first place.

What you are saying it was ALL wrong and flawed to be begin with.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 16:46:27 -0500

On Monday, February 27, 2012 04:43:34 PM Hector Santos wrote:
> > The only reason Type SPF was included was the DNS mafia of the day would
> > have prevented the RFC from being published otherwise.
> 

It was theoretically correct, but of little to no practical utility.  I think 
that's still the case.

I do agree with the statement elsewhere in the thread that we're making little 
progress on this issue and we might better spend out time on others and come 
back to this later.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 16:52:00 -0500

Again, you are ignoring what was stated and I stated it again, this way:

       There is an ORIGINAL RFC 4408 GOAL and INTENT to consider
       type 99 that fundamental was based on WG concerns regarding
       its impact on DNS.

You have ignored this point and the only reason to even reference M A
R I D, is we are forgetting all the wrong done to even thing about
ideas like type 99.

Please stop using threats of excommunications when ignorance is quite
clear on these
critical points.  Rather than ignore it, address it.  Its not my fault
you prefer a position of ignoring input.

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 17:04:33 -0500

> It was theoretically correct, but of little to no practical utility.  I think 

Ok, great! Now I think that should be the central debate because this 
idea of using "Who's Who" is a terrible rat smelling imposition on 
others that don't agree.  Especially if they are not on the "Who's 
Who" list!

If type 99 was originally a bad idea, then it would be a more 
plausible reason to get rid of it.   But if you are following input 
from Patrick on the IETF list, and RFC 5507, I agree with it, a 
decision to abandon it is not only premature, based on subjective 
isolated input.

Again I was all ready to to abandon it, until the evidence has shown 
the that OLD GROUP engineering and migration path thinking was 100% on 
par - to negate this is really an odd thing.

> progress on this issue and we might better spend out time on others and come 

Fine, but it has to be decided at some point and I hope it doesn't 
fall trap to a final situation like in DKIM where people started to 
say about the charted delivery goal for ADSP,  - "We are tired, just 
forgot about and let someone else worry about it"

If that is what you hope, you might just get it.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 27 Feb 2012 12:48:16 -0800

Hi Dave,

There appears to be a wide variety of opinion about Issue 
#9.  Moreover, the discussion has revealed an interoperability 
concern in the existing RFC.  It seems additional discussion is going 
to be needed to determine what to do about that interoperability 
concern, and therefore we cannot conclude anything right now.  We are 
therefore suspending discussion for the moment on Issue #9.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Feb 2012 23:49:27 +0000

> Sent: Monday, February 27, 2012 12:38 PM
> To: [email-masked]

Thanks for the clarification.  Next topic, please.  :-)

(I understand 1, 2, 3, and 8 are open, but SM mentioned that the latter three are chiefly editorial "hold for document update" issues, and it seems to me as if we've already converged on the first.)

-MSK

---

From: Paul Midgen <[email-masked]>
Date: Tue, 28 Feb 2012 01:37:38 +0000

The cache contains about 450k domains based on their sending volume and a few other criteria. It is refreshed every 24 hours. It doesn't strictly mirror DNS; records are stored fully expanded (e.g. A & MX are converted to ip4), and some information is dropped - e.g. spf2.0/mfrom, macros, PTR, etc.

Does that help?

Note that the cache is being replaced with live DNS by the end of March.

-p

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Friday, February 24, 2012 10:09 PM
To: [email-masked]
Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9)

> Behalf Of Paul Midgen

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Feb 2012 09:17:28 -0800

On 2/27/2012 12:48 PM, S Moonesamy wrote:
> There appears to be a wide variety of opinion about Issue #9. Moreover, the
> discussion has revealed an interoperability concern in the existing RFC. It
> seems additional discussion is going to be needed to determine what to do about
> that interoperability concern, and therefore we cannot conclude anything right
> now. We are therefore suspending discussion for the moment on Issue #9.

SM,

Thanks for the followup.  I should note that my message was really meant to do 
two different things.  One was the process concern, which you've resolved.

Of course the deeper issue is getting adequate wg discussion and consensus about 
this part of SPF.

The sequence of brief assertions that my note contained are meant to assert 
specific objective facts and link them in a way that produces a conclusion.

The form of that was/is meant to get reactions to each piece, in the hope that 
that could be more tractable to resolve discrete questions of fact.

For example, I asserted the simple (and intentionally simplistic) view that the 
RR is unused.  Absent data about segmented demographics or indications of wider 
use, I view a usage level of (at best) 1%, with no added functional benefit, to 
be pragmtically equivalent to "unused".

I chose not to add qualifiers, such as "effectively unused", primarily to 
require those who see things differently to argue for the details they see 
differently.

I'm still hoping that this is pursued.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Feb 2012 12:50:30 -0800

> now. We are therefore suspending discussion for the moment on Issue #9.

Responding directly:

I'm a bit chagrined that I missed the basic interoperability flaw in the spec.

However identifying it will probably require that the wg be more clear about 
basic requirements for interoperability.  I'm hoping that that helps us make the 
details simpler.

In any event, thanks for the followup.

d/

-- 

   Dave Crocker

---

From: Stuart Gathman <[email-masked]>
Date: Tue, 28 Feb 2012 21:00:45 -0500

Long ago, Nostradamus foresaw that on 02/26/2012 03:31 AM, Scott
> The reason some domains publish Type SPF only is that RFC 4408 gives them absolutely no hint that's a bad idea.  For 4408bis we should be honest and provide realistic guidance.
Why is it a bad idea? 

1) We've established that most clients query for SPF, so you don't lose
much by not publishing TXT. 
2) You simplify administration because you don't have to keep the two
records in sync. 
3) And you satisfy all those SPF queries instead of wasting them, saving
bandwidth. 

At this point, publishing SPF RR only is a *good* idea!  (And I was
planning to do so as soon as I upgrade my name server platform to RHEL6
- currently I use a script to generate TYPE99 syntax from TXT for older
bind). 

It is only this year that publishing SPF RR became convenient for RHEL
and clones!  Hector tells us that MS platforms have only recently
migrated to DNS 5 which can easily support the SPF RR.   The clients are
on board - the server side was slow in coming, but is now on ready.  It
would truly be a shame to tell people to just forget about it.  It would
be tragic if the SPF RR was then *still* not ready for SPFng as a result.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 22:02:37 -0500

> be tragic if the SPF RR was then *still* not ready for SPFng as a result.

As long as there are clients that don't query for Type SPF (and there are) 
your record gets less exposure in Type SPF than Type TXT.  That is a bad 
thing.

I think using TXT only for v=spf1 and using Type SPF only for some future 
incompatible update makes perfect sense.  For this new future version, now 
that we've spent half a decade laying the groundwork, there would be 
relatively few (compared to 2005/2006) deployment barriers and with no pre-
existing mass of Type TXT records no need to support both.

I don't propose getting rid of the type, just making it SHOULD NOT publish and 
SHOULD NOT check for v=spf1.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 29 Feb 2012 03:06:12 -0000

>SHOULD NOT check for v=spf1.

I'd also be OK with MAY publish but SHOULD NOT check.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 22:07:59 -0500

On Wednesday, February 29, 2012 03:06:12 AM John Levine wrote:
> >I don't propose getting rid of the type, just making it SHOULD NOT publish
> >and SHOULD NOT check for v=spf1.
> 

Yes.  That'd be fine.

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Tue, 28 Feb 2012 21:01:49 -0700

+1.

And, if this all makes sense to the rest of the list, it actually solves 
the apparently dicey problem of getting rid of or not getting rid of the 
SPF RR rather nicely - especially with John Levine's MAY publish suggestion.

Essentially, it puts SPF RR into a kind of stasis, leaving the lives or 
retires call to the future rather than an absolutely something that 
needs addressing in the SPFbis today.

Alan M.