Subject: Re: [spfbis] A proposed reorganization

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Nov 2012 13:24:04 -0400

S Moonesamy <[email-masked]> wrote:

>At 13:37 17-09-2012, Murray S. Kucherawy wrote:
>>On reviewing the -07 draft I observed that the flow could be improved,
>>and that's thus one of the things I tried to do in the proposal.
>
>Could the WG let me know whether the following is an adequate summary 
>of the discussion about the proposal?  Please note that this message 
>is not about debating about the views that were expressed.  There 
>should be ample time during the face-to-face (Jabber for remote 
>participants) meeting for that discussion.
>
>Murray Kucherawy mentioned that the specification has however become 
>somewhat bloated with documentation of nuance and other text that has 
>nothing to do with interoperability, security, or other topics 
>critical to defining a protocol and enabling interoperability.  Much 
>of that bloat may well have been there in RFC4408 itself, and the 
>working group has focused on developing it rather than cleaning it up.
>[1]
>
>John Leslie mentioned that "we're going 'round in circles largely 
>because we have differing opinions on what is protocol and what is 
>operational advice." [2]  William Leibzon noted that that such 
>re-organization is likely to go against original intent of SPF.  The 
>intent was to have it published as a standard document and if part of 
>it is split into "informational" type document that is very different 
>especially given that SPF was published as experimental standard 
>already [3].  Dave Crocker posted the following questions [4]:
>
>  1. Is it generally 'legal' to reorganize a specification document 
>during an effort
>     like spfbis and specifically legal for spfbis?
>
>  2. Does the existing organization have some issues?
>
>3. Does the proposed reorganization increase clarity or otherwise
>improve the
>     document?
>
>Scott Kitterman mentioned that the current document (4408) is the 
>basis for multiple, interoperable implementations [5].  

That was only part of my argument.  Not only has RFC4408 been successful in supporting development of multiple interoperable implementations (demonstrating that the current organization is a successful one and there is inherent risk in choosing an alternative), I think the primary technical audience for 4408bis will be maintainers of existing implementations.and so the existing structure will be more familiar and a new one will be more likely to cause confusion to them (even if the proposed reorganization might be more clear to a new reader (which I don't think is true of the proposal).

Scott K

William 
>Leibzon mentioned that the material has been used and understood by 
>countless developers [6].  Alessandro Vesely commented that Version 
>-07 was still organized according to RFC 4408, with such 
>idiosyncrasies as putting macros after Received-SPF rather than along 
>with mechanisms and modifiers where they pertain and separating 
>filter handling from the result computation is a needed cleanup that 
>this reorganization opens nicely [7].  Arthur Thisell commented that 
>deciding the order of the macro and received-spf headers is not
>important [8].
>
>Andrew Sullivan tried to clarify the goals of the discussion about 
>the proposed reorganization [9].
>
>Regards,
>S. Moonesamy
>
>1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html
>2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html
>3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html
>4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html
>5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html
>6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html
>7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html
>8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html
>9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html 
>
>_______________________________________________
>spfbis mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spfbis

---

From: John Kelley <[email-masked]>
Date: Fri, 2 Nov 2012 15:49:22 -0400

Apologies in advance, I am a newbie with an agenda.

As a fairly neutral observer, I think if both documents are "standards 
track ready" then neither needs to be preferred over the other.

I have read other standards edited by Murray and his reorganization 
certainly makes sense to me, but that is not to say that Scott's latest 
edit is unacceptable.

I think moving SPF forward is important, I think that other work that 
relies upon SPF or even uses of technologies pioneered in the SPF (or 
Sender-ID?) spec(s) may be waiting for this document to work its way 
thru the process to become a standard.

So this is a poor answer to your question, SM.  I do believe that you 
have summarized the discussion very well.

John Kelley
AOL

On 10/30/2012 3:29 PM, S Moonesamy wrote:
> basis for multiple, interoperable implementations [5].  William 
> with mechanisms and modifiers where they pertain and separating filter 
> handling from the result computation is a needed cleanup that this 
> reorganization opens nicely [7].  Arthur Thisell commented that 
> Andrew Sullivan tried to clarify the goals of the discussion about the 
> proposed reorganization [9].
>
> Regards,
> S. Moonesamy
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 02 Nov 2012 12:56:15 -0700

On 11/2/2012 10:24 AM, Scott Kitterman wrote:
> That was only part of my argument.  Not only has RFC4408 been
> successful in supporting development of multiple interoperable
> implementations (demonstrating that the current organization is a
> successful one and there is inherent risk in choosing an
> alternative), I think the primary technical audience for 4408bis will
> be maintainers of existing implementations.

If that were certain, there would be little point in pursuing 
standardization.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 03 Nov 2012 15:09:27 -0400

> If that were certain, there would be little point in pursuing

I think one of the reasons to pursue standardization is to make it easier for 
other work to build on SPF.  While there's already one approved downref to RFC 
4408 in a standards track RFC, that was done at least in part predicated on 
the assumption that this working group was coming soon to produce a standards 
track document.  Even if no new implementations are done, there is value 
associated with documenting the ~existing protocol as a stable, standardized 
basis for other work.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 04 Nov 2012 14:09:38 -0500

> associated with documenting the ~existing protocol as a stable, standardized 

+1, but precisely among the top concerns I have is where other 
external, non-WG work items, perhaps standard track, Informational or 
BCP track RFCs can alter and define what theRFC4408bis framework, 
process model and design takes.

If RFC ABC (current or pending) says X, and 4408 says Y, than does X 
override Y or alters Y or finally defines what may have been to some 
an ambiguous Y?

I believe this has occurred already.  I think it will help if we can 
focus on a pure SPF first for protocol standardization that has no 
external protocol influence.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Nov 2012 15:15:17 -0500

I concur that SM's is an adequate summary.

I agree with the reasons Scott stated for pursuing standardization in
general, which is why I started the chartering process in the first place.

I also agree (obviously) that the quality of the document, and what I
believe is the likely result of IESG Evaluation of a proposed standard, is
a concern and therefore the basis for my proposal.

I have trouble believing that the proposed new structure introduces
difficulty for one skilled in the art, or that including a (typical these
days) summary-of-changes appendix is an unreasonable compromise.

I think the questions Dave and Alessandro pose in response to the summary
are entirely on the mark and need to be addressed.

Finally, this has certainly been an informative exercise in drafting
charters.

-MSK

On Tue, Oct 30, 2012 at 3:42 PM, Dotzero <[email-masked]> wrote:

> I think this is an adequate summary of the discussion but would point
> out that the requirements for a successful standards track document
> are more stringent than publishing an experimental document.
>
> Mike
>
> On Tue, Oct 30, 2012 at 3:29 PM, S Moonesamy <[email-masked]> wrote:
> > Could the WG let me know whether the following is an adequate summary of
> the
> > discussion about the proposal?  Please note that this message is not
> about
> > debating about the views that were expressed.  There should be ample time
> > during the face-to-face (Jabber for remote participants) meeting for that
> > discussion.
> >
> > nothing to do with interoperability, security, or other topics critical
> to
> > defining a protocol and enabling interoperability.  Much of that bloat
> may
> > well have been there in RFC4408 itself, and the working group has
> focused on
> > developing it rather than cleaning it up. [1]
> >
> because we
> > have differing opinions on what is protocol and what is operational
> advice."
> > [2]  William Leibzon noted that that such re-organization is likely to go
> > against original intent of SPF.  The intent was to have it published as a
> > standard document and if part of it is split into "informational" type
> > document that is very different especially given that SPF was published
> as
> > experimental standard already [3].  Dave Crocker posted the following
> > questions [4]:
> >
> >
> during an
> > effort
> improve
> > the
> > Scott Kitterman mentioned that the current document (4408) is the basis
> for
> > multiple, interoperable implementations [5].  William Leibzon mentioned
> that
> > the material has been used and understood by countless developers [6].
> > Alessandro Vesely commented that Version -07 was still organized
> according
> > to RFC 4408, with such idiosyncrasies as putting macros after
> Received-SPF
> > rather than along with mechanisms and modifiers where they pertain and
> > separating filter handling from the result computation is a needed
> cleanup
> > that this reorganization opens nicely [7].  Arthur Thisell commented that
> > deciding the order of the macro and received-spf headers is not important
> > [8].
> >

---

From: Hector Santos <[email-masked]>
Date: Mon, 05 Nov 2012 11:34:32 -0500

> a concern and therefore the basis for my proposal.

Can you outline what specific areas the IESG review will focus on or 
look for that may be lacking in RFC4408 or the revised BIS draft at 
this point>?

Not enough RFC 2119 wording?

Too ambiguous?

> days) summary-of-changes appendix is an unreasonable compromise.

 From my SE perspective, the issue is what exactly is being proposed? 
  What is new or different?  What will the "reorganization" bring?  Is 
it required for obtaining  IESG, IETG and community passage?   What 
exactly is the problem that the IESG reviewers will recognized and we 
failed to address here?

-- 
HLS

---

From: Tim Draegen <[email-masked]>
Date: Wed, 7 Nov 2012 09:58:13 -0500

On Nov 2, 2012, at 1:24 PM, Scott Kitterman <[email-masked]> wrote:
> I think the primary technical audience for 4408bis will be maintainers of existing implementations.and so the existing structure will be more familiar and a new one will be more likely to cause confusion to them (even if the proposed reorganization might be more clear to a new reader (which I don't think is true of the proposal).

Thanks Scott, you've helped me get my bearings in terms of eventual audience for 4408bis.

While catching up on SPFbis list traffic in prep for the face-to-face meeting, I've come to understand that there is a large consumer base of 4408bis that will likely never find themselves contributing to the IETF.  Who are they?

I teach email authentication classes for folks that want to get up to speed on how to "do authentication".  IMO, the largest audience for 4408bis will be people that want to understand how the protocol works and as a reference to people that want to write decent SPF records.

In terms of audience, in second place I'd put new developers (who will look at 4408bis, 4408, and reference existing implementations).  In last place I'd put down everyone that is already involved in the SPF space.

=- Tim

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 Nov 2012 10:24:38 -0500

On Wed 07/Nov/2012 09:58:13 -0500 Tim Draegen wrote:
>> I think the primary technical audience for 4408bis will be
>> maintainers of existing implementations.
> 
> IMO, the largest audience for 4408bis will be people that want to
> understand how the protocol works and as a reference to people that
> want to write decent SPF records.

I'd agree with Tim.  However, I think the audience we'll get is a
function of --among other variables-- what we write on that I-D.

IME, mail admins found it painful to adopt SPF when it came out.  I hope
we'll do better.

---

From: Tim Draegen <[email-masked]>
Date: Wed, 7 Nov 2012 11:23:23 -0500

On Sep 17, 2012, at 6:00 PM, Andrew Sullivan <[email-masked]> wrote:
> Before going further, I'd like for participants in this debate to state
> where they stand with respect to the above arguments, and to clarify
> what trade-offs they think are acceptable as a result.

Andrew et al, my aim is help produce a Standards-track draft that meets the needs of people outside of the IETF in as little time as possible, and no less.

In response to 3 arguments for proposed reorganization:

- As an implementor I can wade through 4408 with a yellow high-lighter and sticky-notes until I get it.
- As someone responsible for teaching others, I would greatly appreciate adoption of Murray's proposed reorganization.
- As a rare participant in IETF process, I agree with the stance of "we should clean it up now and not later".. pushing through an editorially unchanged 4408 seems to me to miss the point of why we're all here (regardless of Chartering).

In response to counter-arguments:
- After review, Murray's proposed reorganization does not change the protocol, it only makes it easier for non-experts to understand.  Perhaps oddly, I don't see the counter-arguments as such.  I see the "move SPF from the experimental to the standards track" to mean "prepare the document so that it behaves like other standards track documents", which Murray's proposed reorganization gets us closer to.
- I do not find the the "accidental protocol changes" argument compelling, due to the passion, expertise, and character-by-character review that all participants in this WG give to proposed changes.
- Similarly, the need-for-side-by-side-comparison argument is lost on me.  Optimizing for easy-review is not on my list of concerns.  I understand that there is risk whenever change is introduced, but the time to make change is when everyone is paying attention, which is now.

Trade-offs for an acceptable result:
- Commit to not changing the protocol; warts, macros, and all.
- Recognize that the current draft does too much and interleaves too many topics to make it a proper IETF standard.  The risk of the IESG kicking the draft back is one thing, but we might as well go all in to meet perceived IESG requirements AND produce a doc that technology generalists can read w/o importing the entire history of SPF into their heads.
- Everyone must commit to trying to "sneak in" at least 1 change.  This will keep everyone on their toes.

Finally, I'd like to submit that the existing draft has done an excellent job of producing interoperable technology within the community of email anti-abuse developers.  In the move from Experimental to standards-track, though, the community will get larger, and therefore the specification needs to be editorially easier to ingest.

See y'all tomorrow,
=- Tim

---

From: "J. Trent Adams" <[email-masked]>
Date: Wed, 07 Nov 2012 09:28:37 -0700

I found myself reading Tim's response and nodding the entire way through.

+1 from me.

- Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Hector Santos <[email-masked]>
Date: Wed, 07 Nov 2012 11:53:08 -0500

I have a hard time understanding the focus and goal here for 
reorganization.  Please state the main purpose and goal to adopt 
Murray's proposed changes. What is the benefits?

In my engineering and product development opinion, the proposed 
changes does alter the scope of the SPF framework (relatively to how 
we have been using it for 9+years) and we are living proof that if we 
follow the proposed changes, it will be a very costly design change 
endeavor to the point we would have to consider the pros and cons and 
most likely ignore the new considerations emphasized in the proposed 
changes.  I don't think this can't be "fixed" but it will does 
required accepting the policies already established in SPF and how 
these are functional specifications are translated into standard 
technical specifications fitting into the SMTP state machine as a 5321 
technology, not 5322 technology.   If we are focusing on 5322 
material, then the scope is changing.

--
HLS

---

From: John Kelley <[email-masked]>
Date: Wed, 7 Nov 2012 11:53:33 -0500

I agree with Trent.  Tim's arguments were compelling.

+1

John Kelley

---

From: Tim Draegen <[email-masked]>
Date: Wed, 7 Nov 2012 12:28:10 -0500

On Nov 7, 2012, at 11:53 AM, Hector Santos <[email-masked]> wrote:
> I have a hard time understanding the focus and goal here for reorganization.  Please state the main purpose and goal to adopt Murray's proposed changes. What is the benefits?

I'll try my best, but keep in mind my "main purpose" is my own.  Main purpose is to produce a document that the larger world can review to orient themselves as to how SPF works.  As an educator, the benefit is to have access to a document that students/non-SPF-experts can reference while groking the technology (mostly in the context of learning how to create and maintain accurate SPF records).

As a bonus, I think the proposed reorganization moves the document closer to the "look and feel" of existing RFCs, which gets us all closer to the goal of producing a standards-track document.

> In my engineering and product development opinion, the proposed changes does alter the scope of the SPF framework (relatively to how we have been using it for 9+years) and we are living proof that if we follow the proposed changes, it will be a very costly design change endeavor to the point we would have to consider the pros and cons and most likely ignore the new considerations emphasized in the proposed changes.  I don't think this can't be "fixed" but it will does required accepting the policies already established in SPF and how these are functional specifications are translated into standard technical specifications fitting into the SMTP state machine as a 5321 technology, not 5322 technology.   If we are focusing on 5322 material, then the scope is changing.

I'm not sure I'm reading the above correctly.  If we stick to editorial changes, then the proposed reorg is not a factor in any alteration of the scope of the SPF framework.  Rather, the above is expressing that the movement of SPF from Experimental to Standards-track will enable future SPF-related work (aka alteration of the scope of the SPF framework).  If this is what is being expressed, I think I agree.

I think the acceptance of already-established policies is a topic worth its own thread.  My experience is that the policy-component of SPF is largely misunderstood; documenting all of the various ways that SPF policy is consumed would be a fantastic exercise (and not just the "HardFail means reject-at-SMTP-time" scenario.. upstream anti-spam scanning, as an information feature in reputations systems, in the use of mitigating joe-jobs, etc).

A while ago a proposal for an extension was circulated to allow linkage between SPF and 5322.From headers.  I believe that proposal was voted off the island as out-of-scope item quite some time ago, therefore I'm not sure what else there is to say about it.  With my engineering and deployment hat on, some stacks only consume SPF results after a message has been accepted (post SMTP exchange), so it might be tough to stick to 5321 if SPFbis wants to paint a complete picture of how SPF is being used.

HTH,
=- Tim

---

From: Dotzero <[email-masked]>
Date: Wed, 7 Nov 2012 13:16:07 -0500

I'm going to take the liberty of top posting (apologies to any this
might offend). I agree overall with Tim's comments (with the exception
of people throwing in changes to test peoples attention) regarding how
to move forward.

I won't be able to make the session tomorrow (not even remotely) as I
will be having surgery tomorrow and will still be under when the
session occurs. For that reason I'd ask that my +1 and agreement with
what Tim has written be considered as if I took this stance during the
session tomorrow.

Thanks.

Mike

---

From: Franck Martin <[email-masked]>
Date: Wed, 7 Nov 2012 18:16:03 +0000

+1 for me too.

Franck

On 11/7/12 8:53 AM, "John Kelley" <[email-masked]> wrote:

>>> Andrew et al, my aim is help produce a Standards-track draft that
>>>meets the needs of people outside of the IETF in as little time as
>>>possible, and no less.
>>>
>>> - As someone responsible for teaching others, I would greatly
>>>appreciate adoption of Murray's proposed reorganization.
>>> - As a rare participant in IETF process, I agree with the stance of
>>>"we should clean it up now and not later".. pushing through an
>>>editorially unchanged 4408 seems to me to miss the point of why we're
>>>all here (regardless of Chartering).
>>>
>>> - After review, Murray's proposed reorganization does not change the
>>>protocol, it only makes it easier for non-experts to understand.
>>>Perhaps oddly, I don't see the counter-arguments as such.  I see the
>>>"move SPF from the experimental to the standards track" to mean
>>>"prepare the document so that it behaves like other standards track
>>>documents", which Murray's proposed reorganization gets us closer to.
>>> - I do not find the the "accidental protocol changes" argument
>>>compelling, due to the passion, expertise, and character-by-character
>>>review that all participants in this WG give to proposed changes.
>>> - Similarly, the need-for-side-by-side-comparison argument is lost on
>>>me.  Optimizing for easy-review is not on my list of concerns.  I
>>>understand that there is risk whenever change is introduced, but the
>>>time to make change is when everyone is paying attention, which is now.
>>>
>>> - Recognize that the current draft does too much and interleaves too
>>>many topics to make it a proper IETF standard.  The risk of the IESG
>>>kicking the draft back is one thing, but we might as well go all in to
>>>meet perceived IESG requirements AND produce a doc that technology
>>>generalists can read w/o importing the entire history of SPF into their
>>>heads.
>>> Finally, I'd like to submit that the existing draft has done an
>>>excellent job of producing interoperable technology within the
>>>community of email anti-abuse developers.  In the move from
>>>Experimental to standards-track, though, the community will get larger,
>>>and therefore the specification needs to be editorially easier to
>>>ingest.
>>>
>>> See y'all tomorrow,
>>> =- Tim
>>>

---

From: Franck Martin <[email-masked]>
Date: Wed, 7 Nov 2012 18:26:57 +0000

Hector,

Murray has stated and several people have stated, they do not seek
protocol change in this reorganization, but to follow Best Current
Practices in writing a RFC.

This needs to look like a proper RFC, rather than a babel towerŠ

We have only one good shot in making SPF a standard, let's not fail due to
poor grammar.

On 11/7/12 8:53 AM, "Hector Santos" <[email-masked]> wrote:

>> Andrew et al, my aim is help produce a Standards-track draft that meets
>>the needs of people outside of the IETF in as little time as possible,
>>and no less.
>> 
>> - As a rare participant in IETF process, I agree with the stance of "we
>>should clean it up now and not later".. pushing through an editorially
>>unchanged 4408 seems to me to miss the point of why we're all here
>>(regardless of Chartering).
>> 
>>"move SPF from the experimental to the standards track" to mean "prepare
>>the document so that it behaves like other standards track documents",
>>which Murray's proposed reorganization gets us closer to.
>>excellent job of producing interoperable technology within the community
>>of email anti-abuse developers.  In the move from Experimental to
>>standards-track, though, the community will get larger, and therefore
>>the specification needs to be editorially easier to ingest.
>> 
>> See y'all tomorrow,
>> =- Tim
>> 
>
>
>

---

From: Elizabeth Zwicky <[email-masked]>
Date: Wed, 7 Nov 2012 13:28:22 -0800

As the person who would have to coordinate Yahoo's implementation if
we were just now implementing SPF, I can say that the reorganization
goes a long way towards making the RFC easier to use. I appreciate that
reorganizations are a technical challenge while they are in progress,
but optimizing for the process right now rather than the many readers
down the road seems to me to be the wrong decision.

As a receiver with SPF support I don't see how the proposed changes
would cause us to change our implementation; could somebody clarify
that for me?

	Elizabeth Zwicky

---

From: Steve Jones <[email-masked]>
Date: Wed, 7 Nov 2012 19:20:38 -0800

The goal of the working group is to have the SPF protocol adopted as an
Internet Standard. I believe that any changes to the protocol itself have
already been ruled as out of scope, and I'm fine with that.

With a working group full of concerned participants, I'm confident that no
functional changes are going to be introduced, accidentally or otherwise.
Though unlike Mr. Draegen I will not suggest that participants attempt to
do so in order to test each others' vigilance...

This document has to meet the criteria and expectations for a mature
standard, not an experiment. It has to have a clear and logical
organization and not have various considerations and clarifications
sprinkled throughout such that finding them all is an exercise. And the
output of this WG should be in final form, not something that's known to
need further refinement and revision.

+1 for reorganizing. My day job is messaging architect (among other roles)
in the financial sector, we've relied on SPF since 2004, and it is
beneficial to our industry and our customers for SPF to transition from
Experimental to Standard status.

--Steve.

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2012 06:53:58 -0500

If we are adding stuff, like AUTH-RES in this reorganization, 
deemphasizing Received-SPF and the FAIL (-ALL) policies with exclusive 
rejection operations, then the scope is changing from both a 
publishing standpoint (less confidence in -ALL usage) and a handling 
standpoint (less reason, payoff to process SPF).

SPF is a security protocol and we have yet to resolve or get agreement 
on various issues such as Issue #29 which evolved to #33 and then #58 
regarding local policy.

If I am forced to support a non-rejecting form of -ALL policies, then 
we can no longer support SPF BIS.  Of course, no one is forcing 
anyone, but we do FOLLOW specification and it must be made clear, 
reorganized or not, -ALL does fundamentally includes SMTP REJECTION 
and ACCEPTANCE is an local deployment option, and in my engineering 
opinion, the exception to the expected behavior by the -ALL publisher.

I just don't wish to see SPF relaxed to satisfy other integrated or 
augmented protocols such as reporting and reputation mechanism because 
IMV, it waters it down as a strong _deterministic_ ANTI-SPOOFING protocol.

Due to time constraints, I doubt I will be able to get my input into 
the remote meeting so I am hoping my concerns are heeded in the 
meeting.  Thanks for your consideration.

--
Hector Santos, CEO/CTO
Santronics Software, Inc.
http://www.santronics.com

Steve Jones wrote:
> ------------------------------------------------------------------------
> 

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 08 Nov 2012 10:26:37 -0500

Hector,

On Thu 08/Nov/2012 06:53:58 -0500 Hector Santos wrote:
> rejection operations, then the scope is changing from both a publishing
> standpoint (less confidence in -ALL usage) and a handling standpoint
> (less reason, payoff to process SPF).

I think that the main point of a well done specification is to, ehm,
_specify_ the protocol.  Specifying rejection is not the same thing as
emphasizing it.  That is undoubtedly one of the reasons why SPF is
painful to implement:  Mail admins find no precise indications, and when
they try to make sense of some kind of behavior, they are told that
rejection is not specified, because this is a /sender/ policy.

You have probably been told so many many times.

For example, recall Stuart's approach to rejection, described in
http://www.ietf.org/mail-archive/web/spfbis/current/msg01268.html
Alas, the SPF implementation I use doesn't support that technique:
Doesn't that illustrate one weakness of emphasizing vs specifying?

Each programmer is encouraged to sprout his/her own conception of policy
regulation.  No surprise that there's no match.  Admins configuring
different packages get different views.  I'd not call that a standard.

> on various issues such as Issue #29 which evolved to #33 and then #58

Separating issues should help resolve them (it was already suggested in
Paris...)

> If I am forced to support a non-rejecting form of -ALL policies, then we
> can no longer support SPF BIS.  Of course, no one is forcing anyone, but
> we do FOLLOW specification and it must be made clear, reorganized or
> not, -ALL does fundamentally includes SMTP REJECTION and ACCEPTANCE is
> an local deployment option, and in my engineering opinion, the exception
> to the expected behavior by the -ALL publisher.

Agreed.  A normative specification of behavior, however, seems to
require its own document.  Personally, I see no point in stuffing
everything into a single RFC, also because there are people who is
interested in just evaluating the check_host() function and it would be
a considerable relief for them if they can do it without having to
consider parts that don't concern them.

> IMV, it waters it down as a strong _deterministic_ ANTI-SPOOFING protocol.

It may seem that moving some text to a later section diminishes its
strength.  In fact, RFC 2119 does not mention any relationship between
the meaning of key words and their position in a document.  Admittedly,
it is important for emphasizing.

I'd gladly exchange emphasis for clarity.

> Due to time constraints, I doubt I will be able to get my input into the
> remote meeting so I am hoping my concerns are heeded in the meeting. 
> Thanks for your consideration.

Oh Hector, there are just a few hundred miles and time enough to get here...

---

From: Franck Martin <[email-masked]>
Date: Thu, 8 Nov 2012 19:50:40 +0000

I prefer if we do not mix an authentication function from a policy
function. These are two different layers.

Some, will be happy to act on the policy hint immediately, some will take
all the policy hints they can find, to make a decision to accept the
message, or not.

If you look at spamassassin
http://spamassassin.apache.org/tests_3_3_x.html (not that it is a
reference), you will see that a fail barely bring 1 point (our of 5), and
funnily enough the soft fail brings more points than a fail!

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2012 15:39:01 -0500

Hi Elizabeth,

A specific goal of the proposed reorganization was to make no changes to
the bits on the wire.  So your latter observation appears to mean that goal
was met.

Thanks for having a look at it.

-MSK

On Wed, Nov 7, 2012 at 4:28 PM, Elizabeth Zwicky <[email-masked]>wrote:

> "prepare
> community

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2012 16:33:16 -0500

I am those who are not convinced that any not bits will not disturb 
the current stable electronic steady state "bits" propagations on the 
wire.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2012 16:33:52 -0500

Typo fit:

I am those who are not convinced that any [NEW] bits will not disturb
the current stable electronic steady state "bits" propagations on the
wire.

-- 
HLS

---

From: Elizabeth Zwicky <[email-masked]>
Date: Thu, 8 Nov 2012 16:17:53 -0800

I'm still not clear here. Do you see changes I will need to make to my implementation
based on the reorganization, or is the concern that new implementations will be
different than the old ones? If the latter, different in incompatible ways, or
in undesirable ways?

	Elizabeth

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2012 13:08:10 -0500

Hi, It depends on how you (SPF deployment) are handling -ALL policies. 
  To make a long story relatively short, lets ask this:

Is your SPF implementation or site deployment rejecting or 
accepting+marking the SPF failed message (failed per the Domain -ALL 
policy)?

Unresolved issues that lead to the documentation impasse:

Issue #29 - defining what "Mark the message" means.  There is no RFC 
2119 language for marking, but there is for Rejecting the message.

Issue #33 - attempts to illustrate the security loophole when a 
receiver accepts the message but does not mark and/or separating the 
mail into a "Junk/Spam" user folder.

In my view, the proposed BIS changes and now reorganization will 
emphasize accept and marking instead of rejecting the message 
operations to help support new/future RFC5322-based Reporting and 
Reputation Protocols.  This is all good as a separate document.  But 
need to be careful for what you ask for because it can be a source to 
continue with the required changes in BIS.

The problem, I guess, at least one for our product, it currently only 
supports SPF rejection for -ALL policy.  If we want to support BIS 
with any of the new goodies, then we need to change our software to 
separate the accepted, marked (issue #29) SPF failed mail otherwise we 
have the security loophole (issue #33).

Thats not to suggest a lack of support for a BIS (reorganized or not), 
if not already understood, the concern is that rejection is not going 
to promoted anymore in the name of reporting/reputation.    Again, as 
long as the option is there, we are still compatible.  So BIS for me 
should first work out SPF itself as a pure protocol with none of the 
integrated protocols design semantics.

Thanks

-- 
HLS

Elizabeth Zwicky wrote:
>>>>> This needs to look like a proper RFC, rather than a babel tower�
>>>>>