Subject: [spfbis] What is a sender policy?

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Aug 2012 13:00:52 -0400

Upon reflection, I think a lot if the recent dialog on this list is based on a misunderstanding about what a 'sender policy' is in SPF terms.  A sender policy is not about a sender telling a receiver what to do. A sender policy is a statement that mail was either sent in accordance with the sender's policy (pass), it wasn't (fail), or one of several varieties of uncertainty.

That's all.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Aug 2012 14:03:58 -0700

On 8/25/2012 10:00 AM, Scott Kitterman wrote:
> Upon reflection, I think a lot if the recent dialog on this list is
> based on a misunderstanding about what a 'sender policy' is in SPF
> terms.  A sender policy is not about a sender telling a receiver what
> to do. A sender policy is a statement that mail was either sent in
> accordance with the sender's policy (pass), it wasn't (fail), or one
> of several varieties of uncertainty.

1.  Clarity about the role of this specification is essential.

2.  For SPF and other, recent email "policy" work, there is a persistent
confusion about the meaning of the specification and the extent to which
a sender can or should attempt to "dictate" behaviors by receivers.

3.  I am not finding language in the current draft that attempts the
kind of clarity Scott's above text has.

So I think we should add language of the sort that in the last two
sentences, above.  Clarify what it is.  Clarify what it is not.  Scott's
language looks like a good start and maybe a good finish.

The text I'd suggested adding to his two sentences is:

   A receiver is provided these sender statements as guidance, to use as
they wish in the handling of a message.

d/

-- 
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Sat, 25 Aug 2012 17:21:03 -0400

At the risk of being excommunicated in this WG, I disagree with this 
assessment and this placement of misunderstanding. Its the same old 
argument from the past and a waste of processing time, cost of 
development, support, overall "time"  to debate what is essence of a 
client/server protocol, any one; the problem and the solution it 
offers to address the problem (read abstract), the payoff, its purpose 
in life.

-ALL has always had a special meaning, despite how a receiver wishes 
to honor or deviate from the protocol functionality specification.  It 
has always been very clear, 2.3 doubled it and to my surprise 
reinforced it in rev6. Yet, there were those opposed to this level of 
strength in the same way SSP has issues with it strong exclusive 
policies. It is not an accident that that new confusion and chaos are 
seeded by the same advocates of both protocols.   Mind you, they are 
valid concerns too. But like anything else, we needed SPF to solve a 
real problem no other protocol was available to address.  SPOOFS are 
real and what IMV what needs to appreciated is that there are those 
who strongly believed in deterministic solutions as as there were 
those that believed in heuristic (belated processing/learning) 
solutions, a.k.a Reporting like protocols.   No one should be trumping 
the other and that IMV has been the conflict. I wish we can finally 
get over it.

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

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Aug 2012 18:37:09 -0400

It's not new this misunderstanding.  This 'special meaning' is documented nowhere.  

Scott K

Hector Santos <[email-masked]> wrote:

>accordance with the sender's policy (pass), it wasn't (fail), or one of
>several varieties of uncertainty.
>> 
>> That's all.
>> 
>> Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Aug 2012 15:43:18 -0700

> Upon reflection, I think a lot if the recent dialog on this list is based on a misunderstanding about what a 'sender policy' is in SPF terms.  A sender policy is not about a sender telling a receiv…

+1.

Also, I think Dave made an important point that went largely ignored:
We know a lot more about a message that passes SPF or DKIM than one
that fails, because failures can happen for so many valid reasons.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Sat, 25 Aug 2012 19:13:35 -0400

> It's not new this misunderstanding.  This 'special meaning' is documented nowhere.  

By "Special Meaning," I hope we can agree that -ALL has an unique 
semantic over others policies in RFC4408. As 2.3 has it,

    ... so that a definitive determination of authorization can be made.

or as rev6 has it:

   ... otherwise, no definitive determination of authorization can be 
made.

or as 2.5.4 says to mark or reject exclusively only for a -ALL fail 
result.

Are we now saying this was never the intent for receivers to behave 
this way specifically and exclusively only possible with -ALL?

I would call that a "special meaning" over the other possible policies 
in SPF.

I agree there has been always the dispute on how strong one believes a 
receiver should honor the SPF, even SSP even ADSP similar "special 
meaning" policies of super strong authorization.  Your proposal I 
don't believe will change this either way.

I guess what I am at lost with this current topic and similar concerns 
is what exactly we are are trying to convey to receivers about what 
domain publishes? What exactly are they responsible for as an SPF 
"receiver" processor, the #1 essential component of the SPF 
client/server protocol?

My concern is what is the end result, more ACCEPT+MARK actions?  Ok, I 
don't see a problem with this new focus and emphasis because it 
doesn't remove the alternative, but it does highlights security 
concern - issue #33.

If you think you need to add something, perhaps you can borrow text as 
it was done with RFC5016 in section 5.3, item 10 for the very same 
concerns of having "special meanings" with strong policies. 
Paraphrasing it for SPF:

      INFORMATIVE NOTE: the main thrust of -ALL is that this
      practice should only be published for that which the publisher
      has control, and should not meddle in what is ultimately the
      local policy of the receiver.

--
HLS

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Aug 2012 22:06:04 -0400

> I would call that a "special meaning" over the other possible policies 

Pre-MARID drafts say:

     Fail (-): the message does not meet a domain's definition of
     legitimacy.  MTAs MAY reject the message using a permanent
     failure reply code.  (Code 550 is RECOMMENDED.  See [RFC2821]
     section 7.1.)

So reject has never been more than a MAY.   Clearly that has is still the 
case.

I think that "message does not meet a domain's definition of legitimacy" is 
very close to my statement today that the message is not from an authorized 
source.  I believe that what I'm saying is very consistent and unchanged and 
if you think it's not, you need to revisit your assumptions.

Don't forget that SPF was originally Sender Permitted From.  Nothing changed 
when the acronym changed.  That's a more accurate name for SPF.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 25 Aug 2012 22:11:39 -0400

Hat in hand.

>   ... otherwise, no definitive determination of authorization can be

It is plainly true that -ALL has different semantics compared to other
things.  One should hope that to be true, or else there'd be no reason
to have it in the protocol.

But there is nothing about it or anything else in SPF that has any
binding on a receiver.  By definition it _cannot_ be binding on a
receiver, because there are lots of receivers who just don't process
SPF. 

> this way specifically and exclusively only possible with -ALL?

That is a false alternative.  -ALL tells you something about what a
sender claims is the case at its site.  What you do with that
information is entirely up to you.  This is the force of Scott's
emphasis of it being a _sender_ policy.  If someone wishes to spin up
a WG that is the Receiver Policy Framework, which dictates what
implementing receivers MUST, MUST NOT, MAY do (and so on), I encourage
such people to write those drafts.  But in my opinion, what receivers
do is just none of our (SPFBIS's) business.

If people wish to pursue continued discussion about telling receivers
of SPF-covered mail how to behave, I'm going to want to see a pretty
good argument -- much better than I've seen so far -- why we ought to
do that or why it is even remotely on charter.  "Remotely on charter"
means that you need to show how the text in 4408 is obscure, how
current practice has settled matters, and how that links up with the
specific tasks in our charter.  Further discussion without meeting
these necessary conditions is just off-topic for the WG.  Please, I am
asking, stop.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 26 Aug 2012 13:44:35 +0200

> these necessary conditions is just off-topic for the WG.  Please, I am

We don't need to show how the I-D is obscure:  It's obvious.  One can
count dozens of occurrences of the term "reject" or inflections
thereof.  Yet, as Scott says, nowhere it documents recipient policy.
It half-says, hints, surmises, alludes.  I think everyone can see the
dangers of standardizing such obscure stuff.

In principle, cleanup can occur in two ways.  After banning further
discussion on receiver behavior, there is one way only:  take off all
of Section 9, and remove any allusion to receiver behavior from the
rest of the document --except one-- so as to really make the I-D
conform to the sentences upthread:

  A sender policy is not about a sender telling a receiver what to
  do.  A sender policy is a statement that mail was either sent in
  accordance with the sender's policy (pass), it wasn't (fail), or
  one of several varieties of uncertainty.  A receiver is provided
  these sender statements as guidance, to use as they wish in the
  handling of a message.

The single allusion that has to be tolerated is a sentence to mandate
header fields on acceptance only, e.g.:

  Receivers who accept a message after having carried out SPF
  authentication SHOULD add a trace header field to convey the result.

I think it may be much easier and fast to proceed this way.  Perhaps,
we will even recharter and complete the receiver policy afterwards.
In any case, we'd better avoid to submit something which is neither
fish nor fowl.

---

From: John Leslie <[email-masked]>
Date: Sun, 26 Aug 2012 07:46:56 -0400

Scott Kitterman <[email-masked]> wrote:
> based on a misunderstanding about what a 'sender policy' is in SPF terms.

   Very likely true!

> A sender policy is not about a sender telling a receiver what to do.
> A sender policy is a statement that mail was either sent in accordance
> with the sender's policy (pass), it wasn't (fail), or one of several
> varieties of uncertainty.

   You prove your point. :^(

   A sender saying +a states clearly that mail originating from that
address is consistent with policy.

   But what does -all mean?

   I guess most senders mean they never send from any other address.
That clearly does _not_ mean that mail received via some other MTA
is _not_ sent according to policy.

   Indeed, it simply isn't clear whether an SPF fail states _anything_
about whether the mail was sent according to policy.

   :^( :^( :^(

--
John Leslie <[email-masked]>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Aug 2012 23:10:21 -0700

>    I guess most senders mean they never send from any other address.

Right.

> is _not_ sent according to policy.

At best it can say "Anything else (that doesn't match the listed
mechanisms) was not originated according to policy."  The difficulty
is that neither the message nor the envelope contain enough data to
allow arbitrary agents in the handling path to reconstruct accurately
the environment where such an evaluation would be meaningful.  That
is, after a message goes from A to B to C, C can't be certain it has
all of the right information to answer the question "What did B see?"
which is what would really make SPF results actionable.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Aug 2012 23:21:41 -0700

> dangers of standardizing such obscure stuff.

I'm confused as to the objection.  Absent normative language about
what a participant has to do, nothing is actually being standardized.
Is it somehow a problem to allude to the current best practices, i.e.,
either reject or mark, as per the receiver's needs, without actually
specifying one?

> conform to the sentences upthread:

I don't agree with striking Sections 9.1 and 9.2 on this basis as they
are not related to receivers.  9.3 delivers nothing normative so I
think it's fine too.  And as we're chartered to document things that
have gained widespread support, the two handling options presented are
permitted (even though, really, nothing's changed).

>   these sender statements as guidance, to use as they wish in the

This, or something like it (perhaps coupled with Scott's statement
that SPF is an MTA-to-MTA protocol), would be a good thing to add
somewhere in Section 1.

>   authentication SHOULD add a trace header field to convey the result.

That's basically what Section 7 should (and does) say.  John Levine
and I mentioned elsewhere that 7.2 should probably be heavily chopped,
however.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Aug 2012 12:43:47 +0200

> either reject or mark, as per the receiver's needs, without actually

I think it /is/ a problem, for various reasons.  First, the "several
varieties of uncertainty" miss an actual meaning unless they are
paired with an intended behavior.  Second, that kind of descriptions,
given as if patting the reader with the elbow or winking, such as
those currently used to pair results to intended behaviors, are a poor
standardization technique, and lower the average quality of IETF
standards.  Third, since they are not spelled out clearly, it is
overly difficult to improve them.  Finally, participants are not
officially supported, so that their behavior can be considered abusive
by anyone acting as a protocol cop.

> think it's fine too.

I've been gross.  There are several little parts to remove (including
one on which the two of us recently agreed upon, e.g.).

> And as we're chartered to document things that have gained
> widespread support, the two handling options presented are 

Yes.

> that SPF is an MTA-to-MTA protocol), would be a good thing to add

Yup, usual disclaimers, such as saying what is beyond the document,
would also be appropriate.  Then, the SPF-deployment document will be
able to say "here we cover what we left unspecified there".

The split of DKIM vs ADSP is a good example of how to do that.

> and I mentioned elsewhere that 7.2 should probably be heavily chopped,

I agree on that, but then OTOH I also proposed additional text.

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Aug 2012 09:15:50 -0400

> able to say "here we cover what we left unspecified there".

-1, I don't think MTA to MTA is proper here. It will inherently BREAK 
as a MTA to MTA "Chain of Trust" hop to hop protocol.

I think this idea of adding MTA to MTA is born out of an erroneous 
notion people had a misunderstanding of SPF.  It is unnecessary and my 
view, would not be technically correct.

--
HLS

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Aug 2012 09:29:45 -0400

>> I guess most senders mean they never send from any other address.

   Of course, _some_ senders might mean "Please reject anything you
receive from a different MTA".

   That's a point of obscurity in the spec. Some receivers _do_
interpret it that way.

> mechanisms) was not originated according to policy."

   I think Murray is saying the same thing, but he leaves out the
"originated" in "that doesn't match..."

> The difficulty is that neither the message nor the envelope contain
> enough data to allow arbitrary agents in the handling path to
> reconstruct accurately the environment where such an evaluation
> would be meaningful.

   _If_ the headers in the message were 100% accurate and 100%
trustworthy, an MTA could reconstruct the originating IP address
from the message headers and perform check_host() on it. But even
were that true, it would fall outside RFC 4408.

> That is, after a message goes from A to B to C, C can't be certain
> it has all of the right information to answer the question "What
> did B see?" which is what would really make SPF results actionable.

   That's a more precise statement.

   IMHO, we need to lay to rest reject-on-fail by a better understanding
rather than by a WGC calling consensus.

   Even if some senders intend reject-on-fail, and some receivers
practice it, it lacks _any_ justification in the model of 4408 --
because the relationship between sender policy and receiver action
is illusory: there's nothing in the envelope to tell the receiver
whether the sending MTA is an originator or an intermediary.

   I suggest that reject-on-fail _be_ mentioned; but described as
being based on a faulty assumption that the sending MTA is an
originator.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Aug 2012 06:55:40 -0700

> by anyone acting as a protocol cop.

Taking each of these in turn:

Given that what you're calling "intended behaviour" is local policy,
and I think we're trending toward agreement that local policy cannot
be an edict of this document, I don't see how this can be resolved.
Rather, the intended behaviour is that the receiver's SPF code returns
a result based on the inputs to check_host().  What happens with that
information is essentially out of scope, but this document presents
some options when outright filtering is not a choice available to the
operator.  DKIM did the same thing; did you disagree with it then?

Why is the proposed Section 7 text (you just contributed to it in
another thread) poor?

They are spelled out clearly; Section 7.1 describes Received-SPF quite
well, and we have RFC5451 for the other alternative.

I don't understand your fourth point.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Aug 2012 16:55:08 +0200

>    That's a more precise statement.

It is possible for B to add an Authentication-Results field with SPF
results, and sign it using DKIM.  If C trusts B, it can then
wholeheartedly accept the message.  That scenario was considered while
discussing DKIM for mailing lists.  It turns out that if C trusts B,
then it can accept the message anyway.

That technique might still be useful, e.g. for forensics purposes.

> being based on a faulty assumption that the sending MTA is an

It would be enough to consider the helo identity to ascertain that
point.  A rather scarce information if one misses a reputation system,
but let's recall the declared purpose of SPF was just to force
spammers to use their own domain names.

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Aug 2012 10:57:23 -0400

> practice it, it lacks _any_ justification in the model of 4408 --

hmmmmm, if I follow you, I don't agree with that.  I think its very 
very clear, since day one.

> whether the sending MTA is an originator or an intermediary.

Serious -1 John.  Just two things here, 1) you can count the hops and 
2) SPF is not as payload (RFC5322) protocol,

> being based on a faulty assumption that the sending MTA is an

IMO, what we should not be doing is reinvent SPF; its theory, the 
problem set and the solution it offered over and beyond anything else 
as one of the fastest entry, fastest adopted SMTP add-on in well, SMTP 
history.  Today, I will surmise it as follow:

   ?ALL is a waste on the system across the board.

   +ALL is also a big waste, but could be used with add-ons.

   ~ALL is less of a waste but explorers are looking at augmented
    with other methods. At this point, it seems to be heuristics,
    but some at looking it with DKIM w/o ADSP in some fashion. I believe
    Microsoft stated they were experimenting with:

       SPF.softfail + DKIM/ADSP.discard

   -ALL was designed to be independent of anything else and is 100%
    deterministic.  To me, finding a FAULT has a higher payoff then
    anything in this era of high volume abuse.  The faster to filter
    the junk, the more you can apply augmented "Heuristic" reputation
    stuff.  But then again, we been there before with this debate?
    No rights/wrongs, to me, SPEED of achieving yields and results
    is what to shoot for in order to avoid the "too late to fix"
    abuse issues due to "learning."

This has nothing to say when it does fail with transition points 
(multiple hops, open relays, etc). We all knew this. Poor Domain 
understanding of their outbound mail network,  Hosting use cases, etc, 
is a source of this.  Kludges like SRS were proposed, I think the BATV 
too, but I never supported it so I don't know but it sounded like an 
SRS thing.  Then we have the PATH solutions (DKEYS, DKIMS) were 
offered but there too, it failed to address the "middle ware" hop 
problem and 3rd party controls.

Nonetheless, with SPF, by far and without a doubt, the industry 
accepted this SPF bad part with the overwhelming good SPF offered with 
clear and concise policy definition capability.  DNS management 
software now offer SPF support in greater numbers, if not all. Not 
much support for other technologies, like DKIM.  SPF was and is still 
simple.  It really isn't that hard.  We are making it hard.  It took 
nearly 9 years to finally see a good payoff with a LMAP software with 
SPF prevailing.  At my site, I see a 16% protection of spoofed 
domains.  Of course, it will vary across the board. But this is good 
and as SPF promises for -ALL, it works.

-- 
HLS

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Aug 2012 11:57:22 -0400

> spammers to use their own domain names.

   I would love to discuss using the HELO identity; but I fear it
exceeds our charter.

   Nonetheless, if Alessandro replies quickly enough, perhaps he could
explain what he was suggesting before the WGCs can stop this thread.

   ;>)

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Aug 2012 12:00:16 -0400

Colleagues,

Think of this as an attempt at scope-limiting advice from the chair.
My natural tendency is always to try to allow people to work out their
disagreements by argument, but we are rapidly (re-)approaching the
point where people appear to be dug in on positions.  I'd like to
avoid making decisions about who is in the rough if I can.

>    stuff.  But then again, we been there before with this debate?

What does _any_ of that have to do with the sender's publication?
This is not attending to the distinctions among protocol,
implementation, and deployment.

The above is about what you can do with a system, once it is
deployed.  It is useful to think about these things.  It is _not_ part
of the protocol as such.

Alessandro Vesely's suggestion is on target here: this stuff doesn't
belong in the protocol document, and if someone wants to pursue it
they should write a draft that includes all these deployment matters.

I strongy encourage those who have opinions about these issues to
start writing that draft.  It becomes a possibile article for adoption
if the WG decides to recharter; otherwise, it can be pursued by other
publication means.  But we need something stronger than, "This is my
opinion," to continue talking about what are really operational
metters in the protocol document.  It doesn't belong there.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Aug 2012 12:22:46 -0400

I believe you have a very unfair view of my input. I am not implying 
anything you seem to be suggesting.

> What does _any_ of that have to do with the sender's publication?

The Domain defined it, it is "what is the sender policy?"

> implementation, and deployment.

I believe it is. But its your opinion that trumps here. I don't think 
I am saying anything wrong.  Note, I am not making a mountain here.

> deployed.  It is useful to think about these things.  It is _not_ part

I believe it is what is described in RFC4408, perhaps in different 
semantics and terms, such as defining what is authorizized or not, 
that has very powerful deterministic value and this is again described 
in RFC4408.  is it not?

> they should write a draft that includes all these deployment matters.

Now, in my opinion, the suggestion is changing the scope of the scope. 
I believe it does belong, which I would not be surprise what if people 
are gaining a greater sense of confusion by removing and attempting to 
define what SPF is or its no. I say its this. You say its that. Who's 
right and how do we determine it?

Again, I don't see a problem. I am trying to advocate a position that 
is not what you believe RFC 4408 is. I have SPF implemented as a 
vendor for thousands of customers and also deployed as as support site 
as one of the original adopters. I believe my input is legitimate and 
I'm seeing a very dangerous trend with a redefinition of what SPF is not.

> metters in the protocol document.  It doesn't belong there.

It should without saying these are my opinions and what others are 
saying are opinions too. There is no need for a draft or I-D. 
Everything I stated is already written in RFC4408 in some way or 
another. I didn't mandate anything. But input from all sides needs to 
be stated otherwise changes are made that are not quite, in my 
technical and engineering SPF experience, valid.  Some items I see as 
poor and do not wish to see it happen.  To me, this are changes to the 
SPF specifications. I don't think I have made any kind of suggestion 
or statement that even comes close to mandating a change or 
requirement.  If you can show it, please do.

If you are going to excommunicate me for being concern of the trend I 
am seeing here, then I there is something serious flawed about this WG 
and how it is being run.  Its not good if you need to continue to 
target me for your moderation when I simply provided a valid argument 
that counters another I view as incorrect.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Aug 2012 12:40:56 -0400

> saying are opinions too. There is no need for a draft or I-D.

I believe I was the first, and as an email to Barry early in the WG 
suggesting that another WG document, Deployment Guide, may be needed. 
  But that was to help accommodate support for new integrated ideas, 
such as DKIM which was obvious in the minds of some folks.

The different is that we got what seems a dispute about the "Theory of 
SPF" something already described as a dime a dozen RFC protocol, 
nothing special about it than another other mixed functional/technical 
RFC document.

I don't understand what you want Andrew quite honestly. I end this in 
the words of another well respected WG participant:

      http://www.ietf.org/mail-archive/web/spfbis/current/msg02373.html

      "Remember that the point of a standard is to tell people how
       to write their software so that it interoperates.

I think RFC4408 does that quite well as an IETF experiment and a World 
Wide pseudo-standard.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 27 Aug 2012 16:41:08 -0000

>wholeheartedly accept the message.

If C trusts B, he should just deliver the message rather than wasting
time second guessing B's filtering.

Do we really have to go through this tired argument yet again?

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Mon, 27 Aug 2012 11:19:05 -0700

Hello,

Here's a quick summary.

Scott Kitterman said that a sender policy is not about a sender 
telling a receiver what to do [1].  A sender policy is a statement 
that mail was either sent in accordance with the sender's policy 
(pass), it wasn't (fail), or one of several varieties of 
uncertainty.  Hector Santos disagreed that there was a 
misunderstanding [2].  Dave Crocker mentioned that clarity about the 
role of this specification is essential [3] and that (he could not 
find) language in the current draft that attempts the kind of clarity 
Scott's above text has.  Scott Kitterman mentioned that the 
misunderstanding is not new [4] and said that SPF was originally 
Sender Permitted From [5].  Alessandro Vesely mentioned that perhaps 
the WG will even recharter and complete the receiver policy afterwards [6].

Hector Santos mentioned the following:

   "Now, in my opinion, the suggestion is changing the scope of the scope. I
    believe it does belong, which I would not be surprise what if people are
    gaining a greater sense of confusion by removing and attempting to define
    what SPF is or its no. I say its this.  You say its that.  Who's right and
    how do we determine it?

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02347.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02349.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02348.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02351.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02355.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02368.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02392.html
8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02395.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Aug 2012 14:41:23 -0400

SM,

You are attributing me to a comment only applicable to a statement 
made by Mr. Sullivan suggesting Alessandro's input was on target with 
an idea of removing all deployment discussions in RFC4408:

    "Alessandro Vesely's suggestion is on target here: this stuff doesn't
     belong in the protocol document, and if someone wants to pursue it
     they should write a draft that includes all these deployment 
matters."

My comment basically disagrees with this idea. I believe it 
(deployment matters) does belong in RFC4408 and should not be removed 
and I believe will begin a major scope change creating confusion.  We 
don't need a deployment Guide within the limited scope we already have 
in SPF. However, I did note I suggested Deployment Guide to Barry 
Leiba for for the WG (and even volunteered to write it) but only 
related to integrated ideas with DKIM and also SPF2.0 (SenderID, 
Submitter), etc, not to remove the basic SPF client/server protocol 
description for RFC4408bis.

Thanks

S Moonesamy wrote:
> Hello,
> 
> Here's a quick summary.
> 
> Scott Kitterman said that a sender policy is not about a sender telling 
> a receiver what to do [1].  A sender policy is a statement that mail was 
> either sent in accordance with the sender's policy (pass), it wasn't 
> (fail), or one of several varieties of uncertainty.  Hector Santos 
> disagreed that there was a misunderstanding [2].  Dave Crocker mentioned 
> that clarity about the role of this specification is essential [3] and 
> that (he could not find) language in the current draft that attempts the 
> kind of clarity Scott's above text has.  Scott Kitterman mentioned that 
> the misunderstanding is not new [4] and said that SPF was originally 
> Sender Permitted From [5].  Alessandro Vesely mentioned that perhaps the 
> WG will even recharter and complete the receiver policy afterwards [6].
> 

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Mon, 27 Aug 2012 11:48:09 -0700

Hi Hector,
At 11:41 27-08-2012, Hector Santos wrote:
>made by Mr. Sullivan suggesting Alessandro's input was on target 
>with an idea of removing all deployment discussions in RFC4408:

I apologize for that.

Regards,
S. Moonesamy

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Aug 2012 15:27:15 -0400

S Moonesamy <[email-masked]> wrote:
> uncertainty.

   You seem to have missed several of my posts disagreeing that "a
sender policy is a statement that mail... wasn't" sent "in accordance
with the sender's policy" if check_host() returns "fail"; and stating
this is a point of obscurity in the (current) spec.

   This issue deserves to be considered. While Scott's statement
attempts to at least partly define what a sender policy is, it really
doesn't help to define sender policy in terms of the output of a
receiver action.

   It's possible, I suppose, that there may not _be_ any definition
of sender policy we can agree on; but if that's the case, we owe it
to our future readers to say so.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 27 Aug 2012 13:30:24 -0700

Hi John,
>this is a point of obscurity in the (current) spec.

I apologize for the omission.

I didn't include all the messages I read as it was meant as a quick summary.

>    This issue deserves to be considered. While Scott's statement

The issue is being discussed on this thread.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Aug 2012 16:41:30 -0400

> to our future readers to say so.

I'm about a day behind on this list, so this may have been discussed already 
...

My precise point is that sender policy is not defined " in terms of the output 
of a receiver action."  I receiver action is a function of the receiver's 
policy.  Personally, I think it's great when receivers reject mail that fails 
SPF checks (earlier this month I had such a rejection that led me to discover 
I'd misconfigured IPv6 address binding on a server), but I'm not at all 
confused that 4408bis can or should tell them to do such a thing.

So I don't understand your comment.  It seems to me like you are violently 
agreeing with me, but I'm not at all sure.

Scott K

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Aug 2012 19:59:04 -0400

Scott Kitterman <[email-masked]> wrote:
> My precise point is that sender policy is not defined "in terms of
> the output of a receiver action."

   Alas, that's not what your words said.

   Going back to your original post:
] 
] A sender policy is a statement that mail was either sent in accordance
] with the sender's policy (pass), it wasn't (fail), or one of several
] varieties of uncertainty.

(pass) and (fail) seem to refer to the output of check_host(), which
_is_ a receiver action.

   Perhaps there is a better way to phrase my statement; but I think
it very unwise to define "sender policy" in terms of the return-value
of check_host().

> A receiver action is a function of the receiver's policy.

   Calling check_host() can be considered a receiver policy, I suppose,
but I guess you meant "any action taken based on check_host()".

> Personally, I think it's great when receivers reject mail that fails 
> SPF checks (earlier this month I had such a rejection that led me
> to discover I'd misconfigured IPv6 address binding on a server),
> but I'm not at all confused that 4408bis can or should tell them to
> do such a thing.

   It may be that -all was intended to be a sender policy of "please
reject all mail that comes to you through an intermediary"; but that
was not documented in RFC 4408.

   We seem to have several folks who believe that was the intent,
and your definition of "sender policy" would support them.

   IMHO, "sender policy" should reflect what the sender _does_ --
not what the sender hopes some other MTA will do.

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Aug 2012 21:32:51 -0400

I don't quite follow the goal of the thread. It seems it attempts to 
provide some reminder for a new purpose for what SPF does with ALL 
policies which IME is already pretty well defined, described for 
receivers to follow for many years.  So is there something broken or 
is there something new we want to market or promote?

I believe the main focus should be to help the REPORTING market 
(Murray's work) by helping to emphasize Accept+Mark as well as the 
rejection, and this is why I issued the security note to help close 
any loophole with increase accept+mark activities, especially with 
those who currently do rejection and may wish to consider an 
accept+mark mode of operation in order to being leverage 
future/current reporting work.

As I indicated from vendor perspective in another post, our current 
stock software can not prepare accept+mark for deployment until we 
added separation logic. In the mean time, its reject only.

My point here is I believe we can probably move forward if all parties 
accept the idea that SPF does provide non-normative protocol 
instructions to the receiver for handling -ALL and accept+mark should 
be a new focus especially since we are also contemplating adding A-R 
and in addition, I believe there is an errata for RFC5451 to change 
the registry keyword from "hardfail" to "fail" to match SPF 
"received-spf: fail" headers.

This illustrates the goal of better supporting accept+mark mode of 
operations, and I hope we can welcome this and also rejects that 
already operate in this mode.

--
HLS

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Aug 2012 23:55:15 -0400

> (pass) and (fail) seem to refer to the output of check_host(), which

Upon reflection, I could have put this more clearly.  The sender policy is the 
list of authorized sources published in the SPF record.  The output of 
check_host() is an assessment of a message relative to that policy.  Is it 
policy conformant, policy non-conformant, or unknown (of some variety).

That assessment is not an action.  It's an input into receiver policy.  The 
receiver policy is entirely a local matter of how to dispose of the message.  
There are a number of things that can be done with it.

> it very unwise to define "sender policy" in terms of the return-value

Then what is it?  Would you agree it's the result of an assessment of a 
message relative to the sender policy?

> but I guess you meant "any action taken based on check_host()".

Yes almost.  

> was not documented in RFC 4408.

I agree.  It was not by accident that this is the case.

> and your definition of "sender policy" would support them.

SMTP time rejection was definitely a major consideration during SPF's 
development.  It's what we'd have like to have recommended, but there were 
enough edge cases to make that imprudent.  No matter how much some people like 
the idea, there are plenty others that don't.

> not what the sender hopes some other MTA will do.

I agree with this.  That's what I was trying to communicate.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Aug 2012 11:35:18 +0200

On Tue 28/Aug/2012 03:32:51 +0200 Hector Santos wrote:
> receivers to follow for many years.

I agree it's already defined, but certainly not "pretty well".

> So is there something broken or is there something new we want to
> market or promote?
> 
> (Murray's work) by helping to emphasize Accept+Mark

Yes, that's relatively new, but SPF specification certainly predates
it.  For that use, "pass" is the most interesting result.  The DMARC
initiative allows a domain to state that messages not passing SPF or
DKIM be quarantined or rejected.  In addition, RFC 6650 provides for
reporting spam to an authenticated domain's abuse-mailbox.

Specifying Accept+Mark possibilities is definitely out of scope for
SPF in general, and for our current charter in particular.  However,
in view of that new tendency (or "market", if you prefer) it does make
sense to produce a cleaned-up specification of SPF, getting rid of all
the badly defined receiver behavior.

As soon as I get back to my office (next week, that is) I'll post a
couple of drafts, as suggested by Andrew, to fully illustrate the
concept:  The cleaned-up SPF spec, and the receiver policy.  Scott
will use the parts of the first one as he likes.  The second one will
only be useful upon rechartering.  However, don't think that
standardizing an SPF protocol that does not at all consider rejection
will have any visible impact on behavior.  Normatively, it changes
nothing about receiver behavior.

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Aug 2012 07:12:43 -0400

> I agree it's already defined, but certainly not "pretty well".

ok, but what is broken about it, perhaps is what I am seeking?  What 
problem are we seeing?  What are trying to fix?

> the badly defined receiver behavior.

Yes, but that's what I scratching my head about. What badly defined 
receiver behavior? What specifically are we talking about and what is 
bad about it?  What issues is it causing that we need so much time 
with it here?  Are we just talking about uppercasing some keywords?  I 
am just wondering if there anything wrong other than what we might 
want to focus more on, like accept+mark.   The spec is peppered with 
receiver protocol instructions and except for issues already outlines 
and worked on to fix here and there, I don't see anything particular 
wrong with SPF as far as receiver behavior.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Aug 2012 19:41:28 +0200

On Tue 28/Aug/2012 13:12:43 +0200 Hector Santos wrote:
>>> what SPF does with ALL policies [...] IME is already pretty
>>> well defined, described for receivers to follow for many
>>> years.
>>
> ok, but what is broken about it, perhaps is what I am seeking?

Maybe what you are seeking cannot be defined within SPF, but hinges on
the (missing) definition of a receiver policy.

> What problem are we seeing?  What are trying to fix?

If one refers to SPF receiver behavior, people can righteously point
out that no such thing is defined.

> with it here?  Are we just talking about uppercasing some keywords?

That is because of the way our mind works.  At times, one may be
unable to solve a simple equation without using paper and pencil.  At
times, one may be unable to get a protocol on focus if the keywords
are not used correctly.

> I am just wondering if there anything wrong other than what we might

SPF doesn't specify any receiver behavior, yet.  Focusing ghost specs
is difficult.