Subject: [spfbis] Issue: SPF RR type

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Feb 2012 22:19:40 -0800

This may be a can of worms,  but since we're chartered to tidy up where appropriate, I wonder if this might be such a spot.

RFC4408 registered a new DNS RRtype, SPF, code 99.

Are we able to tell how much deployment it's received?  If only little (which is what I suspect, but I've no data to back that up), would it be appropriate to relegate its discussion to an appendix and call it "historic"?

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Feb 2012 08:36:47 -0800

Hi Murray,
At 10:19 PM 2/6/2012, Murray S. Kucherawy wrote:
>This may be a can of worms,  but since we're chartered to tidy up 
>where appropriate, I wonder if this might be such a spot.
>
>Are we able to tell how much deployment it's received?  If only 
>little (which is what I suspect, but I've no data to back that up), 
>would it be appropriate to relegate its discussion to an appendix 
>and call it "historic"?

It would help if WG participants could provide data about the 
deployment of the DNS RR as part of the request for empirical data.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Commerco WebMaster <[email-masked]>
Date: Tue, 07 Feb 2012 09:46:13 -0700

Murray,

I would prefer to avoid seeing RRtype 99 being seen as historic. 
Rather, the RRtype should be seen as the preferred RRtype of choice for 
SPF implementations.  This may indeed be even more the case for future 
revs of SPF not addressed in this spfbis process.

There was significant discussion as I recall on the SPF list regarding 
the treatment of RRtype 99 at the time it was approved because of the 
huge levels of adoption of the TXT RRtype for SPF (the only way to 
implement the experiment prior to the issuance of RRtype99).  During 
those discussions I recall the future V3 version of SPF as perhaps 
implementing the notion that RRtype 99 was indeed to become the 
preferred mechanism for describing SPF in DNS.

As such, I would tend to vote against the relegation of RRtype 99 as 
"historic".

Best,

Alan M.

On 2/6/2012 11:19 PM, Murray S. Kucherawy wrote:
> This may be a can of worms, but since we’re chartered to tidy up where
> appropriate, I wonder if this might be such a spot.
>
>
> Are we able to tell how much deployment it’s received? If only little
> (which is what I suspect, but I’ve no data to back that up), would it be
> appropriate to relegate its discussion to an appendix and call it
> “historic”?
>
>
>
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Feb 2012 09:42:35 -0800

At 08:46 AM 2/7/2012, Commerco WebMaster wrote:
>Rather, the RRtype

I prefer not to see any discussion about the issues or reviews that 
have been or will be posted to this mailing list.  As WG Chairs, we 
rely on WG participants to help in making progress nicely.  We would 
like to handle one o two controversies at a time instead of having a 
full-blown discussion about everything.

Let me say it clearly.  When I label a message as coming from the WG 
co-chair and I say "no discussions now", I mean no discussions 
now.  Could WG participants please show some self-restrain by not 
getting into discussions about issues?

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Feb 2012 12:49:11 -0500

Chair hat on.

> I would prefer to avoid seeing RRtype 99 being seen as historic.

Please, no, stop.

Now is _not_ the time, as we have asked repeatedly, to discuss the
merits of the various issues.  There will be an opportunity to discuss
them later.  Now, we are collecting issues, and not debating them.

If we try to debate every issue at once, we will never manage to make
any progress.

Thanks and best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Commerco WebMaster <[email-masked]>
Date: Tue, 07 Feb 2012 11:34:00 -0700

I was simply responding to the question originally started by Murray S. 
Kucharawy regarding the topic.

Perhaps this is a process issue as regards how the bis process operates. 
  My most recent understanding of the process was that Murray was 
originally leading up the effort to get spfbis on track prior to the 
introduction of the co-chairs.  He had introduced the original question 
on this list designed to get spfbis to standards.  He has been here 
serving in that capacity prior to the introduction of chairs to this 
process and apparently continues to make good contributions to the 
spfbis effort.  I worked on the belief that with specific questions 
being posed to the list by facilitators, there was an implicit request 
for answers by list members.

To the spfbis co-chairs: if questions are brought up on the list by 
those generally understood to be process facilitators, how are they to 
be best addressed by list members in future?

Thank you in advance for your guidance in this matter.

Alan M.

On 2/7/2012 10:42 AM, S Moonesamy wrote:
> I prefer not to see any discussion about the issues or reviews that have
> been or will be posted to this mailing list. As WG Chairs, we rely on WG
> participants to help in making progress nicely. We would like to handle
> one o two controversies at a time instead of having a full-blown
> discussion about everything.
>
> co-chair and I say "no discussions now", I mean no discussions now.
> Could WG participants please show some self-restrain by not getting into
> discussions about issues?
>
> Regards,
> S. Moonesamy
> SPFBIS WG co-chair

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Feb 2012 11:00:41 -0800

Hi Alan,
At 10:34 AM 2/7/2012, Commerco WebMaster wrote:
>Perhaps this is a process issue as regards how the bis process 
>operates.  My most recent understanding of the process was that 
>Murray was originally leading up the effort to get spfbis on track 
>prior to the introduction of the co-chairs.  He had introduced the

Murray spearheaded the effort in getting the SPFBIS WG chartered.  He 
has put in a lot of effort in getting the working group on track.

>those generally understood to be process facilitators, how are they 
>to be best addressed by list members in future?

What Andrew and I have been trying to say is: please review RFC 4408 
and post the issues you find to the mailing list.  We will compile a 
list of issues and then start the discussion on them.  We would like 
to tackle one of two controversies at a time as it would be easier 
for us to make progress nicely.

Please do not discuss any question until the WG Chairs send out the 
request for comments.

The SPFBIS WG Charter is at 
http://www.ietf.org/dyn/wg/charter/spfbis-charter  IETF participants 
should also read and understand the Note Well ( 
http://www.ietf.org/about/note-well.html ).

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Feb 2012 14:05:26 -0500

Hi,

> to be best addressed by list members in future?

In the IETF, I don't know what "generally understood to be process
facilitators" means.  If you are not familiar with the way the IETF
works, I encourage you to read RFC 4667, which can be found at
http://www.rfc-editor.org/rfc/rfc4677.txt.  

In this particular case, however, the WG chairs have been asking to
follow one particular methodology: put your issues to the list, but
please don't discuss them yet.  That's what I requested last Friday,
and I think we've tried to be consistent with it.  The "yet" there is
important.  We will have an opportunity to discuss each issue at a
later date, but we don't want to discuss them all now.

As we've now said several times, the goal here is to break the issues
down into manageable chunks, so that we're not struggling with all the
issues at once.  In general, we believe that progress is most likely
to come if we can make progess on individual issues one or two at a
time.

Best regards,

Andrew 

-- 
Andrew Sullivan
[email-masked]

---

From: Commerco WebMaster <[email-masked]>
Date: Tue, 07 Feb 2012 12:24:53 -0700

To our co-chairs,

Thank you both for the clarification and I apologize for not entirely 
understanding current the process.

To that end, perhaps we can have a single thread which lists all of the 
issues to be discussed once the list is assembled.  In this way, we will 
have one spot we can all look to for an understanding of the next phase 
in the process, where comments would be more appropriate.

@Andrew - thank you for the link to RFC 4667.

Best,

Alan M.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Feb 2012 14:50:57 -0500

Hi all,

This is just a (re-re-)re-iteration of how we're trying to run this
process.  This particular part of the process is about capturing
issues with RFC 4408.  I'm not talking here about resolving the
experiment; we'll deal with that in another thread.

On Tue, Feb 07, 2012 at 12:24:53PM -0700, Commerco WebMaster wrote:
> To that end, perhaps we can have a single thread which lists all of
> the issues to be discussed once the list is assembled.

In the first stage, we are collecting issues.  I'd originally imagined
people would post whole reviews of RFC 4408, but instead people seem
to be identifying particular issues they have with it in separate
messages.  That's grand.  Whatever way we collect them is good.  We
asked that people get their issues together by 18 Feb.  Nobody has
objected to that deadline yet.

The plan is that, once we have stopped collecting, we can collate the
issues into a big list.  That big list will go into the tracker (if
you don't know about the issue tracker, visit
http://tools.ietf.org/wg/spfbis.  To use the tracker you need a tools
login.  If you don't know about this, poke me offline and I'll
explain), and we'll post a summary here.  We'll ask for anything we
missed or any distinctions people think we haven't made.  Again, that
will be an opportunity to _identify_ cases, and not to debate their
merits.

Once we have this in hand, then we can pick one or two of the
identified issues _at a time_, and work to resolve them.  This way, we
control the rate at which we have to discuss complicated and
contentious issues, and we can move forward.

All of this was intended to be implicit in the note I sent to the list
last Friday, but I recognize that perhaps it wasn't clear enough.
Hence this note.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Philip Gladstone <[email-masked]>
Date: Tue, 07 Feb 2012 15:09:11 -0500

> deployment of the DNS RR as part of the request for empirical data.
I fetched the SPF RR from each of the 287,000 DNS names (in my database) 
that had an SPF record. Only 4,613 entries returned SPF (type 99) 
records. There were many timeouts (but I didn't count them) as it seems 
that some servers do not respond: azbus.net, kupai.me, togocom.com etc.

Of the 4613 SPF RRs, ~800 do not match the TXT version for the same 
domain. In some cases it is just a whitespace difference or ordering 
difference.

kvsupply.com
TXT: v=spf1 a mx include:kvvet.com ~all
SPF: v=spf1 a mx include:kvvet.com include:kvpetsupply.com ~all

lps.org
TXT: v=spf1 mx ptr ?all
SPF: v=spf1 a:zmta1.lps.org a:zmta2.lps.org ptr ?all

pizza.be
TXT: v=spf1 a mx ip4:82.94.230.23 ip4:213.34.65.131 ip4:213.34.65.132 
ip4:213.34.65.133 ip4:82.94.249.230 ~all
SPF: v=spf1 a mx ip4:82.94.230.23 ip4:213.34.65.131 ip4:213.34.65.132 
ip4:213.34.65.133 ip4:82.94.249.230 include:trustpilot.com ~all

harvardbusiness.org
TXT: v=spf1 ptr a:mail.hbsp.harvard.edu ip4:67.202.196.80/28 
include:hbsp.harvard.edu ?all
SPF: v=spf1 ptr a:mail.hbsp.harvard.edu ip4:67.202.196.80/28 
ip4:74.125.148.0/22 include:hbsp.harvard.edu ?all

Philip

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Feb 2012 12:29:35 -0800

Hi Philip,
At 12:09 PM 2/7/2012, Philip Gladstone wrote:
>I fetched the SPF RR from each of the 287,000 DNS names (in my 
>database) that had an SPF record. Only 4,613 entries returned SPF 
>(type 99) records. There were many timeouts (but I didn't count 
>them) as it seems that some servers do not respond: azbus.net, 
>kupai.me, togocom.com etc.
>

Thanks for providing the data.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 07 Feb 2012 20:29 -0500

> deployment of the DNS RR as part of the request for empirical data.

I'm not sure if this qualifies as data or not, but ...

I'm one of the upstream maintainers of the Python SPF library (pyspf).  Pyspf 
has supported Type 99 since a few days after the type was allocated to SPF.  
Due to complaints about issues with badly acting DNS servers we disabled type 
99/SPF support by default after a short period.  There have been zero 
complaints about it not being enabled by default.  I have reviewed the source 
of the open source users of pyspf and none of them over-ride this setting.

As far as I can tell it's been off for half a decade and no one cared.

I also help maintain a Postfix policy server in Perl that uses the Mail::SPF 
library.  It did, for several years, have even the option to turn off type SPF 
queries.  The Mail::SPF developer added the switch after multiple complaints.  

Based on interactions with multiple open source projects, including large 
Linux distributions like Debian and Ubuntu, all of the feedback from users 
I've heard is that type SPF is a problem and it should not be used.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 Feb 2012 02:40:37 -0800

Hi Scott,
>of the open source users of pyspf and none of them over-ride this setting.

I added this to Issue #9 ( 
http://trac.tools.ietf.org/wg/spfbis/trac/ticket/9 ).

Regards,
S. Moonesamy