Subject: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 10:17:14 -0500

On Wednesday, January 16, 2013 03:06:05 PM Murray S. Kucherawy wrote:
> Operators are ultimately the ones that implement local policy, so I think
> it's reasonable to place the focus there.  It's unlikely that end users
> will read this and/or try to understand it.  That said, I don't have a
> problem with the alternative text proposed by John.
> 
> I think the point in the last paragraph of the proposed 11.7 needs to
> remain, however.

I'm working through issues for the next revision and this is one of them.

I think we should stick with Murray's originally proposed text for this new 
security consideration:

>  	   Operators that choose to deliver mail for which SPF produces a "fail"
>  	   result need to understand that they are admitting content that is
>  	   explicitly not authorized by the purported sender.  While there are
>  	   known failure modes that can be considered "false negatives", the
>  	   distincg choice to admit those messages increases end-user exposure
>  	   to likely harm.  This is especially true for domains belonging to
>  	   known good actors that are typically well-behaved; unauthorized mail
>  	   from those sources might well be subjected to much higher skepticism
>  	   and content analysis.
>  	   
>  	   SPF does not, however, include the capacity for identifying good
>  	   actors from bad ones, nor does it handle the concept of known actors
>  	   versus unknown ones.  Those notions are out of scope for this
>  	   specification.

Here's John Leslie's proposed alternative:

" Many operators have found that email for which SPF produces a "fail"
" result is nonetheless email which end-users depend upon receiving,
" and deliver it despite the "fail" result. This practice is permitted.
" There are things the end-user can do which will distinguish SPF
" "fail" email which they do want from SPF "fail" email they don't
" want.
" 
" Nonetheless, there are SPF publishers that really want an SPF "fail"
" to prevent delivery. SPF does not and cannot promise that. However,
" both operators and end-users should clearly understand that most
" SPF "fail" emails deserve to be rejected, and a significant number
" of them can cause harm. SPF "fail" emails from senders which are
" typically well-behaved probably deserve much higher skepticism
" and automated content-analysis.

I prefer the original language (and will use it unless I get overruled).  I 
think that the proposed alternative reads less like a security consideration.  
Additionally, I don't like putting things in terms of permitted practice.  
We've tried to minimize receiver policy for reasons that aren't worth re-
hashing and so talking about practices permitted for the receiver is a bit out 
of step with what we're trying to communicate overall.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 5 Feb 2013 11:53:20 -0500

I am ok with MK's text except for the 2nd paragraph.  I think a simple remove is OK since I think the spec is precisely about establishing a client/server protocol which inherently includes a sender and receiver policy framework.  

Ultimately, please do not weaken the -ALL policy, industry wide from small to large, from low to high value domains have comes to expect to mean one thing - they are the exclusive mail handlers (senders) and any deviation from the mail delivery behavior as detected by the SPF protocol supportive receiver is a very deterministic security condition for rejection. It has nothing to do with what a receiver will ultimately do but a good SPEC simply need to lay out the design options one can follow to handle both the backend automation and any possible ergonomic UI design necessary. 

I personally consider this as a normal project management practice product liability issues that do include the legal considerations that are possible for malpractice and/or tort, i.e. allowing a -ALL failed transaction to be passed to users as an inherent legal risk. I am not suggesting that the BIS consider this realistic thoughts, but the BIS design will be fundamental in allowing it to be done probably without all the subjective opinions.

--
HLS

----- Original Message ----- 
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 05, 2013 10:17 AM
Subject: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt

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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 12:30:05 -0500

On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote:
> I am ok with MK's text except for the 2nd paragraph.  I think a simple
> remove is OK since I think the spec is precisely about establishing a
> client/server protocol which inherently includes a sender and receiver
> policy framework.  

While the second paragraph may be sufficiently obvious to members of the working 
group, I think for a naive reader of the spec, it's an important thing to 
communicate.  I'd prefer to leave it.

Scott K

---

From: Dotzero <[email-masked]>
Date: Tue, 5 Feb 2013 12:38:05 -0500

+1 to Scott's comment about leaving the second paragraph in.

---

From: John Leslie <[email-masked]>
Date: Tue, 5 Feb 2013 14:28:33 -0500

Scott Kitterman <[email-masked]> wrote:
> I prefer the original language (and will use it unless I get overruled).

   Hmmm... Scott is a Document Editor: he should suggest text, not
demand that WGCs call a consensus...

> I think that the proposed alternative reads less like a security
> consideration.  

   Fine: I really don't care how it's wordsmithed.

> Additionally, I don't like putting things in terms of permitted

   I really don't care if "permitted" is wordsmithed out.

> We've tried to minimize receiver policy for reasons that aren't
> worth re-hashing and so talking about practices permitted for the
> receiver is a bit out of step with what we're trying to communicate
> overall.

   IMHO, delivering SPF "fail" email with appropriate headers _is_
permitted, no matter how much some of us dislike it. Regardless, it
is _done_ and will continue to be done -- because end-users demand
it.

   I think it important to say that SPF _cannot_ promise non-delivery
of email that receives an SPF "fail"; and it is not helpful to "blame"
service providers who do so.

--
John Leslie <[email-masked]>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Feb 2013 14:43:16 -0500

> demand that WGCs call a consensus...

As chair, FWIW, I did not read Scott's message as demanding a
consensus call.  He expressed a strong preference for one version, and
said that was what he was going to do but left open the possibility
that the WG could tell him otherwise.  I think this is fine.

Best,

A
 
-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 14:52:36 -0500

> demand that WGCs call a consensus...

I didn't mean this as a consensus call.  I have an opinion and I'm curious 
what other people think.  I know I don't ask for a consensus call nor do I get 
to judge if rough consensus or not.  I don't think that means I'm obligated to 
work in a vacuum.

> service providers who do so.

I know it's permitted, but I don't see value saying so in this consideration.  
I think it's reasonably clear that SPF cannot promise non-delivery for fail 
mail.  Security is about risk versus benefit.  Many operators see the risks 
over rejecting on fail as outweighed by the benefits.  The new security 
consideration only points out that there are risks related to not rejecting 
(which is what I think a security consideration should do).  I don't think it 
blames anyone for anything.  Operators are responsible for the choices they 
make and this is an area where we can't provide a universal solution.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 5 Feb 2013 15:06:43 -0500

I don't believe the 2nd paragraph is correct, technically or logically.  It provides a falsehood about the SPF protocol, a sense of wasted purpose to support or publish -ALL which is not a figment of our imaginations - its in HIGH USE and there are two basic protocol actions:

     REJECT 
     MARK (can be symnonous to separation)

For many people, even the naive, that can be very clear and precise for naive administrators and/or naive developers.

What you are doing, and I am highly concern with, is the idea with the "naive" market (whatever that means, different audidence of BIS readers?) doesn't have to do anything in being a fully compliant SPF Receiver.

This will water down the -ALL policy, the confidence in its usage of what is expected by receivers to FILTER.

What you (the text) is saying:

      Forget all that, its out of scope. What is in scope is 
      to REPORT the result and if you don't want to do anything with it, 
      thats also, IN SCOPE.  

Very confusing and ultimately, in my view, a SPF-KILLER. It will lower the incentive to support SPF.  It hurts SPF.  I say that because we saw it happen with DKIM when POLICY was watered down (deemed out of scope) and removed.  That is essentially what is going on here and I am very concern about it. I can't support a BIS that marginalizes the -ALL policy in any way, shape or form.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 15:15:12 -0500

Please give me the section number of RFC 4408 where it defines how SPF 
determines good actors from bad ones?  If you can find that, we might have 
something to discuss.

Scott K

On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote:
> I don't believe the 2nd paragraph is correct, technically or logically.  It
> provides a falsehood about the SPF protocol, a sense of wasted purpose to
> support or publish -ALL which is not a figment of our imaginations - its in
> HIGH USE and there are two basic protocol actions:
> 
>      REJECT
> For many people, even the naive, that can be very clear and precise for
> naive administrators and/or naive developers.
> 
> What you are doing, and I am highly concern with, is the idea with the
> "naive" market (whatever that means, different audidence of BIS readers?)
> doesn't have to do anything in being a fully compliant SPF Receiver.
> 
> Very confusing and ultimately, in my view, a SPF-KILLER. It will lower the
> incentive to support SPF.  It hurts SPF.  I say that because we saw it
> happen with DKIM when POLICY was watered down (deemed out of scope) and
> removed.  That is essentially what is going on here and I am very concern
> about it. I can't support a BIS that marginalizes the -ALL policy in any
> way, shape or form.
> 
> --
> HLS
> 
> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was
> Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt
> > While the second paragraph may be sufficiently obvious to members of the
> > working group, I think for a naive reader of the spec, it's an important
> > thing to communicate.  I'd prefer to leave it.
> > 
> > Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 5 Feb 2013 15:43:39 -0500

I don't think this is the question to ask and with all due respect, an unfair one to impose knowing there is no answer to it unless we wish to begin discussion for the definition of GOOD vs BAD.

This is part of the confusion of "Reputation" and "Scoring" being injected into the protocol - the Message Evaluation Component or Agent (MEA)** as it being considered, but we need to first change the mindset to a REPORTING instead of rejection. 

Good or BAD are inherent terms in SPF, and specifically for -ALL, since it declares with a high certainty who are "GOOD" or "VALID: senders as oppose to "BAD" or "WRONG" ones.  In fact, I suggest some may even extend that to a BAD/GOOD Reputation concept, just not the one most are thinking about using some 3rd party with a combined DKIM component.

No, with SPF, the -ALL, and thats all I speak of, thats a deterministic (On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt thats not to say it can part of some proprietary secret formula.

IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKING technical protocol ideas.  Just lay it out - don't suggest it out of scope thus it can't be discussed. People, especially "naive" ones do need direction I would think.

** The MEA is implementation specific. We know that, but there is a GENERAL guideline that SPF needs to lay out - thats part of the scope. That includes, REJECT or MARKING and even doing nothing, but that goes for all protocols - to do nothing. It wouldn't make sense to repeat that here because you can cleanly lay it out as a in-scope logic:

  REJECT
  MARK (REPORT) / SEPARATION
  MARK (REPORT) / DO NOTHING

Naive readers will like to know what needs to be done for supporting SPF from an receiver standpoint and for documenting what an -ALL policy can offer domains.

Thanks

---

From: Dotzero <[email-masked]>
Date: Tue, 5 Feb 2013 15:59:16 -0500

> I don't think this is the question to ask and with all due respect, an unfair one to impose knowing there is no answer to it unless we wish to begin discussion for the definition of GOOD vs BAD.

GOOD and BAD are irrelevent. Either it validates or it does not. The
use of "?", "~", "-" and "+" at the end of an SPF record communicates
the strictness of the published record. It tells us about
authorization, not goodness or badness.

> This is part of the confusion of "Reputation" and "Scoring" being injected into the protocol - the Message Evaluation Component or Agent (MEA)** as it being considered, but we need to first change…

Not at all.

> Good or BAD are inherent terms in SPF, and specifically for -ALL, since it declares with a high certainty who are "GOOD" or "VALID: senders as oppose to "BAD" or "WRONG" ones.  In fact, I suggest s…

GOOD and BAD are not inherent terms in SPF much as you would like them
to be. VALID is not the same as GOOD.

> No, with SPF, the -ALL, and thats all I speak of, thats a deterministic (On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt thats not to say it can part of some proprietary secret…

You would like the reporting option to go away yet there it is in
black and white.

> IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKING technical protocol ideas.  Just lay it out - don't suggest it out of scope thus it can't be discussed. People, especially "n…

Hector, there are some things I agree with you on but you have been
beating this drum for years without gaining traction. Different
mailbox providers (validators) will choose different ways of handling
SPF outcomes. To demand that they only do it "your" way (reject) is
IMHO quite simply a non-starter.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 5 Feb 2013 16:17:36 -0500

Thats an unfair uncategorization that is not reflective in our product lines. To suggest I am demanding my way (reject) is also defaming as well as it is not true.

Yes, I am strong advocate for deterministic protocols and what I am briefing about is a technical specification layout, not a subjective concept, that is already inherent in the protocol and always was.  Of course, anyone can do whatever they want. But that needs to be laid out and it usually comes in terms of options provided to the operator to use (or even program himself).

But thats all in-scope, and for -ALL, thats 

   REJECT
   MARK

as it was defined for RFC4408.

All I wanted is for MARK to be clearly defined (issue #29) and if it isn't, then it would be a protocol security loophole. At at minimum, in my technical view, it is engineering requirement to match the protocol functionality of two options when its related to security.  It is prudent that this be done.

I don't think I am wrong and believe it is appealable to have a market of -ALL Domains now possibly having a renewed SPFBIS specification watered down with new implementations (by naive readers as stated as the target readers).  Highly detectable -ALL transactions is no longer the case with the movement towards reporting.  Thats a change, which is fine, just lay it out very clearly. Its all in scope.

I don't wish to see that happen with SPF as it similarily did with DKIM - wasted DO NOTHING processing for the single exclusive strong policy, in this case -ALL.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 16:20:28 -0500

OK.  I think that is all covered in the current draft.

Scott K

On Tuesday, February 05, 2013 03:43:39 PM Hector Santos wrote:
> I don't think this is the question to ask and with all due respect, an
> unfair one to impose knowing there is no answer to it unless we wish to
> begin discussion for the definition of GOOD vs BAD.
> 
> This is part of the confusion of "Reputation" and "Scoring" being injected
> into the protocol - the Message Evaluation Component or Agent (MEA)** as it
> being considered, but we need to first change the mindset to a REPORTING
> instead of rejection.
> 
> Good or BAD are inherent terms in SPF, and specifically for -ALL, since it
> declares with a high certainty who are "GOOD" or "VALID: senders as oppose
> to "BAD" or "WRONG" ones.  In fact, I suggest some may even extend that to
> a BAD/GOOD Reputation concept, just not the one most are thinking about
> using some 3rd party with a combined DKIM component.
> 
> No, with SPF, the -ALL, and thats all I speak of, thats a deterministic
> (On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt thats
> not to say it can part of some proprietary secret formula.
> 
> IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKING
> technical protocol ideas.  Just lay it out - don't suggest it out of scope
> thus it can't be discussed. People, especially "naive" ones do need
> direction I would think.
> 
> ** The MEA is implementation specific. We know that, but there is a GENERAL
> guideline that SPF needs to lay out - thats part of the scope. That
> includes, REJECT or MARKING and even doing nothing, but that goes for all
> protocols - to do nothing. It wouldn't make sense to repeat that here
> because you can cleanly lay it out as a in-scope logic:
> 
>   REJECT
> Naive readers will like to know what needs to be done for supporting SPF
> from an receiver standpoint and for documenting what an -ALL policy can
> offer domains.
> 
> Thanks
> 
> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result -
> wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 05 Feb 2013 22:25:31 +0100

>>   	   versus unknown ones.  Those notions are out of scope for this

+1  for this text, _including_ the 2nd paragraph. And yes, I have read 
all messages in this thread until 2 minutes ago. So maybe I should say: 
+10 for this text.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 13:31:36 -0800

> authorization, not goodness or badness.

Right.  Spammers can get an SPF "pass" easily enough, so do we simply admit
everything that "pass"es?  That seems awfully un-smart to me.  Similarly,
legit senders pass mail through forwarders, through no fault of their own.
That will result in a "fail", and "-all" will cause such legit mail to be
rejected.  Put those together and SPF falls well short of being
"deterministic".  It may be good enough for some people to be used that
way, but generally speaking, one can't make that claim, and a standards
document certainly should not.

As Dave has pointed out before, the only case where you actually know
something about a message is when you get a "pass".  That's the only case
in which you have some generally actionable result, though it's also silly
to conclude "pass" is congruent to "deliver".

I think this notion that we are injecting reputation or scoring into the
protocol is specious.  The only thing going on here is the need to point
out to operators that "pass" doesn't automatically mean "deliver", as
described above.  That has to be communicated; it would be irresponsible of
us not to do so.  What the operator does with that information is up to it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 13:39:28 -0800

+1.

-MSK

On Tue, Feb 5, 2013 at 1:20 PM, Scott Kitterman <[email-masked]> wrote:

> > >> I don't believe the 2nd paragraph is correct, technically or
> logically.
> > >> It
> > >> support or publish -ALL which is not a figment of our imaginations -
> its
> > >> in
> > >>
> > >> This will water down the -ALL policy, the confidence in its usage of
> what
> > >> is expected by receivers to FILTER.
> > >>

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 5 Feb 2013 16:52:32 -0500

None of which has to do what DESIGN OPTIONS are available for the SPF protocol.  Its not a vague concept.

      Reciever gets an -ALL failure, it can REJECT or MARK the message.

isn't that what RFC 4408 2.5.4 basically stated?

All you are basically saying now (reminding the naive), it can DO NOTHING.

Fine, then say it, but lay it out:

   REJECT        (already has RFC 2119 semantics)
   MARK          (Define it)        
   DO NOTHING    (Warning against it)
   OTHER         (Advise of DOMAIN PUBLISHER expectations)

Ultimately, alternatives MUST|SHOULD match the Functional behavior of a REJECT, otherwisethere are security repercussions with the MARK and worst with DO NOTHING and possible OTHER.

We are not starting new here. 

Thanks

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2013 22:18:04 -0000

>service providers who do so.

Agreed.  It really is not our job to tell receivers what some of us
think that receivers should do with the SPF results.

R's,
John

---

From: John Leslie <[email-masked]>
Date: Tue, 5 Feb 2013 17:51:56 -0500

> isn't that what RFC 4408 2.5.4 basically stated?

   Yes:
] 
] 2.5.4.  Fail
] 
] A "Fail" result is an explicit statement that the client is not
] authorized to use the domain in the given identity.  The checking
] software can choose to mark the mail based on this or to reject the
] mail outright.

   In the draft, this has become:
] 
] 2.6.4.  Fail
] 
] A "fail" result is an explicit statement that the client is not
] authorized to use the domain in the given identity.

   In Section 8, we see:
] 
] 8.4.  Fail
] 
] A "fail" result is an explicit statement that the client is not
] authorized to use the domain in the given identity.  Disposition of
]  SPF fail messages is a matter of local policy.
]...
] If the checking software chooses not to reject the mail during the
] SMTP transaction, then it SHOULD add a Received-SPF or
] Authentication-Results header field (see Section 9) to communicate
] this result to downstream message processors.  While this is true for
] all SPF results, it is of particular importance for "fail" results
] since the message is explicitly not authorized by the domain owner.

   It seems to me that this is where Hector's problem lies: "SHOULD"
add one of these two headers is less than he read into 4408.

>    OTHER         (Advise of DOMAIN PUBLISHER expectations)

   The Security Considerations text in question lumps together the
second, third, and fourth of these.

   I think it reasonable to say somewhere (not necessarily in Security
Considerations, that the "SHOULD" in Section 8.4 may not be strong
enough -- that for an SPF "fail" adding one of those headers is a MUST.

   (OTOH, a "SHOULD" is actually a lot stronger than Hector may think:
"SHOULD" is less strong than "MUST" only if the implementor can find
an actual reason that "MUST" is inappropriate. While I can't think of
such a reason, perhaps someone else can...)

   The intent of my proposed text was that a service provider (that
implements SPF at all) might have a business reason to add one of
those headers showing the SPF "fail" and pass the email to the
mail-delivery process. I certainly did not intend that the service
provider might deliver the email without adding such a header.

   I would tend to humor Hector to the extent of mentioning in
Security Considerations that a service provider that marks with
one of the headers mentioned is in accordance with the spec, even
though this exposes a receiver that fails to check those headers
to potential harm. OTOH, I'd be happy with such text in Section 8.4
instead...

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 5 Feb 2013 17:50:47 -0500

It is our job in providing the learned SPF technical engineering options, epecially in a BIS I hope will gain from the 9+ years of deployed engineering insights and not start fresh with a new and alternative viewpoints on how SPF receivers should now behave post-BIS.

Ultimately, -ALL requires supportives receivers to:

    reject or mark, per RFC 4408 
 
What I see being advocated is:
    
    REPORT and do nothing (or we won't tell you want to do).

It is prudent that we write down what are the engineering and security issues with either one.

If domains (Post BIS era) come to learn that -ALL has no weight with receivers then we have failed the SPF protcol as it was done with DKIM when we did the same by watering down DKIM policies.  We are signing mail for no purpose any more. No one is doing handling as far as I know.  Lets not create the same problem for SPF -ALL policies.

Thank you.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 15:50:15 -0800

I think we're straying across the line of local policy again.  To my mind,
the only justification for a MUST or SHOULD here would be a valid claim
that the protocol has failed to operate correctly if you don't reject or
mark the message.  But that's not true; SPF itself terminates when the
"fail" is delivered to whatever asked the question in the first place, and
not when some handling action has been selected locally.

Saying SHOULD or even MUST add a result header field of some kind if not
rejecting is ideal operational advice, but I don't agree that it's part of
the protocol proper.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Tue, 05 Feb 2013 16:24:21 -0800

>] authorized to use the domain in the given identity.

Thanks to John Leslie for the above.  I have been reading the 
messages on this thread to understand the comments.

I read the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03070.html 
which is the diff mentioned at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03060.html

The diff shows the following for Section 2.5.4:

   "2.5.4. Fail
    A "fail" result is an explicit statement that the client is not
    authorized to use the domain in the given identity."

There was issue #29 about Section 2.5.4 (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01314.html ).

The definition of one of the possible outputs ("fail") has been in 
the draft for a while.

>add one of these two headers is less than he read into 4408.

I do not see any "SHOULD" for "mark" in Section 2.5.4 of RFC 
4408.  As a quick reaction, the "SHOULD" seems to have been added to 
clarify the "mark".  I have not tracked the history of this change yet.

Is the problem that the reorganization changed the substance of -08 
(see http://www.ietf.org/mail-archive/web/spfbis/current/msg03053.html )?

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 18:41:30 -0800

I think the SHOULD included in the new Section 8.4 is there mainly to
advise that the two proposed "marking" methods are the de facto standard
ways to accomplish the relaying of results to downstream components, rather
than suggesting that SPF interoperability is jeopardized if one doesn't do
so without a very good reason.  Put another way: "If you're not going to
reject, then you need to use Received-SPF or Authentication-Results, unless
you have a very good reason not to", but not "SPF is broken if you don't do
this."  Otherwise, the SHOULD for "mark" (which is really "add a header
field") is certainly good general operational advice, but not part of the
actual protocol, and as such, we might be challenged about including it in
the -bis draft, because it doesn't affect the interoperability of SPF as a
protocol between a domain owner and the receiving MTA.

There are, however, operational environments where doing "none of the
above" makes sense; neither "marking" in the ways described in the -bis
draft nor rejection makes sense there, yet the SPF result is still used as
input to the final handling decision via some out-of-band transmission of
the result to the decision component.

We might consider replacing the SHOULD with a note that "marking" is best
accomplished by adding a header field designed for that purpose, as
described in Section 9.

-MSK

On Tue, Feb 5, 2013 at 4:24 PM, S Moonesamy <[email-masked]> wrote:

> Thanks to John Leslie for the above.  I have been reading the messages on
> this thread to understand the comments.
>
> I read the message at http://www.ietf.org/mail-**
> archive/web/spfbis/current/**msg03070.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03070.html>which is the diff mentioned at
> http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03060.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03060.html>
>
> There was issue #29 about Section 2.5.4 (see http://www.ietf.org/mail-**
> archive/web/spfbis/current/**msg01314.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg01314.html>).
>
> The definition of one of the possible outputs ("fail") has been in the
> draft for a while.
>
>
>     In Section 8, we see:
>> ]
>> ] 8.4.  Fail
>> ]
> I do not see any "SHOULD" for "mark" in Section 2.5.4 of RFC 4408.  As a
> quick reaction, the "SHOULD" seems to have been added to clarify the
> "mark".  I have not tracked the history of this change yet.
>
> Is the problem that the reorganization changed the substance of -08 (see
> http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03053.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03053.html>)?
>
> Regards,
> S. Moonesamy
> SPFBIS WG co-chair
>
> ______________________________**_________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/spfbis<https://www.ietf.org/mailman/listinfo/spfbis>
>