Subject: Re: [spfbis] SPFBIS proposed charter

From: Frank Ellermann <[email-masked]>
Date: Thu, 1 Dec 2011 09:31:53 +0100

On 1 December 2011 07:37, Murray S. Kucherawy <[email-masked]> wrote:

> This level of hostility will kill this work before it gets off the ground.

Apropos, it could help to note in the Charter that 4408bis shall work
for most valid existing published 4408 policies (syntax and semantics)
"as is".  It could be good if some rarely used features are identified
and "unrecommended" or similar, but it would be bad if many policies
have to be upgraded for 4408bis implementations.

Likewise, ideally 4408 SPF implementations are "automagically" 4408bis
implementations (excluding errata, obviously).  There was some magic
in
this direction in the DKIM Charter wrt Domainkeys, therefore it might
be good to mention "compatibility" explicitly.

And no, of course I intend no "hostile take over" of this work, if folks
don't wish to talk about EAI, or at least not now and here, that's fine
with me.

And yes, there was an attempt to take over "v=spf1" policies some years
ago.  I'm very much in favour of all statements in your proposed Charter
that this will be "out of scope" here.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Dec 2011 00:40:33 -0800

> -----Original Message-----
> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Thursday, December 01, 2011 12:32 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [spfbis] SPFBIS proposed charter
> 

It already says:

        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.

> implementations (excluding errata, obviously).  There was some magic in

I think what I cited above covers backward compatibility, but I have no objection to actually saying so if there's consensus that it's necessary.

> And no, of course I intend no "hostile take over" of this work, if
> folks don't wish to talk about EAI, or at least not now and here,
> that's fine with me.

That isn't the hostility to which I was referring.

---

From: SM <[email-masked]>
Date: Thu, 01 Dec 2011 21:41:59 -0800

At 13:56 30-11-2011, Murray S. Kucherawy wrote:
>I've contacted the author, and now his boss, to remind him to post it.  :-)

Commenting on the proposed charter:

    'Finally, the working group will develop the proposed "scope"
     extension found in draft-mehnle-spfbis-scope.

     Specifically out-of-scope for this working group:'

draft-mehnle-spfbis-scope is new work.  As there isn't any 
operational experience for it, I suggest not to limit the scope 
except for discussions about the merits of SPF.

I suggest deleting the following sentences:

    'Finally, the working group will develop the proposed "scope"
     extension found in draft-mehnle-spfbis-scope.'

    'Extensions to SPF other than the one specified above.'

    'MMM YYYY:   A standards track document creating the "scope"
                         extension to the IESG for publication.'

and re-chartering to take on draft-mehnle-spfbis-scope.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Dec 2011 22:31:59 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Thursday, December 01, 2011 9:42 PM
> To: [email-masked]
> draft-mehnle-spfbis-scope is new work.  As there isn't any operational
> experience for it, I suggest not to limit the scope except for
> discussions about the merits of SPF.

The idea of the charter's current language is to prevent rat-holing on any of the contentious stuff regarding what parts of SPF are better or what's wrong with other mechanisms.  There's clear consensus that we as a community want to move forward with SPF to the exclusion of other things in its family, so anything else is a distraction.  We're hoping this language will help to maintain focus.

The "reasonably warranted based on operational experience" bit further constrains the discussion, limiting any tweaks to SPF such that they have to be based on what we've actually seen in operation rather than anything hypothetical.  "Reasonably", of course, is subjective, and the working group and its co-chairs would need to gauge what things are safe to reopen based on those criteria and what things are also rat-holes.

The extension draft you're talking about doesn't fit into that category, and there's a community that wants to develop and implement it now.  Given that level of extant support for it, I believe it makes sense to allow for it in this first charter as well.  We've called out a single, specific extension as a candidate for consideration rather than "extensions", which would be far too general.

> [...]

If the re-chartering process is as painless as I've heard it is, then I suppose this is an option.  How do others feel?

-MSK

---

From: SM <[email-masked]>
Date: Thu, 01 Dec 2011 22:40:52 -0800

Hi Murray,
At 22:31 01-12-2011, Murray S. Kucherawy wrote:
>The extension draft you're talking about doesn't fit into that 
>category, and there's a community that wants to develop and 
>implement it now.  Given that level of extant support for it, I 
>believe it makes sense to allow for it in this first charter as 
>well.  We've called out a single, specific extension as a candidate 
>for consideration rather than "extensions", which would be far too general.

[snip]

>If the re-chartering process is as painless as I've heard it is, 
>then I suppose this is an option.  How do others feel?

I am ok with any of the two alternatives you commented about.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Thu, 01 Dec 2011 22:58:21 -0800

At 16:03 30-11-2011, Dave CROCKER wrote:
>We need to leave Sender-ID alone for this round of effort.  Touching 
>it is inviting distraction and delay from producing an SPF 
>specification on standards track.

I'll volunteer to edit the document that concludes the 
experiments.  I can resurrect an amended version of an expired draft 
as a starting point. I suggest working on 4408bis first to avoid any 
distraction.

Regards,
-sm

---

From: Paul Midgen <[email-masked]>
Date: Fri, 2 Dec 2011 07:03:54 +0000

I'm still relatively inexperienced in the standards process, so keep that in mind when reading my comments.

I'm treating SPFbis as the effort that will bring a path authorization mechanism to internet standards status. We currently have two path authorization mechanisms in experimental status. Over the last 6 months it's become evident (to me) that in the last 5+ years a de facto consensus for the operation of path authorization mechanisms has emerged.

One of SPFbis' efforts will be to publish data detailing current operational characteristics of SPF & SenderID (the document Dave Crocker mentioned), and said data will inform SPFbis. As has been mentioned, it's not terribly interesting (to me, anyway) what happens with RFCs 4406 & 4407.

Having now given draft-mehnle-spf-scope a first read, my hope that what it essentially proposes (inclusion of some number of RFC5322 headers as authenticatable identities) finds its way into SPFbis, and that doing so is supported by operational data. I've seen this to be true anecdotally, but want it out there in published form with data from multiple receivers, senders, etc. included in the analysis.

-p

> Sent: Thursday, December 01, 2011 10:41 PM
> To: [email-masked]
> >category, and there's a community that wants to develop and implement
> >it now.  Given that level of extant support for it, I believe it makes
> >sense to allow for it in this first charter as well.  We've called out
> >a single, specific extension as a candidate for consideration rather
> >than "extensions", which would be far too general.
> 
> [snip]
> 
> >If the re-chartering process is as painless as I've heard it is, then I
> >suppose this is an option.  How do others feel?
> 
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Paul Midgen <[email-masked]>
Date: Fri, 2 Dec 2011 07:05:27 +0000

Murray and I have had some discussion on this prior to starting SPFbis, and the work is already in progress - though my contribution to it won't be ready for some months, since I'm constrained by my current ability to gather all the data I want.

So - before we start editing and circulating documents, we should first have a discussion on what all our thoughts/expectations are.

> Sent: Thursday, December 01, 2011 10:58 PM
> To: [email-masked]
> >We need to leave Sender-ID alone for this round of effort.  Touching it
> >is inviting distraction and delay from producing an SPF specification
> >on standards track.
> 
> I'll volunteer to edit the document that concludes the experiments.  I can
> resurrect an amended version of an expired draft as a starting point. I
> suggest working on 4408bis first to avoid any distraction.
> 
> Regards,
> -sm
>

---

From: SM <[email-masked]>
Date: Thu, 01 Dec 2011 23:54:32 -0800

Hi Paul,
>that in mind when reading my comments.

If my comments are unclear, please let me know and I'll elaborate.

>One of SPFbis' efforts will be to publish data detailing current 
>operational characteristics of SPF & SenderID (the document Dave 
>Crocker mentioned), and said data will inform SPFbis. As has been 
>mentioned, it's not terribly interesting (to me, anyway) what 
>happens with RFCs 4406 & 4407.

draft-kitterman-4408bis will obsolete RFC 4408 and according to the 
proposed charter will be published as a Proposed Standard.

>Having now given draft-mehnle-spf-scope a first read, my hope that 
>what it essentially proposes (inclusion of some number of RFC5322 
>headers as authenticatable identities)

Yes.

>  finds its way into SPFbis, and that doing so is supported by 
> operational data. I've seen this to be true anecdotally, but want 
> it out there in published form with data from multiple receivers, 
> senders, etc. included in the analysis.

I prefer not to comment on this during the chartering discussion as 
it might end up being controversial.

At 23:05 01-12-2011, Paul Midgen wrote:
>Murray and I have had some discussion on this prior to starting 
>SPFbis, and the work is already in progress - though my contribution 
>to it won't be ready for some months, since I'm constrained by my 
>current ability to gather all the data I want.
>
>So - before we start editing and circulating documents, we should 
>first have a discussion on what all our thoughts/expectations are.

Good idea.  I am ok with whatever the consensus is for the "conclusions" draft.

This mailing list has been quiet which is unusual for a fora where 
SPF and Sender-ID is mentioned.  It's better to have the 
above-mentioned discussion after the working group is chartered as 
there will be a WG chair to deal with the controversies.

Regards,
-sm

---

From: Julian Mehnle <[email-masked]>
Date: Sat, 3 Dec 2011 01:03:08 +0000

Murray S. Kucherawy wrote:

> SM wrote:
>
> > BTW, where's the draft-mehnle-spfbis-scope document?
>

As usual, I'm participating in the IETF as an individual and am not acting 
on behalf of my employer.  They're not even paying me to do this.

-Julian

---

From: Julian Mehnle <[email-masked]>
Date: Sat, 3 Dec 2011 01:14:15 +0000

Murray S. Kucherawy wrote:

> Hello all, and welcome to the SPFbis mailing list.
>
> As usual, our first order of business is to hash out a charter for the
> working group.  Many of you have already seen it privately, and it was
> circulated and discussed briefly within the APPS area working group
> session in Taipei and its mailing list.  Attached is the latest
> version, a product of all of the above.

Thanks for setting up the list and organizing the effort so far, Murray!

> So the usual questions:
>
> - Does this charter capture an accurate description of the problem to be
>   solved (in our case, it's really the work to be done)? 
>
> - Is the charter appropriately broad and/or limited in scope?

I agree with the version of the charter that Murray posted on 2011-11-30.

> - Who is willing to review and comment on documents in the working
>   group? 

I'm willing to review, and comment on, all documents that this WG 
produces.

> - Who is willing to act as document editor(s)?

If the "scope" modifier doc ends up being in-scope (haha! sorry!) for this 
WG, I'm willing to act as an editor for it.

I'm willing to act as a co-editor for the main 4408bis document as well, 
but I'm severely time-constrained, so I will commit to it only if there 
aren't enough volunteers.  (Whatever it takes, but not a lot more.)

> - Who is likely to implement (or, since SPF is already out there, who is
>   likely to update their implementations to match any changes in the
>   specs) and participate in interoperability testing?

I will update the Mail::SPF Perl library (which I wrote and which has no 
known deviations from RFC 4408) as necessary as this WG progresses.

Like Scott Kitterman, I'm also willing to work on updating the SPF test 
suite.

-Julian

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 03 Dec 2011 20:26:19 +0100

On 30/Nov/11 21:01, Murray S. Kucherawy wrote:
> 
> -          Does this charter capture an accurate description of the
> problem to be solved (in our case, it’s really the work to be done)?
> 

One way to further constrain the charter would be to explicitly
mention "v=spf1" either in the relevant milestone or in the "Changes
to the SPF specification" paragraph.

For the scope document, IMHO it would be better to concentrate on
checking and enforcing rather than extending the syntax.  Some
receivers already check 5322.from either as a further restriction or
inclusively, e.g. http://www.courier-mta.org/courier.html#SPF  By
allowing this point to be managed by domain owners, we limit what
receivers can do.

I also heard of verifiers who assume an MX/24 for domains that have no
SPF record.  Should these uses be documented?

jm2c

> -          Who is willing to review and comment on documents in the
> working group?

+1

---

From: Julian Mehnle <[email-masked]>
Date: Sat, 3 Dec 2011 22:49:45 +0000

> allowing this point to be managed by domain owners, we limit what

Receivers will always do whatever they want.  A standards document like 
4408bis, however, must consider compatibility and predictability.

As an analog, RFCs 974/1035 clearly define the semantics of DNS "MX" 
records, with good reason.  Would you claim this (unduly) limits what 
users of MX records can do?  Should RFCs 974/1035 be revised to allow 
frequent abuses of MX records, such as ignoring the MX preference value 
and submitting mail (spam) only to the MX with the *highest* preference, 
just so these RFCs don't limit what users of MX records can do?

> SPF record.  Should these uses be documented?

This is known as "best guess" and is non-standard practice — probably not 
even best practice: <http://www.openspf.net/FAQ/Best_guess_record>

-Julian

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 03 Dec 2011 19:03:57 -0500

Julian Mehnle <[email-masked]> wrote:

>even best practice: <http://www.openspf.net/FAQ/Best_guess_record>.

This practice was known when RFC 4408 was developed and there was a strong consensus that it was not appropriate to standardize it.  I can't think of a good reason to consider it differently now.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Dec 2011 11:10:03 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Mehnle
> Sent: Saturday, December 03, 2011 2:50 PM
> To: [email-masked]
> This is known as "best guess" and is non-standard practice — probably
> not even best practice: <http://www.openspf.net/FAQ/Best_guess_record>

I would be comfortable with documenting "Best Practice SPF" in a non-normative appendix.  It's common enough that it should be written down someplace permanent, like the back of an RFC.

---

From: Stuart Gathman <[email-masked]>
Date: Sun, 04 Dec 2011 21:16:28 -0500

Long ago, Nostradamus foresaw that on 12/04/2011 02:10 PM, Murray S.
> I would be comfortable with documenting "Best Practice SPF" in a non-normative appendix.  It's common enough that it should be written down someplace permanent, like the back of an RFC.
I use "best guess", and find it very useful, *however* spfbis should
explicitly mention that such results should not be reported as SPF
results in Received-SPF or Authentication-Results headers.  I report
them as x-bestguess= in Received-SPF.

---

From: Tim Draegen <[email-masked]>
Date: Sun, 4 Dec 2011 10:02:56 -0500

Hi, I'm writing in support of, and to support, this work.  Comments in-line..

On Nov 30, 2011, at 3:01 PM, Murray S. Kucherawy wrote:
> So the usual questions:
>  
> -          Does this charter capture an accurate description of the problem to be solved (in our case, it’s really the work to be done)?

In my professional life, the fact that SPF is Experimental acts as a minor deployment barrier.  Changing this would be most helpful as I travel around attempting to get more folks to deploy.

> -          Is the charter appropriately broad and/or limited in scope?

The charter looks just right to me, including Julian's extension.  You can take my view with a grain of salt, though, as Julian and I work at the same company.

> -          Who is willing to review and comment on documents in the working group?

Glad to.

> -          Who is willing to act as document editor(s)?

Can't be me, as I'm limited in time and hope to contribute in a different area... see below.

> -          Who is likely to implement (or, since SPF is already out there, who is likely to update their implementations to match any changes in the specs) and participate in interoperability testing?

I'd like to bring to the Working Group a different resource.  My company, Agari - formerly Authentication Metrics - has amassed a significant amount of real-world data pertaining to SPF and SenderID -- including sources of messages, verification-check results, SPF records, the domains under verification.. HELO, MFROM, header-From/Sender/Resent-From/Resent-Sender fields, from many different sites across the internet.

I'd like to make this data available to answer questions, inform discussion, and to help produce the best spec possible.  Some examples: How much of Sender-ID-veriified email is checking From: vs Sender: vs Resent-From: vs Resent-Sender:?  Categorically, where does the MFROM diverge from the header-From.. and how many senders are responsible for 90%, 50%, 25%, 10 %, etc of this behavior?  What are the most common errors found in SPF records?  What happens when SPF records exceed the size of a UDP packet?

IMO, good questions directed at real-world data should go a long way in helping move SPF out of Experimental.

> -          Who is willing to co-chair a working group?

I can't do a good job at this due to other commitments and a desire to participate as a contributor.

Cheers,
=- Tim

---

From: Tim Draegen <[email-masked]>
Date: Sun, 4 Dec 2011 10:19:18 -0500

> One of SPFbis' efforts will be to publish data detailing current operational characteristics of SPF & SenderID (the document Dave Crocker mentioned), and said data will inform SPFbis. As has been m…

I can commit to working on, and providing data to back, this effort.  In my opinion, moving both SPF & SenderID in any direction out of Experimental should leave behind documentation that describes "The Experiment is now over, here is what we've learned".  There's clearly a lot of experience to capture and relate.

=- Tim

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 05 Dec 2011 18:30:31 +0100

On 05/Dec/11 03:16, Stuart Gathman wrote:
>> I would be comfortable with documenting "Best Practice SPF" in a
>> non-normative appendix.  It's common enough that it should be
>> written down someplace permanent, like the back of an RFC.

How about adding an SPF BCP to the milestones?

> them as x-bestguess= in Received-SPF.

Hm... I'm not following you.  Do you mean that one would write the
following if ietf.org didn't have an SPF record?

  Received-SPF: pass
    identity=mailfrom;
    envelope-from=[email-masked];
    client-ip=12.22.58.30;
    x-bestguess=a

BTW, the production rule for identity seems to be orphaned, in Section
7.  Cannot connect for www.openspf.org/RFC_4408/Errata ...

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Dec 2011 09:45:33 -0800

> How about adding an SPF BCP to the milestones?

What, exactly, would it cover?  That is, what's the scope of the task that 
permits achieving the milestone?  What problem will it solve?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Stuart D. Gathman" <[email-masked]>
Date: Mon, 5 Dec 2011 13:36:42 -0500 (EST)

>    envelope-from=[email-masked];

No.  SPF result is none where there is no SPF record:

Received-SPF: None (mail.bmsi.com: 98.139.91.92 is neither permitted nor denied
 	by domain of yahoo.com) client-ip=98.139.91.92;
 	envelope-from="[email-masked]";
 	helo=nm22.bullet.mail.sp2.yahoo.com; receiver=mail.bmsi.com;
 	mechanism=ptr; x-bestguess=pass; x-helo-spf=pass; identity=mailfrom

-- 
 	      Stuart D. Gathman <[email-masked]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Dec 2011 13:37:52 -0500

Alessandro Vesely <[email-masked]> wrote:
...
>7.  Cannot connect for www.openspf.org/RFC_4408/Errata ...

Use openspf.net instead.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Dec 2011 10:39:34 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Sunday, December 04, 2011 11:10 AM
> To: [email-masked]
> I would be comfortable with documenting "Best Practice SPF" in a non-
> normative appendix.  It's common enough that it should be written down
> someplace permanent, like the back of an RFC.

Just to be clear: If the working group agrees, it is also free to explain why it thinks use of Best Guess SPF is a bad idea.  The goal here is education, after all.

---

From: Dotzero <[email-masked]>
Date: Mon, 5 Dec 2011 14:07:33 -0500

> Just to be clear: If the working group agrees, it is also free to explain why it thinks use of Best Guess SPF is a bad idea.  The goal here is education, after all.

If we are talking standards track I think we would need more
information on "Best Practice SPF" for the RFC to say
good/bad/indifferent. It has basically been out of scope for the
existing RFC.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 06 Dec 2011 13:05:41 +0100

On 05/Dec/11 18:45, Dave CROCKER wrote:
> What, exactly, would it cover?  That is, what's the scope of the task
> that permits achieving the milestone?  What problem will it solve?

There's quite some FAQs, approaches, tricks, recommendations, similar
to bestguess.  For example, publishing "v=spf1 -all" for some hosts
that have an A record, use of _spf.example.com and other include/
redirect strategies.  Quite often we'll ask ourselves what to do with
this or that issue, and decide for non-normative, educational text.

Two alternative destinations for such material are an appendix and web
sites like openspf.NET --thanks Scott, I should have recalled that.
While both of them have their own merits, the former is more demanding
on the editor and the resulting document will be somewhat less tight;
the latter is better for ongoing developments than for bottom line
statements made at a definite time.

As for whether to mention it in the charter, and BCP vs informational
rank, I don't know.