Subject: Re: [spfbis] #58: Local policy in 4408bis

From: Arthur Thisell <[email-masked]>
Date: Wed, 12 Sep 2012 06:50:47 -0700 (PDT)

My two cents...

First, I don't think we should try to dictate local policy in an RFC.  Even if the IESG thought it was ok to do, I don't think it is very effective.

Second, historically, Meng Weng Wong felt that we could and *should* try to dictate local policy, and the drafts he wrote in 2003 reflected that.  Even the ones from 2004 pre-marid had some of that language left over.

Third, during marid, it was resolved that drafts shouldn't have local policy.  We are repeating arguments that conflict with our charter.

Fourth, while we can't tell people what to do with email they receive, it might be productive to turn the argument around to what senders expect with their sender policies.  So, we can't say "you MUST reject on SPF fail", but we could say "the sender accepts that any mail that is rejected due to an SPF fail is their problem to resolve."  Now that particular example would change the semantics of SPF fail and thus violate our charter.  We could add a modifer called yesreallywewantrejectonfail=true, but that again would violate our charter.  Still, language along those lines might help the draft.

Last, sometimes senders can know that it is ok to reject all email that fails.  For example an SPF record that says "v=spf1 -all" is very safe for host that don't send email.  Also, there are ways for senders largely solver the forwarding problem from their end (e.g. using ses/batv, an exist: mechanism and a custom DNS server), and any false positives are acceptable to them.  Or the marketing department may want peoples "real" email address and not "hide" behind throw-away forwarding services.

*shrug*

People are going to do what they want anyway.  And, they will try to shift blame for all problems onto someone else anyway.  Human nature.

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Sep 2012 11:22:27 -0400

Look, just because there are some here that wishes to dismiss what SPF 
was during MARID, continued to carried the same mindset over the years 
are they developed other protocols and when it didn't pan out, come 
back to SPF to re-created the same opposition once again, does mean 
its going to change anything. Just like the definition of insanity.

I don't believe I will be off base that SPF was from the very 
beginning an PROTOCOL for REJECTION of DETECTABLE SPOOFS using the 
LMAP assertion of DOMAIN::IP.    SPF is not the only protocol.  We had 
early predecessors in RMX, DMP, CEP all with the same  REJECTION 
semantics. Keep in MIND that AVOIDING the IETF was the BY DESIGN - so 
we can do these types of new pseudo standards that would NEVER pass 
IETF review.  It only came because Microsoft jumped into the game with 
its XML version.

As a result, we had FOUR PRODUCTIONS FROM MARID:

      RFC4405
      RFC4406
      RFC4407
      RFC4408

And it is SURREAL that we can once again DISPUTE the spirit and intent 
again of what SPF was design for to offer and do not only for the 
DOMAIN but the HIGHLY ABUSED receiver who has just as much a major 
interest in SPF than domains publishing and exposing their outbound 
mail practices.

I reject the notion that SPFBIS is being used to water down this 9+ 
year protocols with "RFC2119" related semantics or lack their of.

I don't like the way this WG direction has taken and its ashame that 
we will be repeating history just like it happen with ADSP.   Taken 
away ADSP, DKIM was watered down to a near zero payoff protocol.  Take 
away the highest benefit SPF has with -ALL policy and I can almost you 
assure you, the MISSION will be accomplish of destroy this protocol as 
well and in fact, watering down all the domain disclaimers they have 
out with -ALL policies. I will even go as far for the legal people who 
can understand this, RECEIVER can put themselves at RISK for 
MAL-PRACTICE for simple things like not accepting FAILED mail knowing 
full well what the DOMAIN owner intent and expectation was with a SPF 
SPOOF DETECTED failed messages.

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

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Sep 2012 14:24:44 -0400

On Wednesday, September 12, 2012 11:22:27 AM Hector Santos wrote:
....
> As a result, we had FOUR PRODUCTIONS FROM MARID:
...

This is factually incorrect.  MARID was closed with no documents produced (and 
let's not redebate it anyway).

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Sep 2012 14:48:18 -0400

I see your response as being very unreasonable and a non-response but 
to create some negative view of something I didn't state.  Are we 
being a bit technical about what was the outcome of the MARID work? 
Where these not the four documents that were produced from all the 
work in MARID?

In fact, it is stated here in RFC4408:

    IESG Note

    The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
    are published simultaneously as Experimental RFCs, although there is
    no general technical consensus and efforts to reconcile the two
    approaches have failed.  As such these documents have not received
    full IETF review and are published "AS-IS" to document the different
    approaches as they were considered in the MARID working group.

In in draft rev-07:

    1.2.  Experimental History

    This document updates and replaces RFC 4408 that was part of a group
    of simultaneously published Experimental RFCs (RFC 4405, RFC 4406,
    RFC 4407, and RFC 4408) in 2006.  At that time the IESG requested the
    community observe the success or failure of the two approaches
    documented in these RFCs during the two years following publication,
    in order that a community consensus could be reached in the future.

My only point is that the production of RFC4408 did not work in 
ISOLATION.  If it was the only isolated work, then it might have had a 
"Proposed Standard"

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Sep 2012 14:57:53 -0400

On Wednesday, September 12, 2012 02:48:18 PM Hector Santos wrote:
Top posting fixed.
> > This is factually incorrect.  MARID was closed with no documents produced
> > (and let's not redebate it anyway).

> ISOLATION.  If it was the only isolated work, then it might have had a

No one in the SPF community wanted it to be linked to Microsoft's Sender ID 
efforts or to be experimental.  Those were political choices of the day.  Note 
that the element of the document you quoted says "considered in the MARID 
working group", not products of the MARID working group.  This is because the 
MARID working group produced nothing.  If you believe this is not true, go 
read the two appeals filed against Sender ID and then think again.

The Sender ID RFCs are dependent on RFC 4408, but the reverse is not true.  
>From an SPF/RFC 4408 perspective Sender ID doesn't exist (RFC 4408 contains no 
references to any SenderID document outside the IESG note, which is 
paraphrased in 4408bis in the history section).

You are entitled to your own opinions, but not your own facts.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Sep 2012 15:27:31 -0400

> You are entitled to your own opinions, but not your own facts.

You keep saying this like its in style. Its pretty rude and 
unnecessary.  You behave like I wasn't involved during the entire 
period. Thats neither here or there though.

So lets try it again this way. If 4408 was isolated work, and yes I 
agree there was much animosity toward Microsoft and its key 
participation which I doubt MARID would had EXIST or SPF get any IETF 
review or an RFC if it wasn't for Microsoft, I didn't care or 
participated in any of that drama,  then why did have the IESG NOTE in 
RFC 4408 and continue with the references in SPFBIS draft section 1.2?

I agree, SPFv1 does not depends SPV2 or any part of it, as it is 
WRITTEN, but that is that the REALITY in practice in TOTAL. There are 
SPFV1 SUBMITTER supporters.

The fact is, Scott, the majority of the work did include consideration 
for ALL the documents as a result or even conclusion, if we must, of 
the MARID working group.

These are not myths and again my only point a group here is 
re-debating the theory of SPF like its all new.  It isn't.

In my view, the proper engineering is to see the entire scope as all 
products were framed to be.  What is the point and goal of this issue 
anyway?  What are we looking for? It seems people can answer pretty 
easily when all they need to look is at history - Occam's Razor.

-- 
HLS