Subject: [spfbis] WGLC for draft-ietf-spfbis-experiment

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Apr 2012 16:44:54 -0400

Dear colleagues,

This message begins a 2 week Working Group Last Call on the document
draft-ietf-spfbis-experiment-07.

Please perform a complete review of the document and send your remarks
to the mailing list.

Your chairs would like to be sure that the document really represents
WG consensus in the event we forward the document to the IESG for
publication.  As a result, we would like to see as many reviewers as
possible who state that they have read the document and approve its
publication, and in no case fewer than five.  In the case of those who
have read and reviewed previous versions of the document, we would
like evidence that you are amenable to changes that have been made in
response to your comments; we will count those among the five.
("Five" is an arbitrary number intended to be a minimal threshold of
review; if we can't find five people who say something is a good idea
to publish, it's hard to argue that there's any interest at all.)

SM will be the document shepherd for this document.

This last call closes on 2012-05-09 at 00:00 UTC.

Best regards,

Andrew 

-- 
Andrew Sullivan
[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Apr 2012 14:56:36 -0400

> draft-ietf-spfbis-experiment-07.

I just gave -07 the once-over, and I'm happy.  It's ready.

Barry, participatorily

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 15:21:11 -0400

> Please perform a complete review of the document and send your remarks

I've got one point I really don't like in this draft, but I understand I'm on 
the rough end of the consensus, so +1 from me for publication as is unless 
there's some unexpected groundswell of support for my view on how record reuse 
is described.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 15:21:11 -0400

Scott K

---

From: Dotzero <[email-masked]>
Date: Wed, 25 Apr 2012 16:09:24 -0400

> there's some unexpected groundswell of support for my view on how record reuse

I agree with Scott on the record re-use issue. Leaving this
unaddressed is problematic. I was originally neutral about SIDF and
figured leave well enough alone. Now I believe we need to address
this. Other than this issue I am +1 for publication.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Apr 2012 13:09:58 -0700

> there's some unexpected groundswell of support for my view on how record reuse
Dear Scott,

I agree with your concern.  There is no clean way to avoid Sender-ID 
results other than publishing a replicate SPF record with "spf2.0/mfrom 
(spfv=1 content)" headers.  This header should prevent any Sender-ID 
results from being reported and not just "neutral" results from the 
recommended alternative.  It remains unknown what is the best strategy 
to avoid Sender-ID delivery issues, but it seems Hotmail has found DKIM 
+ SPF provides results as good or better than those using the PRA 
algorithm.  Waiting for adoption of outbound DKIM and removal of PRA may 
still be a long time into the future, but it might also be sooner than 
you might expect.

Regards,
Douglas Otis

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2012 20:36:19 -0000

>there's some unexpected groundswell of support for my view on how record reuse 

I agree with Scott.  It's OK as it is, but we really should say
somewhere (not necessarily this document) that if we're planning to
advance SPF, we should deprecate Sender-ID due to the TXT record
collision issue.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Apr 2012 22:35:26 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dotzero
> Sent: Wednesday, April 25, 2012 1:09 PM
> To: Scott Kitterman
> Cc: [email-masked]
> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment
> 
> I agree with Scott on the record re-use issue. Leaving this unaddressed
> is problematic. I was originally neutral about SIDF and figured leave
> well enough alone. Now I believe we need to address this. Other than
> this issue I am +1 for publication.

Based on the wording you chose here, I'm not certain you and Scott are saying the same thing.

Scott is saying that we're being inaccurate by not being clear that Sender ID made use of the SPF-defined record.  How are you suggesting the experiment document address this, if not simply that clarification?  And I'll pose the same question to you I did to him: What does that change bring to the presentation of adoption data that's missing otherwise?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 19:13:29 -0400

On Wednesday, April 25, 2012 10:35:26 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Dotzero Sent: Wednesday, April 25, 2012 1:09 PM
> > To: Scott Kitterman
> > Cc: [email-masked]
> Scott is saying that we're being inaccurate by not being clear that Sender
> ID made use of the SPF-defined record.  How are you suggesting the
> experiment document address this, if not simply that clarification?  And
> I'll pose the same question to you I did to him: What does that change
> bring to the presentation of adoption data that's missing otherwise?

I am OK with removing the reuse discussion from the draft because it's not 
needed or going back to the more correct description of it (I thought we'd 
agreed to do the former).  I find the current biased description objectionable.

If it's not needed, remove it.  If it's needed, make it correct.  You'll get 
no argument from me with either of those.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2012 23:17:57 -0000

>Scott is saying that we're being inaccurate by not being clear that Sender ID made
>use of the SPF-defined record.  How are you suggesting the experiment document
>address this, if not simply that clarification?  And I'll pose the same question to
>you I did to him: What does that change bring to the presentation of adoption data
>that's missing otherwise?

In the context of this document, I would want to say that although the
data suggest that reused records had only a minor effect in practice,
we did not resolve the issue, and so long as people continue to use
both SPF and Sender-ID, there remains some risk that systems that
intend to publish SPF will inavertently have their mail filtered by
Sender-ID.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 25 Apr 2012 19:53:24 -0400

I don't think I have seen actual cases where there is a conflict.  We 
know of the long time claims, but did the 6+ years of experimentation 
actually show a history of such problems, and further, if record pairs 
were found to be incorrect, is it something that could not be resolved 
by the SIDF implementation? Is there DATA, even if isolated to a few, 
that showed where the conflict claim materialized?

It just sounds to me that the SPF1 44408 only focus overall is 
implying  - don't use our records for any other protocol meaning.  I 
don't think SIDF is doing that, but the burden is on SIDF to make sure 
its protocols do not hurt any SPF1 4408-only deployment.  IMO, the 
4408 only focus with SPFBIS should not be concern about this in the 
same way other non-standard 4408 usages have materialize, such as the 
Best Guess thing, which I just read the other day with one MUAs 
plug-in have used and actually documented it as a NON-4408 standard 
method.

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

Murray S. Kucherawy wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Apr 2012 22:25:00 -0400

> intend to publish SPF will inavertently have their mail filtered by

I believe this doc is meant to present actual results observed in
operation.  Are there results that show that mail has been rejected under
the conditions you describe?  If so, let's absolutely present them.  If
not, I continue to think that speculating on things that aren't seen in
practice is out of place in this document.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 22:35:08 -0400

> practice is out of place in this document.

All I can offer is the anecdotal experience of helping a customer troubleshoot 
a problem where it turned out that there was a case where one domain published 
both v=spf1 and SPF2.0/pra records, but used an include: statement in both 
that included a domain that only had a v=spf1 record.  Either they didn't look 
or assumed that the fallback applied to includes as well.  Mail got rejected 
due to an implementation that quite reasonably (in my opinon) did not use 
v=spf1 records in include: mechanisms of spf2.0 records.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 26 Apr 2012 09:01:37 -0700

> intend to publish SPF will inavertently have their mail filtered by

I believe we have do not have the type of data needed to deal with this 
concern.

Were there greater SID use and more indications of problems due to 
colliding use of the DNS record, it would be worth pursuing.

Given the very low usage leves of SID, I think that worrying about 
problems from the conflict aren't worth the effort.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Apr 2012 10:54:00 -0700

> Please perform a complete review of the document and send your remarks

I have participated in the working group discussions leading to the last 
call and have done a final review on the document.

I believe the document is well-organized and clearly written and is 
sufficient to its purpose.  It is ready for publication.

Minor suggestions, none of which I deem critical to the document's 
utility, but potentially useful for aiding casual readers or those 
lacking bits of relevant expertise.

Where I suggest adding a conclusion, or the like, I don't care whether 
it's located in the place I suggest or in Section 5, Analysis or Section 
6, Conclusion.

> 3.1.  DNS Resource Record Types
...
> these surveys pulled a large number of domain names
>    from recent activity logs

The surveys are, presumably, distinguished by which activity logs they 
were based on.  The introduction should state this and should provide 
some basic description of the operational activities that provided the 
sources of logging data.  A log from a personal email operation is a 
rather different sampling environment from an email service provider 
having hundreds of millions of mailboxes...

As I recall, these are activity logs of large receivers.  Unless there 
is a reason to sanitize their names, use them.  Otherwise, provide some 
generic description of their salient characteristics.  For example, 
"extremely large service provider that receives mail" probably fits one 
or more...  (By the way, I suggest avoiding the term "MX server or the 
like, since A records are still valid for finding an email receiving 
host, aren't they?)

The highly indirect reference to contributors to the analysis, cited in 
the Acknowledgements is, IMO, too indirect for the concreteness I think 
useful to the inline text.

Also, what is the difference between an "activity log" and a "nameserver 
log"?  The text uses both terms without explanation. (I'm suggesting 
adding clauses, not sentences, to explain these.)

> 3.2.  Implementations

It might be worth adding an analytic conclusion suggesting that these 
data point mean that there are reasonably good software choices for 
using either mechanism, so that the gating factor probably was 
operational policy, rather than lack of coding sources.

The fact that SPF has 80% more implementations might be worth noting, 
but it's pretty obvious and might or might not be all that significant.

> 3.3.  The SUBMITTER SMTP Extension

I suggest starting with a one sentence summary of the function.  It 
isn't explained elsewhere in the doc.

Hmmm, probably worth doing a sentence describing PRA, too.

> Fewer than 4.5% of these advertised the
>    SUBMITTER extension.

This is picky, but the earlier, table format for this kind of data, 
makes it particularly easy to extract core data from the document.  I 
suggest re-using the format for all data, such as the one here.

> Over 97% of the responding MTAs advertising the SUBMITTER SMTP
>    extension were different instances of one MTA.

My general fear of common problems in casual reading during reviews 
worries that this sentence might be mis-read to mean that 97% of active 
MTAs implement the feature, rather than 97% of the 4.5%.

> 4.  Evidence of Differences

It is probably worth adding a sentence at the end of this section that 
observes something along the lines of:

      Anecdotally, the differences in conclusions have not been noted as 
causing significant operational problems by the email-receiving community.

> 5.  Analysis
...
> 6.  Although they may be marginal, there remain obstacles to
>        deployment of protocols that use DNS RRTYPEs other than the most
>        common ones,

Drop the opening clause.  Opinions about the import of the obstacles 
vary quite a bit, and it is not necessary to resolve it in this document.

The fact is that barriers remain and that they are important enough to 
mention here.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Apr 2012 06:29:40 +0000

I have made the changes stated below in my working copy, but will hold off including them in a posted -08 until we're sure there's no objection and WGLC has ended (or the chairs direct me otherwise).

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
> Sent: Sunday, April 29, 2012 10:54 AM
> Cc: [email-masked]

In all cases they were based on domains found in actual email traffic, so I've tweaked that text to say so explicitly.

> is a reason to sanitize their names, use them.

I've added the survey numbers in the case of the DNS surveys to the credits at the end, which allows attribution.  I could add them parenthetically to the "DNS Survey #X" tags as well if you like.

> adding clauses, not sentences, to explain these.)

Clarified in the text.  "activity log" is email traffic data; "nameserver log" is a trace of queries received by a nameserver.

> operational policy, rather than lack of coding sources.

Added.

> Hmmm, probably worth doing a sentence describing PRA, too.

Added.

> suggest re-using the format for all data, such as the one here.

I'll see what I can come up with.  There are so few numbers in this case that it seems like overkill to create a table, but perhaps I can add a line that's more illustrative to make it worthwhile.

> MTAs implement the feature, rather than 97% of the 4.5%.

Fixed.

> causing significant operational problems by the email-receiving

Added.

> The fact is that barriers remain and that they are important enough to

Done.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Apr 2012 09:31:07 -0700

Sorry for dragging this out another iteration...

On 4/29/2012 11:29 PM, Murray S. Kucherawy wrote:
>> The surveys are, presumably, distinguished by which activity logs
>> they were based on.  The introduction should state this and should
>> provide some basic description of the operational activities that
>> provided the sources of logging data.  A log from a personal email
>> operation is a rather different sampling environment from an email
>> service provider having hundreds of millions of mailboxes...
>
> In all cases they were based on domains found in actual email
> traffic, so I've tweaked that text to say so explicitly.

My concern was about 'actual' versus something else, but about which 
types of activity were being logged.  The last sentence, above, was 
meant as an example of the distinction I think would help some readers. 
That is, the question is /which/ activity was logged and by whom or by 
what kind of 'whom'.

>> As I recall, these are activity logs of large receivers.  Unless
>> there is a reason to sanitize their names, use them.
>
> I've added the survey numbers in the case of the DNS surveys to the
> credits at the end, which allows attribution.  I could add them
> parenthetically to the "DNS Survey #X" tags as well if you like.

Again, my intent is to focus on a characterization of the organization 
doing the logging, so the reader will have a sense of the nature and 
scale of their operation.  That will provide a heuristic about the 
population of data from which they are logging activity.

>>> Fewer than 4.5% of these advertised the SUBMITTER extension.
>>
>> This is picky, but the earlier, table format for this kind of
>> data, makes it particularly easy to extract core data from the
>> document.  I suggest re-using the format for all data, such as the
>> one here.
>
> I'll see what I can come up with.  There are so few numbers in this
> case that it seems like overkill to create a table, but perhaps I can
> add a line that's more illustrative to make it worthwhile.

My suggestion is totally Procrustean.  I'm only making it because I 
believe the numbers are the essence of the report and that a document 
like this gets casual readers who tend to scan rather than contemplate 
the data.  The tabular format greatly aids the scanning.

Again, my focus is on looking for way to bullet-proof against misreading.

Thanks!

d/

---

From: Philip Gladstone <[email-masked]>
Date: Mon, 30 Apr 2012 15:03:49 -0400

Not inline:

The data that I provided was not from email traffic but was from the top 
1 million alexa websites. I did mix in the domains that I found in my 
personal mailbox and it only added a few new domains ( > 90% of my 
correspondents domains were already in the top 1 million list [170 out 
of 1776 were newly added]). [When I say top 1M list, this was actually 
the union of two top 1m lists from about a month apart. This totalled 
1.23M entries. The other domains were in the noise, so the grand total 
was 1.23M (1228850). To generate the sqlite database, each domain was 
looked up, and if a include or redirect were found, then the target was 
added to the list of domains to be looked up. I don't know how many of 
these include/redirects were found.]

Philip

On 4/30/2012 12:31 PM, Dave Crocker wrote:
> meant as an example of the distinction I think would help some 
> readers. That is, the question is /which/ activity was logged and by 
> whom or by what kind of 'whom'.
>
>
> 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: Scott Kitterman <[email-masked]>
Date: Mon, 30 Apr 2012 17:25:10 -0400

On Monday, April 30, 2012 06:29:40 AM Murray S. Kucherawy wrote:
> I have made the changes stated below in my working copy, but will hold off
> including them in a posted -08 until we're sure there's no objection and
> WGLC has ended (or the chairs direct me otherwise).
> > Of Dave Crocker Sent: Sunday, April 29, 2012 10:54 AM
> > Cc: [email-masked]
> In all cases they were based on domains found in actual email traffic, so
> I've tweaked that text to say so explicitly.
> I've added the survey numbers in the case of the DNS surveys to the credits
> at the end, which allows attribution.  I could add them parenthetically to
> the "DNS Survey #X" tags as well if you like.
> Clarified in the text.  "activity log" is email traffic data; "nameserver
> log" is a trace of queries received by a nameserver.
> > > 3.2.  Implementations
> > 
> I'll see what I can come up with.  There are so few numbers in this case
> that it seems like overkill to create a table, but perhaps I can add a line
> that's more illustrative to make it worthwhile.
> >       Anecdotally, the differences in conclusions have not been noted
> > 
> > as
> > >        deployment of protocols that use DNS RRTYPEs other than the
> > 
> > most
> > 
> > >        common ones,
> > 

Since you're doing another update, I'll take another shot at resolving my 
objection to the introduction....

The current published version starts:

   In April 2006, the IETF published the [SPF] and Sender ID email
   authentication protocols, the latter consisting of three documents
   ([SUBMITTER], [SENDER-ID], and [PRA]).  Both of these protocols
   enable one to publish via the Domain Name System a policy declaring
   which mail servers were authorized to send email on behalf of a
   specific domain name.  The two protocols made use of this same policy
   statement and some specific (but different) logic to evaluate whether
   the email client sending or relaying a message was authorized to do
   so.

   Consensus did not clearly support one protocol over the other, and

   there was significant concern that the two would conflict in some
   significant operational situations, interfering with message
   delivery.  The IESG required the publication of all of these
   documents as Experimental, and requested that the community observe
   deployment and operation of the protocols over a period of two years
   from the date of publication in order to determine a reasonable path
   forward.

Reading it again, I'm also not sure any reference to consensus is appropriate 
as there were never any IETF attempts at consensus on these two documents.  
I'd be happy with the following if you think it's OK:

   In April 2006, the IETF published the [SPF] and Sender ID email
   authentication protocols, the latter consisting of three documents
   ([SUBMITTER], [SENDER-ID], and [PRA]).  Both of these protocols
   enable one to publish via the Domain Name System a policy declaring
   which mail servers were authorized to send email on behalf of a
   specific domain name.   There was significant concern that the two would
   conflict in some significant operational situations, interfering with message
   delivery.  

   The IESG required the publication of all of these documents as
   Experimental, and requested that the community observe
   deployment and operation of the protocols over a period of two years
   from the date of publication in order to determine a reasonable path
   forward.

I think that says enough for our purpose and avoids the issue I was concerned 
about.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 May 2012 06:01:12 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Sunday, April 29, 2012 11:30 PM
> To: [email-masked]
> I have made the changes stated below in my working copy, but will hold
> off including them in a posted -08 until we're sure there's no
> objection and WGLC has ended (or the chairs direct me otherwise).

A proposed diff to -07, for the WG's consideration.

-MSK