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

From: S Moonesamy <[email-masked]>
Date: Sun, 09 Sep 2012 18:45:04 -0700

At 18:32 09-09-2012, spfbis issue tracker wrote:
>#58: Local policy in 4408bis
>
>  Message posted by John Levine on 9 Sept 2012:
>
>  The checking software can process the mail based on local policy.
>
>  If it rejects, that's local policy, too.  I really think that we need to
>  prune out the advice that implies that recipients are required to do
>  anything specific with SPF results.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html

I opened a ticket for local policy.  I suggest moving the "local 
policy" discussion to this thread.  Please comment on the above so 
that it can be determined whether it is an acceptable path from which 
to proceed.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 Sep 2012 11:15:55 +0200

On Mon 10/Sep/2012 03:45:04 +0200 S Moonesamy wrote:
>> If it rejects, that's local policy, too.  I really think that we
>> need to prune out the advice that implies that recipients are
>> required to do anything specific with SPF results.
>>
> that it can be determined whether it is an acceptable path from
> which to proceed.

That seems to be consistent with Murray's vision of a split, as given
in http://www.ietf.org/mail-archive/web/spfbis/current/msg02700.html

Does this thread/issue include considerations about the contents of
the revised charter?

---

From: S Moonesamy <[email-masked]>
Date: Mon, 10 Sep 2012 03:11:40 -0700

Hi Alessandro,
>Does this thread/issue include considerations about the contents of

Sorry for not provide context.  Barry Leiba responded to a comment I 
made about a sentence in Section 2.5.4 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html 
).  Text was suggested in the messages at:

  http://www.ietf.org/mail-archive/web/spfbis/current/msg02710.html
  http://www.ietf.org/mail-archive/web/spfbis/current/msg02711.html
  http://www.ietf.org/mail-archive/web/spfbis/current/msg02712.html

and there was a comment from John Levine ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html ).

This is not directly related to a revised charter or any split.  I 
cannot tell whether there is agreement or not about whether a message 
rejection or any other action following a SPF evaluation is a matter 
of local policy.  This thread is to get a sense of views about that.

As a possibly bad example, is the action taken after a SPF evaluation 
an operator decision or is it up to the implementation?

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Sep 2012 07:53:25 -0400

S Moonesamy wrote:
> http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html ).  
> Text was suggested in the messages at:
> 
> rejection or any other action following a SPF evaluation is a matter of 
> local policy.  This thread is to get a sense of views about that.
> 
> As a possibly bad example, is the action taken after a SPF evaluation an 
> operator decision or is it up to the implementation?
> 

 From Issue #29, it evolved to #33 and now #58 regarding local policy 
(LP). Fascinating! LP was never in question.  Generally, a protocol 
spec describes what options to make available to Local Operators!

As I stated a few times, I believe we can resolve this in section 
2.5.4 by defining what MARK means. (Issue #29).  This was the original 
points and proposal stated back in April, 2012

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

              ------------------
The following is update "starter text" for proposing 2.5.4 text 
changes. I personally don't care if the RFC2119 language is removed as 
long as the basic ideas and insights are cited.

NEW:

    2.5.4.  Fail

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

    When the result is a "Fail", the checking software MUST offer local
    receiver SPF deployments the option to choose between marking and
    classifying (MARK-ON-FAIL) the message having failed the domain
    SPF policy or rejecting the mail outright (REJECT-ON-FAIL).

    When the REJECT-ON-FAIL option is used, the SMTP server MUST 
reject the
    mail during the SMTP transaction and it SHOULD issue a permanent
    rejection reply code of 550 and for servers supporting extended
    reply code [RFC3463], use a policy based rejection description subject
    sub-code of 5.7.1. The following are some examples of REJECT-ON-FAIL
    server responses:

        550 SPF MAIL FROM check failed:
        550-5.7.1 SPF MAIL FROM check failed:
        550-5.7.1 The domain example.com explains:
        550 5.7.1 Please see http://www.example.com/mailpolicy.html

    When the MARK-ON-FAIL option is used, it server SHOULD report this
    failure by adding a Receiver-SPF header to the received message. See
    Section 7.

    The REJECT-ON-FAIL should be regarded a System Level local policy for
    global filtering for all users, where the MARK-ON-FAIL should be 
regarded
    as a User Level Policy framework where good vs bad mail is separated
    for the user.

    Since the receiver option to either mark or reject should provide the
    same negative failure outcome of the message to the user, the receiver
    applying the the MARK-ON-FAIL option SHOULD also separate the 
message in
    appropriate user in-box folders, i.e. Junk E-MAIL. The primary 
reason for
    this is related to the type of MUA being used by the user. If an 
online MUA is
    used, then the backend host can control the display of separate 
folders. If an
    offline MUA is used with POP3 mail pickup, the backend POP3 server 
SHOULD NOT
    combine the failed separated mail with the normal mail pickup. If 
the MUA is
    using IMAP [RFCxxxx], then this will continue with a safer 
separating of
    folder displays for users. Overall, the local site SPF deployment 
of MARK-ON-FAIL
    SHOULD be aware of how it users are accessing the mail.

        ---------------

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Sep 2012 07:06:07 -0700

On Mon, Sep 10, 2012 at 3:11 AM, S Moonesamy <[email-masked]> wrote:
> This is not directly related to a revised charter or any split.  I cannot
> tell whether there is agreement or not about whether a message rejection or
> any other action following a SPF evaluation is a matter of local policy.
> This thread is to get a sense of views about that.

Indeed, I think we're still getting ahead of ourselves.  There's no
rechartering on the table that I've seen, only something of the form
"If we want to do this, here's the way."  The first half of that
hasn't resolved yet.  Also, there's a difference between a charter
change and a milestone update, and it's not clear we even need the
former for the proposal before us.

> operator decision or is it up to the implementation?

I'm not sure there's a difference.  Either way, I don't much like the
idea of a protocol specification telling people what options their
implementations have to have.  I certainly can't think of an example
of another protocol specification that does so.  At best, the material
needs to be presented so that such things are inferred by the reader,
not stated by the editor(s).

Put another way, the stuff we're haggling about here does not affect
SPF interoperability one bit, so it's out of place in a protocol
document.

In my view, proper protocol specifications are like man pages (for
those of us that are UNIX people): present general context, specify
inputs and options, specify outputs, then specify mechanism, and give
the consumer just enough information to be able to make basic use of
it.  There's nothing in that idea about how it has to be exposed to
end users.  SPF is no different.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2012 10:28:38 -0400

No hat.

On Mon, Sep 10, 2012 at 07:06:07AM -0700, Murray S. Kucherawy wrote:

> implementations have to have.

Another way of saying that is that, if something is required, then
it's not OPTIONAL, but REQUIRED.  Certainly, protocol specifications
tell people what required elements their implementations have.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Sep 2012 07:44:59 -0700

> tell people what required elements their implementations have.

Right, I think.

The point I'm getting at is this: If we agree with the premise "What
an operator does with SPF results is a matter of local policy", then
also saying "You MUST provide a configuration knob for reject globally
vs. mark per-user" (or anything of the sort) exceeds that premise.  We
can't say "It's local policy" (meaning "It's completely up to the
operator") and then say "Here are your local policy choices."

We ought to say: "If you choose to reject, here's how we think you
might best do so.  If you choose to mark, here's how we think you
might best do so.  Those are the most common handling options.  Or,
you could do something else altogether if that's appropriate for your
environment."

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Sep 2012 10:54:12 -0400

I hope this is just a matter of semantics but I don't think the 
industry would of gotten very far with such questionable views on 
protocol engineering, client/server software designs, etc.  There is 
some common sense that needs to be expected and overall, what it means 
to be SPF "ready", "supportive", "compliant",  etc.

I've always felt this was an example of a yet another philosophy issue 
between developers and administrators. I've seen it under various 
SDOs, including the IETF, FSTN, etc.

At the end of the day, we have automation, we have software with knobs 
and switches. Traditionally, a technical specification is extracted 
from the functional specification.  IMO, whats going on here is quite 
normal - we are finding the "bugs" in the functional specs.   In this 
case, the SPF compliant receiver must be programmed to do and offer 
administrator local policy configurations for:

   reject
   accept, mark,
   accept, not mark

The question is if there is a common functionality in the form of 
"mail separation" that is inherently provided with rejection also part 
of the accept w/o marking of a SPF failed message?

Its not a matter of local policy per se, its a matter of defining what 
the programmer will offer the operators in order to satisfy their 
needs in Local Policy.

Personally, I don't know where all this is going but its not what I 
expected when it simply started with issue #29 requesting that we 
define what MARKING meant.

-- 
HLS

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2012 11:19:38 -0400

No hat.

> operator") and then say "Here are your local policy choices."

I think by that you mean that one can say, "Here's the local policy
menu," but we can't say, "Here's what you have to do under your local
policy," right?  I think we are allowed to do the first (though I
don't think we should in this case), but not the latter.
 
> you could do something else altogether if that's appropriate for your

+1

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stuart D Gathman <[email-masked]>
Date: Mon, 10 Sep 2012 11:54:16 -0400

> an operator decision or is it up to the implementation?
For SPF Fail, publishers of SPF don't really care what the receiver 
*does* with the failing email (maybe they accept it, and use it to train 
a spam filter, then throw in the bit bucket).

Instead, spf4408bis should say what NOT to do for an SPF fail.

For a given domain 'example.com':

You SHOULD NOT apply any reputation from emails with SPF Fail "from" 
example.com to emails with SPF Pass from example.com.  (In general, 
reputation for each domain:spfresult pair should be tracked separately.)

You MUST NOT send a DSN or other MAIL FROM <> response to an alleged 
return path with SPF Fail "from" example.com.

The last one is truly a protocol issue.  Receivers can still justify 
sending a DSN by pretending that they didn't actually check SPF, but we 
should make it clear that sending a DSN for an SPF FAIL result is a 
protocol violation.

Beyond that, spf4408bis can only suggest possible applications for SPF 
results in receiver policy.  What they choose to do does not directly 
affect email protocol.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Sep 2012 11:18:28 -0700

> don't think we should in this case), but not the latter.

I think we're agreeing, but I'm not certain.

My issue with "the local policy menu" is that it's a closed set.  I
perceive that as "implementers have no choices but this list we put
before them", and I think that's wrong-headed, at least in the context
of what a receiver does with content when we can't possibly know what
the receiver's constraints are, in terms of both technical and human
factors.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Sep 2012 11:20:53 -0700

On Mon, Sep 10, 2012 at 8:54 AM, Stuart D Gathman <[email-masked]> wrote:
> For SPF Fail, publishers of SPF don't really care what the receiver *does*
> with the failing email (maybe they accept it, and use it to train a spam
> filter, then throw in the bit bucket).

I think that's ideally correct, but not actually correct.  Some
publishers want very badly to control or at least influence strongly
what the receiver does with the failing email.  The debate appears to
be about whether a protocol document should really do that.

> results in receiver policy.  What they choose to do does not directly affect
> email protocol.

+1.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2012 14:37:18 -0400

No hat

> the receiver's constraints are, in terms of both technical and human

Right.  What I was saying is that there are cases where, for protocol
purposes, you actually do have a closed set, and we have no trouble
with that.  "Here are your protocol-permitted options, but you can do
anything at all inside these rules."  IDNA is like this, for instance:
zone operation is a local matter, and in principle you could put
anything at all in your zone; but IDNA limits your choices for the
purposes of interoperation with anyone else.  SPF, actually, is _also_
like this: by overloading the TXT RRTYPE and giving it semantics at
the owner name, we are effectively restricting what everyone (even
people not implementing SPF, please note) may put in their TXT
records.  This is the sense in which it is ok, in my opinion, to
provide a local policy menu.

In the particular case we are talking about, such restrictions don't
apply because there is fundamentally no interoperation problem: local
mail policies are _by definition_ local only.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Commerco WebMaster <[email-masked]>
Date: Mon, 10 Sep 2012 12:38:25 -0600

+1

Alan M.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Sep 2012 11:54:45 -0700

> provide a local policy menu.

That brings up two points:

1) Just to complete this thread, are you saying we do present a menu
to publishers, since there's a closed set of mechanisms and modifiers
defined here?  With that I totally agree.  Just not at all to the
receiver side.

2) On a related note, I reviewed the IESG evaluation record for
RFC4408, and I note that there was an ABSTAIN position recorded for an
AD who considered SPF an abuse of the DNS.  Is there anything we could
or should do to prepare for that kind of thing happening again as we
go for Proposed Standard?

> mail policies are _by definition_ local only.

Whew!

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 10 Sep 2012 12:15:11 -0700

Hi Murray,
>go for Proposed Standard?

There is not much that can be done to prevent that from 
happening.  It would make matters easier if the draft is up to par 
with other Proposed Standards.

Regards,
S. Moonesamy (speaking for myself)

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2012 15:33:23 -0400

No hat.

> go for Proposed Standard?

No, and I personally hope that someone on the IESG takes such a
position, because I also think it's an abuse of the DNS to specify
semantics for a TXT record.  (The parking lot is, in vast chunks of
North America, the most significant architectural feature for miles.
Just because that's the way the world is doesn't mean I have to like
it.  Same thing here.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2012 19:53:31 -0000

>might best do so.  Those are the most common handling options.

Actually, we don't even know that.  A lot of receivers just stir the
SPF results into the secret sauce, logging the result only in a custom
header (spamassassin) or an opaque cookie.  By volume of mail
received, that may well be more common than marking with a header and
certainly more common than reject on SPF fail.

Again, I think that we should just take out advice about receiver
policy.  It has nothing to do with making SPF interoperate, it's
speculative, and the current advice has little to do with what
systems really do.

R's,
John

PS: On the other hand, we really do need to nail down the formula
for the lookup limit, since that does affect interoperability.

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2012 19:54:57 -0000

>reputation for each domain:spfresult pair should be tracked separately.)

Receiver policy.  Out of scope.  Not our job.

>return path with SPF Fail "from" example.com.

Receiver policy.  Out of scope.  Not our job.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Sep 2012 17:37:27 -0400

> Receiver policy.  Out of scope.  Not our job.

So what is the minimum SPF receiver policy for "Behavior?"

Is there any recommendation?

Even a claim of "out of scope" brings some minimum level of advice for 
handling:

    Always accept and mark?

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Sep 2012 21:00:39 -0400

> Just because that's the way the world is doesn't mean I have to like

+1.  I'm was always a SPF supporter and also a critic of its obvious 
high processing waste, especially in the known, expected short term 
any theoretical DNS based policy will be until critical mass is 
reached.  But to me, more importantly only seeing a high payoff, a 
RETURN with the -ALL exclusive operations DOMAIN mail sender policy.

We DO NOT have possibility of a high return in any of the SPF policies 
EXCEPT -ALL policies.  For all policies except -ALL, itt would be 100% 
pure waste and to reduce the waste, we needed more augmented methods 
which I deemed:

             "Batteries Required"

Thats the key different in implementation and deployment of SPF 
receiver practices.

SPF -ALL needs nothing else [1].  The other policies do perhaps and 
there is no concrete solution that any one can write about.  Maybe 
they could but it will see need "Batteries" and worst, everyone will 
need to use the same "Batteries" [2].

I just hope we can remain focus and not get too lost again with the 
theory of SPF. Sure, it would of been nice if uppercase were used but 
I don't think will alter the protocol anyway. It won't change anything.

      For SPF fail, Receivers MUST offer one of two options at a 
minimum to
      local policy operators:

      - SMTP reject the transaction
      - SMTP accept and add Receiver-SPF trace header.

      If the failed message is accepted, it is HIGHLY RECOMMENDED the
      accepted message is distinguishable from the rest of the targeted
      user's normal collection of new mail, i.e. "Junk Email, Spam Mail"
      folders to allow the user to determine it is a suspicious message.

I don't think the above language changes anything.  Current systems 
may in fact be already compliant with A) Rejection and/or B) Accept 
and Separation.  If not, like us where we reject only currently, then 
they now will learn doing (B) will take extra work. Either they 
support it, update their code or stay with the status quo and just 
reject the mail.  Nothing changes, but 4408BIS is improved as a 
official standard with the security Tees crossed and Eyes dotted.

-- 
HLS

[1] We know of its #1 flaw with expected relays at the MX final 
destination hop used by mail senders.

[2] Same arguments were made in MARID which did not allow CSV/DNA and 
DomainKeys as well to get traction - reputation was needed and people 
were looking for something that did not require some future business 
to be available. SPF did not need a tertiary business plan of Trust 
Vendors/Reputation Market brokers.

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Sep 2012 21:15:51 -0400

Interesting approach.  I guess I see it easier with:

    See Section 2.3

    The domain has declared this transaction as authorized.
    By using -ALL, per Section 2.3, the domain copyrighted
    and responsible owner is exposing legal permission for
    you to reject and throw it away with Full Force!

    If you do accept this message, it is highly advise that
    you color code, negative classify (See section 2.3)
    this message with "Unauthorized Domain" notifications and
    classification, whatever UI ergonomics best serves your
    Mail Service and overall reduces all harm to the user.

    See Section 2.3

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

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Sep 2012 22:06:33 -0400

So what is the goal of these issue I wonder?

Are we trying to negate the idea that REJECTION is possible?

Are we trying to discourage the idea of REJECTION?

RFC4408 is peppered with Receiver Protocol Instructions, Insights 
information, Receiver "Local Policy" insights and concepts.

Over 26 instances of the usages for the term "Reject."

Over 29 instances of the usages for the term "Authorization" and 
authorization checks, where its performs, how its performed, etc, etc.

It just really odd that we are arguing what SPF was and still is.  It 
doesn't matter of X number of sites does ACCEPT and MARK operations, 
REJECTION is very much part of protocol and ALL SOFTWARE are coded to 
support it.

The issue is whether current support for ACCEPT+MARK transactions are 
secured for the user?

Is it?  Do all the BIG BOYS and all the SMTP vendors with SPF support 
and open source SPF APIs all have programmable options to:

     ACCEPT+MARK+SEPARATE

the mail?

Is this the standard practice and anything else (like rejection) 
SHOULD NOT be part of the SPF 9+ year old framework and philosophy?

I am just really lost on where we are going with all this.

S Moonesamy wrote:
> I opened a ticket for local policy.  I suggest moving the "local policy" 
> discussion to this thread.  Please comment on the above so that it can 
> be determined whether it is an acceptable path from which to proceed.
> 
> Regards,
> S. Moonesamy

-- 
HLS

---

From: SM <[email-masked]>
Date: Tue, 11 Sep 2012 03:32:20 -0700

Hi Murray,
>the consumer just enough information to be able to make basic use of

I'll comment on the document quality of 
draft-ietf-spfbis-4408bis.  The layout is, in most parts, similar to 
the RFC 4408 layout.  One possible explanation for why that RFC is 
lengthy is because the author of the draft did not have time to make 
it shorter when the draft was submitted.

The draft-ietf-spfbis-4408bis-07 starts with an introduction of the 
protocol.  It then discusses protocol status and experimental history 
and introduces the terminology which is to be used throughout the 
document.  That is followed by a discussion of the operation.  The 
protocol part, if it can describe as that, is about publishing 
authorization and checking authorization.  The document then explains 
how the (SPF) result is to be interpreted.

The DNS record is then introduced and there is some discussion about 
DNS.  The document then explains the check_host() function and its 
arguments.  It then explains the result and processing.  The 
mechanisms are introduced, followed by modifiers.  There is a 
discussion of DNS limits and domain specification.  Mechanisms are 
then defined, followed by modifier.  The draft then explains how to 
record the result.  Macros are defined after that.

The document then attempts to outline the major implications that 
adoption of the specification will have on various entities involved 
in Internet email.  It discusses about sending domains, then DNS 
resource considerations and mediators.  That is followed by a 
discussion about policy.  The document ends with a discussion of 
security considerations.

I noticed during section-wise reviews that some topics are discussed 
in several parts of the document.  That can be a layout issue which 
affects document clarity.  I found it difficult to identify the 
requirements for interpretability, i.e. what must be done for the 
protocol to work, what must be done unless you have a very good 
reason not to do so and what is optional.  There is excessive usage 
of RFC 2119 key words.  Most of that can be traced back to RFC 
4408.  I mentioned "checking software" previously as a nit.  The 
terminology used isn't consistent throughout the document.

It can be argued that any or all of the above is ok.  I may be asked 
whether I have personally reviewed the document that the WG considers 
as ready for publication and, in particular, do I believe it is ready 
for forwarding to the IESG.  I would say no and point out that it is 
the consensus of SPFBIS.

Regards,
-sm

---

From: John Leslie <[email-masked]>
Date: Tue, 11 Sep 2012 06:59:56 -0400

John Levine <[email-masked]> wrote:
> [Stuart D Gathman <[email-masked]> wrote:]
> 

   While "receiver policy" is indeed not our job, this is an example
of a unmistakeable _sender_ policy: "I didn't send this!"

   I wouldn't write this as a MUST NOT, of course; but it feels as if
it deserves a SHOULD NOT...

--
John Leslie <[email-masked]>

---

From: "John R Levine" <[email-masked]>
Date: 11 Sep 2012 09:21:05 -0400

> of a unmistakeable _sender_ policy: "I didn't send this!"

No, it's saying that I shouldn't send a bounce because you say the message 
is bogus.  That's your policy statement, not mine.

It may well be a good idea not to bounce on SPF failure, but that's not 
for you, or the SPF spec to say.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Sep 2012 08:08:31 -0700

On 9/11/2012 3:32 AM, SM wrote:
>   I may be asked
> whether I have personally reviewed the document that the WG considers as
> ready for publication and, in particular, do I believe it is ready for
> forwarding to the IESG.  I would say no and point out that it is the
> consensus of SPFBIS.

SM,

Please clarify your last sentence.  Perhaps it is the 'and' that 
confused me.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: John Leslie <[email-masked]>
Date: Tue, 11 Sep 2012 11:25:31 -0400

> is bogus. That's your policy statement, not mine.

   You can write better than this, John: I know you can.

   ("I" and "you" are ambiguous, for anyone having trouble with the
English grammar...)

> for you, or the SPF spec to say.

   (Note that John Levine snipped the part where I distinguished MUST
from SHOULD.)

   In brief, this deserves a "Straw Man Alert!" John Levine is responding
to something I didn't say.

   In my experience as an ISP, "blowback" DSNs are quite useless (that
being when _I_ get the DSN because a spammer forged the MAIL-FROM).

   If the sender policy is a clear "I didn't send this" (as I claim,
but John Levine seems to dispute), it's essentially no step at all to
"I don't want blowback DSNs". There is, after all, nothing useful
the domain receiving such DSNs can do; and they either cost support time
or force you to ignore pretty-much all DSNs. (If I were interested in
learning when spammers forge my domain, I wouldn't advertise -ALL.)

   That is why I said it feels like it deserves a SHOULD NOT. SPF
holds great promise of informing decisions of whether to reject at
SMTP time or accept in hopes the email might prove useful after all.
IMHO, an SMTP-time reject is more useful to honest senders.

   Obviously, YMMV...

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2012 16:08:20 -0000

My goodness, you worked hard to misread what I said.

>   (Note that John Levine snipped the part where I distinguished MUST

Sure, since neither one belongs in the SPF spec.

>"I don't want blowback DSNs".

Gee, did we just drop through a wormhole into 2003 or something?
Despite a great deal of wishful thinking, such as evidenced in the
paragraph above, SPF failures don't always mean that a message is
spam, nor that the putative sender didn't send it.  It's strongly
correlated, but as we all know, there is plenty of legitimate mail
that SPF can't describe.

Nobody wants blowback DSNs, but you, tne SPF publisher, don't get to
tell me what I do with my mail, nor can you perfectly predict what
will be blowback and what won't.  As has been noted about a million
times before, there are perfectly plausible forwarder scenarios in
which sending the DSN is the right thing to do. You have no idea how
my mail system is set up, and it is pure hubris to assert that you
know enough to dictate my behavior.

R's,
John

PS: If you were planning to reply along the lines that even if the SPF
is wrong, I should follow it anyway, please don't.

---

From: SM <[email-masked]>
Date: Tue, 11 Sep 2012 09:12:18 -0700

Hi Dave,
At 08:08 11-09-2012, Dave Crocker wrote:
>Please clarify your last sentence.  Perhaps it is the 'and' that confused me.

If I perform an individual review of a draft and my conclusion is 
that it needs more work, I say so.  If WG consensus says otherwise, I 
am fine with that.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Sep 2012 09:22:26 -0700

On 9/11/2012 9:12 AM, SM wrote:
> If I perform an individual review of a draft and my conclusion is that
> it needs more work, I say so.  If WG consensus says otherwise, I am fine
> with that.

ack. tnx.

d/

---

From: John Leslie <[email-masked]>
Date: Tue, 11 Sep 2012 12:34:00 -0400

> My goodness, you worked hard to misread what I said.

   No harder, certainly, than you did to _ignore_ what I said. :^(

> will be blowback and what won't.

   I assert that the SPF publisher has better information about this
than the SMTP receiver.

   YMMV, obviously.

> You have no idea how my mail system is set up, and it is pure hubris
> to assert that you know enough to dictate my behavior.

   There's that straw-man, again... :^(

   (It's really time for the ad-hominem stuff to stop: I don't intend
to respond to any further ad-hominem posts.)

---

From: "John R Levine" <[email-masked]>
Date: 11 Sep 2012 13:03:50 -0400

>   I assert that the SPF publisher has better information about this

Wow, we really have fallen through a wormhole back to 2003.  Time to go 
look for some duct tape.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Sep 2012 10:45:54 -0700

>    I assert that the SPF publisher has better information about this

I assert that history has shown us that this is simply not the case.

I've come to realize that message authentication work often blurs the
lines between "the way it is" and "the way it ought to be".  We as a
community cling tenaciously and furiously to the latter as we fight
the gravity of the former.

> to respond to any further ad-hominem posts.)

This whole exchange is on the ugly side, but John's post wasn't ad hominem.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Sep 2012 10:48:41 -0700

On Tue, Sep 11, 2012 at 3:32 AM, SM <[email-masked]> wrote:
> I noticed during section-wise reviews that some topics are discussed in
> several parts of the document.  That can be a layout issue which affects
> document clarity.  I found it difficult to identify the requirements for
> interpretability, i.e. what must be done for the protocol to work, what must

I think you meant interoperability there.

> It can be argued that any or all of the above is ok.  I may be asked whether
> I have personally reviewed the document that the WG considers as ready for
> publication and, in particular, do I believe it is ready for forwarding to
> the IESG.  I would say no and point out that it is the consensus of SPFBIS.

There's no "may" here.  That's part of the PROTO writeup the shepherd
(probably you or Andrew) needs to prepare before the document can go
to the IESG. That is, you will indeed be asked that.

-MSK

---

From: John Leslie <[email-masked]>
Date: Tue, 11 Sep 2012 14:03:36 -0400

> I assert that history has shown us that this is simply not the case.

   Aha! The basis for a good discussion...

   Do you mean that SMTP receivers have better information (about what
will be blowback), or that neither has any useful information?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Sep 2012 11:37:08 -0700

> will be blowback), or that neither has any useful information?

I mean the receiver is the one who gets to see by which paths mail
arrives.  Consider that there are two sets of mail paths, namely (a)
those that the domain owner thinks it's using, and (b) those by which
mail actually arrives.  Those who claim the senders know better and
should be able to assert receiver policy appear to operate under the
impression that (a) is absolute or that the two sets are equal, when
in reality we've seen that (b) is nearly always a proper superset of
(a).  The place in the resulting Venn diagram where the two do not
overlap is false negative territory, and it's potentially very painful
for receivers.

The very same thing came up in DKIM policy, which tried at first to
have a strong policy component, but we quickly learned that this
approximately impossible to achieve with sufficient reliability as to
be actionable.  Although people characterize this as "watering down"
of DKIM policy, it is merely acceptance of the reality that receiver
policy cannot be expressed with universal normative language.  Better
still, ADSP showed us that trying to force receiver-side policy can
cause collateral damage to uninvolved third parties.

I've yet to encounter a system anywhere in my career, from personal
machines to large corporate server clusters, where any of the policy
mechanisms coupled with message authentication schemes -- and that
includes SPF and ADSP -- are used in an absolute fashion.  So from
where I sit, if there's no industry demand for universal normative
receiver policy after all these years, we should stop trying to write
one, let alone the fact that it's not a protocol's business to do so.

We really need to stop trying to go there.

-MSK

---

From: SM <[email-masked]>
Date: Tue, 11 Sep 2012 11:33:20 -0700

Hi Murray,
>I think you meant interoperability there.

Yes.

>There's no "may" here.  That's part of the PROTO writeup the shepherd

:-)

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 11 Sep 2012 18:02:57 -0400

> We really need to stop trying to go there.

Things are a bit different now though.  We have RFC 6652 that gives domain 
owners a way to express an interest in feedback about these kinds of messages.

It does use MUST NOT on sending auth failure arfs if they are not requested.

I realize that's not exactly the same situation, but it's similar.

We probably can't, but it'd be nice to wrap this up into something that said 
SHOULD NOT bounce for non-pass SPF results and use auth failure arfs instead 
if they have been requested.  

Part of the purported benefit of SPF is that it allows you to take actions 
based on a name based identifier for SPF pass.  I think the flip side of that, 
that one shouldn't do so for non-SPF pass is equally reasonable.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2012 22:03:19 -0000

>will be blowback), or that neither has any useful information?

The former, of course, since many receivers have a pretty good idea of
who's forwarding mail to them, and how good a job of inbound filtering
they do.  For example, the DMARC reports that Google sends identify
the forwarders in impressive detail.

Really, this is all stuff that has been covered at length in prior SPF
arguments.  It's hard to see any value in rehashing it yet again.  If
you want to do so, it would be very helpful to refer to the previous
arguments and explain why this time is different.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Sep 2012 15:12:01 -0700

> if they have been requested.

If some set of implementations already have that provision in them, I
think it fits in the charter to document as a deployed enhancement.

-MSK

---

From: John Leslie <[email-masked]>
Date: Tue, 11 Sep 2012 19:08:21 -0400

Murray S. Kucherawy <[email-masked]> wrote:
> arrives.

   I'm not clear what that has to do with the perception of blowback.
(Perception, alas, is as close as we can get to "reality".)

> Consider that there are two sets of mail paths, namely
> (a) those that the domain owner thinks it's using, and
> (b) those by which mail actually arrives.

   We are pretty safe assuming that senders won't consider (a) blowback.

   ISTM that senders know better than receviers whether (b) is "blowback".

> Those who claim the senders know better and should be able to assert
> receiver policy appear to operate under the impression that (a) is
> absolute or that the two sets are equal, when in reality we've seen
> that (b) is nearly always a proper superset of (a).

   There seems to be a failure to communicate. :^(

   Clearly, the sender _cannot_ control what a receiver does with an
email. It is most unfortunate that SPF was sold to some senders as
a way to control what the receiver does. I hope that 4408bis will make
the reality clear.

   But the sender _can_ control what it considers to be blowback. The
sender _can_ apply disincentives to MTAs which send what it considers
to be blowback. (Yes, I have been the victim of this.)

> The place in the resulting Venn diagram where the two do not overlap
> is false negative territory, and it's potentially very painful for
> receivers.

   Indeed, receivers often find they must deliver email which has
received an SPF hard-fail. I hope that 4408bis will make that clear.

   But if they're not going to deliver it, an SMTP-time reject is
much more helpful than blowback (which often goes to a domain which
had no role whatsoever in the email in question, and thus there is
nothing useful for them to do about it).

   I am _only_ trying to suggest that in SPF hard-fail cases, the
SMTP-time reject is far more appropriate than a later DSN. An
SMTP-time reject is most likely to go to a sending MTA best able
to deal with the problem (especially if that MTA is a forwarder).
A later DSN would bypass the forwarder and reach someone unable
to rectify the situation.

   Obviously, there will be cases where neither an SMTP-time reject
nor a later DSN will happen. My claim is only that the sender has
better information on whether a later DSN is better or worse than
no error response as all.

> includes SPF and ADSP -- are used in an absolute fashion.

   They do exist -- but this is not what I'm talking about.

> So from where I sit, if there's no industry demand for universal
> normative receiver policy after all these years, we should stop
> trying to write one, let alone the fact that it's not a protocol's
> business to do so.

   You're pretty darn far off-base if you think I want SPF to
demand normative receiver policy...

   What I want is for SPF records to _mean_ something. It is not I
that want SPF to be a blindly-applied algorithm. IMHO, no
blindly-applied algorithm can be helpful to folks trying to find
the best SPF policy to advertise.

   Further, any blindly-applied algorithm that doesn't give
specific feedback on the result from the receiver running it to
the "sender" advertising it cannot help educate those who
advertise SPF records.

   (I expect to end up in-the-rough here -- that would be easier
if someone gave me the impression they were considering what I
actually say...)

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2012 01:10:24 -0000

>that one shouldn't do so for non-SPF pass is equally reasonable.

No, they're not at all symmetrical.  If SPF passes, you can be
reasonably confident that the message was sent by the domain that
passed.  If it fails, you don't know whether the message is bogus, or
it's a real message that arrived via a path that SPF can't describe.

Murray probably has his fingerprints on more mail than all of the rest
of us put together, so I would take his comments to heart.  Large mail
systems don't treat SPF fail as anything more than optional advice.
No matter what we put in 4408bis, that will still be true, and I don't
see any point in writing a standard that we know people won't
implement.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 11 Sep 2012 22:40:19 -0400

On Wednesday, September 12, 2012 01:10:24 AM John Levine wrote:
> >based on a name based identifier for SPF pass.  I think the flip side of
> >that, that one shouldn't do so for non-SPF pass is equally reasonable.
> 

I'm fine with not saying MUST NOT for that reason.  OTOH, SHOULD NOT stamps it 
a generally a bad idea (which I think is reasonable), but says go ahead if you 
think you know better.  I believe that's consistent with what you say you 
want.

While there are no RFC police, I have, on more than one occasion told people 
where had implemented $BAD_IDEA to get read some section of some RFC to learn 
about why it was a bad idea and they've taken it to heart.  

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Sep 2012 22:54:46 -0700

> think you know better.  I believe that's consistent with what you say you

The debate, then, is about whether RFC2119 language can be used to
describe an operational practice (in this case, local policy) that
isn't part of the protocol proper.  I believe the answer is "no".
Perhaps one of the co-chairs or an AD should weigh in on that point.

To be specific: The protocol itself works if the receiver generates
the result that the sender's published policy intended to provide.
The normative terms are available to be used such that implementers
will write something that works properly.  That's interoperability.
What the receiver does with the message afterwards doesn't change the
fact that check_host() did precisely what it was supposed to do.  The
protocol, at that point, is done.  No MUSTard we put on what happens
after that has anything at all to do with interoperability of the
protocol itself, and thus I'd say is inappropriate for a protocol
document (but not necessarily for an applicability statement, which
this is not).

Now, that's all true if we agree that SPF is a protocol between the
sending ADMD and the receiving MTA.  Since there are people who want
this MUSTard there, they must have something else in mind.

Hector, I believe, claimed that SPF is more of a protocol between the
sending ADMD and the MUA.  I don't think that's right because the
output of check_host() is not used anywhere as a signal to the MUA,
since MUAs can't reject messages; the best they could do is apply an
annotation (another kind of "mark") or simply decline to show the
message.  But we -- correctly, I believe -- shy away from making
assertions about what MUAs should do.  So what's left?  At best, one
could claim it's a protocol between the sending ADMD and the LDA.  I
don't think LDAs typically do rejection or "marking", though, and even
if they did, the rejection would need to be in lockstep with SMTP,
otherwise there's backscatter.  So I don't really know what to do with
this line of thinking.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Sep 2012 00:56:13 -0700

> (Perception, alas, is as close as we can get to "reality".)

Nothing, because I don't think that's what this thread was originally
about.  I went back through it and I couldn't find the point where
that subject came in.  Maybe that's why the other John was also
arguing policy issues.

I think it's probably quite appropriate to point out to people that
generating a DSN for something for which SPF failed is a questionable
practice.  I don't know about doing so normatively though, because it
has nothing to do with the definition of SPF as a protocol; it's
operational advice, which deserves non-normative treatment in a
protocol document.

(...which in turn means this seems to be more material for an
operations guide than I'd originally thought.)

> demand normative receiver policy...

But that's what this thread was about.  And the Subject: hasn't
changed since it was.  No wonder you think we're confused.

-MSK

---

From: SM <[email-masked]>
Date: Wed, 12 Sep 2012 01:51:56 -0700

>isn't part of the protocol proper.  I believe the answer is "no".

RFC 2119 language is about interoperability.  It is generally not 
used to describe an operational practice in a protocol document.

>fact that check_host() did precisely what it was supposed to do.  The

That's what the specification says in my opinion.  There is the 
problem definition, i.e. what problem the protocol seeks to 
solve.  This is from the Introduction section:

   "Although this feature is desirable in some circumstances, it is a
    major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
    Furthermore, many domain name holders are understandably concerned
    about the ease with which other entities may make use of their domain
    names, often with malicious intent."

That can be read as SPF attempts to:

   (a) reduce spam

   (b) restrict the usage of domain names in email to domain name holders

Item (a) generates controversies.  Item (b) works in some cases and 
does not work well with forwarding.  "It is always possible to 
agglutinate multiple separate problems into a single complex 
interdependent solution. In most cases this is a bad idea."

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 Sep 2012 10:59:47 +0200

On Wed 12/Sep/2012 09:56:13 +0200 Murray S. Kucherawy wrote:
> practice.

Yet, non-rewriting forwarders do so in order to let any DSN go to the
right recipient.  In RFC 5598's wording:

   The benefit of retaining the original MailFrom value is to
   ensure that an Actor related to the originating ADMD knows
   there has been a delivery problem.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Sep 2012 02:37:33 -0700

On Wed, Sep 12, 2012 at 1:51 AM, SM <[email-masked]> wrote:
> RFC 2119 language is about interoperability.  It is generally not used to
> describe an operational practice in a protocol document.

I think if we can all agree on that, then the required edits become
pretty obvious.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Sep 2012 02:42:58 -0700

>    there has been a delivery problem.

But non-rewriting forwarders aren't the ones generating DSNs, so I'm
not sure what point you're trying to make.

Someone who receives mail that passed through a non-rewriting
forwarder will probably get an SPF "fail".  That might be legitimate
forwarded mail, it might be fraudulent mail, it might be something
else.  In only one of those cases is it clear that a DSN would be
backscatter and ought to be avoided.  Reliably identifying that case
requires heuristics.  We can't normatively specify such things; the
best we can do is call out the condition and give advice (though
possibly not in the core protocol document).

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Sep 2012 09:10:31 -0400

No hat.  Well, maybe a 2119 weenie hat on.

On Tue, Sep 11, 2012 at 10:40:19PM -0400, Scott Kitterman wrote:

> OTOH, SHOULD NOT stamps it 
> think you know better. 

SHOULD NOT is an interoperability word that says that you'd better
have a pretty good reason not to do this thing.  Many of us argue that
any SHOULD NOT which does not say what happens if you violate the
condition is a misuse of SHOULD NOT.  Most importantly, SHOULD NOT is
not some sort of expression of what the consensus in good ideas or
taste is.  So it's not just that it's a "generally bad idea".  It
needs to have some interoperation consequence.

> about why it was a bad idea and they've taken it to heart.  

Yes, there's nothing wrong with explaining why something is a bad
idea.  (That need not be couched in SHOULD NOT, of course.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Sep 2012 13:56:55 -0400

On Tuesday, September 11, 2012 10:54:46 PM Murray S. Kucherawy wrote:
> > I'm fine with not saying MUST NOT for that reason.  OTOH, SHOULD NOT
> > stamps it a generally a bad idea (which I think is reasonable), but says
> > go ahead if you think you know better.  I believe that's consistent with
> > what you say you want.
> 

>From my POV, this is similar to the issue #33 thread, only more so.  One of 
primary drivers for development of SPF was to reduce "Joe job" bounces.  In 
this case, the MUSTard in play goes to achieving one of the main goals of the 
protocol.  It's not ancillary at all.

I guess I'll wait to see if there's anyone more greybeard around.

Scott K

---

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

Murray S. Kucherawy wrote:
> sending ADMD and the MUA.  

Sorry, I don't believe I have never provided any talk of such and 
would never do so.

But to be specific:

First, I said SPF is a MTA to MDA protocol. I think the information in 
RFC4408 and RFC5598 will back this model than anything else.

Second, I said there are different kinds of MUAs

    - Thin Online MUA, your browser for example

    - Fatter Online MUA, RFC based Offline reader using IMAP as a
      protocol, older school enterprises use EXCHANGE like groupware
      conferences methods. This can be also Native Online MUA which
      means they are more proprietary (i.e. Wildcat Navigiator, AOL,
      Prodigy, CompuServ, CCMAIL, etc).

    - Pure OffLine MUA, using as a store and forward protocol such as
      POP3.

and mixed ones.

IMAP has multiple streams (folders). POP3 has ONE stream (one folder).

With an Online MUA, one can say the ORIGINAL centralized mail system 
where there was no room (storage or hardware) for a client device to 
do any sort of work. It was purely online.  In this case, a Backend 
can separate the display mail into folders, i.e, "NEW MAIL" vs "SPAM 
FOLDER"

With a pure offline MUA, with you have POP3, I stated that the 
separation need to be  in place so that the single stream "new mail" 
is no lumped with an separated spam folder.  It is not unconceivable 
that a backend will collect all new mail from all the user's folders, 
not just the "new mail" bin, but this would be a case where it need to 
look at the MARKING to skip that one message from the total collection.

The main reason for this separation for the POP3 access is because one 
the offline reader gets it, it will need its own set of filtering to 
address this SPF failed issue and I stated very clearly (like in other 
WG with related ideas) that we can not depend on the Offline MUA to 
resolve it.

PS:

We deal with all kinds of "MUA" and the following provides an 
illustration of the complexity and advanced framework for multiple 
devices.

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 Sep 2012 15:00:56 -0400

> Perhaps one of the co-chairs or an AD should weigh in on that point.

The chairs have both said good things along this line; note Andrew's
comment especially.  As an AD, I'll add my agreement, but I'll also
add some other comments.

This is an important point, so note it well:
Not all normative text has 2119 keywords in it.

Let me say that again, in a different way:
Just because you decide not to put MUST or SHOULD (with or without
NOT) in doesn't mean that it's just fluff text that can be ignored on
whim.

AS A PARTICIPANT, I agree with Scott: if we have, by experience,
determined that it's a really bad idea to do X (where X might be to
silently delete mail purely on the basis of an SPF fail, or any other
such thing), then it's a really good idea to say so, and to strongly
advise against it.

As both a participant and an AD, I think such advice should not be
using 2119 language.  And I think that doesn't, in itself, make it
casual, non-normative advice.  If you want to give strong advice in
the form of an applicability statement, do so.  You can even label the
paragraph "Applicability Statement:", or put it in a section so
titled.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Sep 2012 12:24:28 -0700

> NOT) in doesn't mean that it's just fluff text that can be ignored on

For further clarification: Is the distinction about when 2119 language
is appropriate based on the main subject of the document?  That is,
since this document is supposed to define the SPF protocol, then 2119
language is only appropriate where something is defining an
interoperability aspect of SPF itself, and not for adjacent stuff like
applicability statements.  Correct?

> paragraph "Applicability Statement:", or put it in a section so

I think that's fine for this document if the size of such a section is
kept reasonable.  Otherwise, making a separate AS document seems to me
to be a much more palatable approach, and as a result that specific
set of material and the core documentation each have more breathing
room.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2012 19:27:35 -0000

>I guess I'll wait to see if there's anyone more greybeard around.

My beard's pretty grey and I'm in full agreement with Murray here.

Perhaps Dave or Barry or Pete Resnick (whose ponytail is an honorary
beard) will chime in.

R's,
John

---

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

I'm grey.

For the record, Murray made an erroneous statement about I didn't say 
and just basically paraphrase what I did say.

SPF is a MTA to MDA protocol. This is backed up by 4408 and also 5598 
but then again, it depends how its read.

Overall, the BACKEND must deal with the ACCEPT+MARK issue in order to 
be security on-par with its alternative mode - rejection.  I said that 
in April 2012, after losing a tooth, it was made part of issue #29 
with the wrong mail reference, ignored and supposedly closed, but 
resurfaced as Issue #33 this time from a security angle and that was 
still a problem because it "tells receivers" what to do, and it was 
also out of scope.  No one likes Security Issues for RFC proposed 
standards works I guess.

Now we debating what is the meaning of Local Policy, and RFC Technical 
Writing Styles arguing whether what is written wasn't really was 
intended!

Good Luck with all this.

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 Sep 2012 15:55:29 -0400

> applicability statements.  Correct?

Well, I don't think that's quite it.  If there are choices to be made that
affect interoperability of the protocol, use the 2119 language to specify
the choices, whether that's in the TS or an AS.  So, if the protocol
requires it, you might say that some entity MUST retrieve the domain's MX
record from DNS, snf SHOULD fall back to the A record if no MX exists.
 This would all specify how to operate the protocol.

But when you're not talking about an interop-related choice, it's probably
not 2119 territory (though I'm oversimplifying here).  Language that talks
about what to do with the results of the protocol... is, I think, not the
place for 2119 key words.

> kept reasonable.  Otherwise, making a separate AS document seems
> to me to be a much more palatable approach, and as a result that
> specific set of material and the core documentation each have more
> breathing room.

That's for the WG to decide.  There's value in keeping a TS clean, and
there's value in including AS information in the TS document.  Judgment.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Sep 2012 16:38:56 -0400

> paragraph "Applicability Statement:", or put it in a section so

Thank you.  I think that clarifies it for me.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Sep 2012 22:51:01 -0400

> an operator decision or is it up to the implementation?

We've spent a lot of time arguing over how not to give direction on local 
policy for SPF fail in RFC 4408bis when neither 4408 nor 4408bis do so (which 
seems like an odd place to expend resources to me).  The only definitive piece 
of receiver policy MUSTard in 4408/4408bis is for neutral.  It says: 

   A "Neutral" result MUST be treated exactly like the "None" result; the
   distinction exists only for informational purposes.  Treating
   "Neutral" more harshly than "None" would discourage domain owners
   from testing the use of SPF records (see Section 9.1).

If you want to argue about receiver policy, let's start there.  I think that 
should definitely stay because the MUST is part of the semantics of the 
result.

Additionally, if we're going to say it's a matter of local policy, we have to, 
to some extent, say what that means.  I don't think it makes any difference if 
we say see section 9 for a description of what that means or see 4408bis' for 
a descriptions ...  We have to cover the information either way.  If we end 
our definition of the protocol with an undefined term, that's just a bug.

To answer your specific question (implementation or operator), my answer would 
be "yes".  An operator is limited to the options an implementation supports.  
Since it's a matter of local policy, the operator should be the one making the 
determination and a good mail system that integrates SPF would make a range of 
choices available so that the system can be configured to correctly implement 
the policy.  I don't think any of that goes in 4408bis or the possible 
4408bis'.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 Sep 2012 12:05:44 -0700

> the policy.  I don't think any of that goes in 4408bis or the possible

I agree, what lands in the hands of the operator is a function of the
implementation, and what the implementation (assuming it's compliant)
can make available is a function of what the protocol's outputs are.
But both of those are at a level above what a protocol definition is
supposed to say.

SPF itself can't say "reject", it can only say "fail".  It's up to the
implementation to do something with that, whether it's rejection,
"marking", logging, or something else altogether.  We can and should
also provide text that informs consumers (both implementers and
operators) of the reasons each result can occur, so that reasonable
implementation and operation (policy) decisions can be made for each
result.

Where it extends to an applicability statement would be defining a
capability the protocol enables.  Such an AS might say "Here's how to
reject mail based on SPF if you're not worried about the false
negatives."  I think that's perfectly reasonable for us to do.

I suppose the real issue is how much of that sort of thing do we need
or want to say here, and also make it clear that such advice is not
part of the protocol proper.  To use an example, DKIM did it a little
bit by saying a bad signature ought not be ascribed any particular
value.  With SPF we seem to want to be a lot more verbose and
aggressive about interpretation, and that's what's leading us in this
direction now.

As for all the discussion about MARID and pre-MARID, we shouldn't hold
those up as if they're a constitution for this work.  It's entirely
possible those people, despite good intentions, got some things
plainly wrong.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Sep 2012 13:40:57 -0700

Folks,

On 9/13/2012 12:05 PM, Murray S. Kucherawy wrote:
>> determination
...
> can make available is a function of what the protocol's outputs are.

A thread that goes on this long often indicates either a lack of shared
framework among participants, or a difference of opinion about a key
point. I'm pretty sure the former is at work here. If we can all get on
the same 'framework' page, we might yet find differences in opinion.
(Gosh, that would be so unusual.)

Various postings have, I think, tried to formulate a framework to share,
but it does not seem to have completely succeeded.

I'm a fan of diagrams, in such cases. I'm also a fan of having explicit
statements about formal 'output'.

Starting with Figure 1 of the DKIM Deployment document:

http://www.dkim.org/specs/draft-ietf-dkim-deployment-11.html#trustseq

I suggest a variant for SPF:

(you need a fixed-width font for this, of course...)

    +------+------+                            +------+------+
    |   Author    |                            |  Recipient  |
    +------+------+                            +------+------+
           |                                          ^
           V                                          |
    +-------------+                            +------+------+
    | Responsible |...                      -->|  Handling   |<--
    |  Identity   |  .                      -->|   Filter    |<--
    +------+------+  .                         +-------------+
           |         .                                ^
           |         .                                |
           |         .                         +------+------+
           |         .  ++=====================|  Identity   |==++
           |         +........................>|  Assessor   |  ||
           |            || Authorization       +-------------+  ||
           |            || Identifier                ^ ^        ||
           V            ||                           | |        ||
++=====================++                   ++======| |========++
|| +------+------+         +-------------+  ||      | |  +-----------+
|| |   Sending   |         | Identifier  +--||------+ +--+ Assessment|
|| |    Host     +-------->| Validator   |  ||           | Databases |
|| +-------------+         +-------------+  ||           +-----------+
||               SPF Service                ||
++==========================================++

The major variation is to include a portion of the Identity Assessor
function to be /within/ SPF. This reflects the larger scope of SPF,
compared with DKIM, in that it validates sending host authorization.

Using the -07 version as reference:

1. SPF's output is defined in terms of the check_host() pseudo-function,
as described in Section 4. Its possible output values are defined in
Section 2.5. { aside: in documentation terms it would be nice to have
results described after basic definition of the function... the simple
form of this request is: references be in the document 'direction' that
matches the functional relationship. In this case, output comes 'after'
the function. }

2. Anything that happens after the output function and is normative
needs to be essential for "interoperability". Otherwise, it is
/strictly/ a matter of local preference.

3. A spec must not dictate local behaviors that are not essential for
interoperability. On the other hand, it can often be helpful to have a
discussion of possible or common choices and their implications.
Sometimes this can be inside a specification document -- albeit highly
separated from normative text -- and other times it needs to be in a
separate document. The choice is sometimes a matter of taste and
sometime a matter of what will make the spec more understandable to a
typical reader.

I'm going to claim that a receiving host's actions, after obtaining
check_host() output, are always and only a matter of local preference.
SPF cannot dictate any of that behavior. It can explain sender
preferences (or "requests"). It can discuss implications. But it
cannot dictate.

Simply put, once we are outside of the realm of basic interoperability,
we cannot have one ADMD dictating the behaviors of an independent ADMD.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Sep 2012 17:33:32 -0400

On Thursday, September 13, 2012 01:40:57 PM Dave Crocker wrote:
...
> preferences (or "requests"). It can discuss implications. But it
...
To focus in on this bit, as I think it's the core ....

I believe this is generally, but not universally true.  Specifically, as I 
mentioned up thread, I think the MUST treat the same as "none" language for 
"neutral" in RFC 4408 is part of the core semantics of what the "neutral" SPF 
result means.  I don't think it's severable. 

If that can't stand, it'd be more technically correct to eliminate the 
"neutral" result and map "?" to none, but (of course) we can't do that.

Yes, I know that nothing we write in 4408bis stops someone from doing the 
exact opposite of what it says, but that doesn't make it wrong to say it.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Sep 2012 14:56:51 -0700

> "neutral" result and map "?" to none, but (of course) we can't do that.

Well, it's certainly important to ask why it is important to have two 
different output values, if their semantics are the same.

My impression is that it is considered useful to keep the separate 
values.  Hence I think our job is to define the semantics in two parts. 
  Perhaps one is authorization semantics; with the other being logging 
"semantics", if that distinction works for folk.

> exact opposite of what it says, but that doesn't make it wrong to say it.

Classic point:  operators are always free to do whatever they want.  The 
issue with a spec is defining "the 4 walls of an environment" and then 
it owns the semantics within those walls.  Hence, an operator that does 
something else is outside the scope of the spec, rather than 'violating' it.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Sep 2012 18:09:55 -0400

On Thursday, September 13, 2012 02:56:51 PM Dave Crocker wrote:
> > "neutral" in RFC 4408 is part of the core semantics of what the "neutral"
> > SPF result means.  I don't think it's severable.
> > 

There are a number of places where SPF semantics are more verbose than they 
might be.  If I were designing SPF from scratch, I'd probably combine the "a", 
"ip4", and "ip6" mechanisms into one.  If we were the SPF3 WG and not SPFbis 
I'd probably suggest combining them and I'd think disposing of "neutral" in 
favor of "none" was worth discussing.

> "semantics", if that distinction works for folk.

It is a useful distinction for forensics, but not normal operations, so your 
suggestion makes conceptual sense.  My suspicion is trying to describe it that 
way will be more confusing than what we have now, but I'm certainly glad to 
explore to concept if you have ideas about how to characterize it.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Sep 2012 15:36:19 -0700

> favor of "none" was worth discussing.

Let's see whether I have a particular bit of understanding correct:

    I think that the items you cite are part of the /internal/ SPF 
evaluation mechanism, rather than part of its semantic /output/.  (For 
the moment, I'm ignoring the details of what might be listed in logging 
output.)

> explore to concept if you have ideas about how to characterize it.

What we have now is a tendency to confuse internal processing versus 
formal output.  That strikes me as inherently worse than merely needing 
to refine the definition of the latter...

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Sep 2012 23:13:30 -0400

On Thursday, September 13, 2012 03:36:19 PM Dave Crocker wrote:
> > might be.  If I were designing SPF from scratch, I'd probably combine the
> > "a", "ip4", and "ip6" mechanisms into one.  If we were the SPF3 WG and
> > not SPFbis I'd probably suggest combining them and I'd think disposing of
> > "neutral" in favor of "none" was worth discussing.
> 

Yes, but it's an example of more semantic variation than is strictly needed.

> > It is a useful distinction for forensics, but not normal operations, so
> > your suggestion makes conceptual sense.  My suspicion is trying to
> > describe it that way will be more confusing than what we have now, but
> > I'm certainly glad to explore to concept if you have ideas about how to
> > characterize it.

I think part of what we have is a disagreement about how to draw the boundary 
around the edge of SPF.  To say it's confusion implies one perspective is 
right and the other is wrong.  I think it's more productive to characterize it 
as a disagreement.

If I were to draw the line at a point that says that the SPF result is the end 
of the SPF protocol, then I would argue that the distinction between neutral 
and none is a piece of internal SPF structure that happens to leak into the 
outside world.

To translate this into software terms, sometimes bits of private API leak into 
public view and it's appropriate to document that it's not appropriate to rely 
on that private API.  Ideally we'd fix the bug, but there's no way to do it 
without breaking the ABI so we're stuck with the bug until we can do an ABI 
break.  Programmers exploit private API that is incidentally visible, but when 
that breaks their software later, they get no sympathy from the library 
author.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Sep 2012 21:39:52 -0700

> Yes, but it's an example of more semantic variation than is strictly needed.

Maybe.  Maybe not.

It's clearly necessary to have a core of semantic output that is the 
'reason' for having SPF.  This is the check_host() result.

It is often helpful to facilitate debugging and forensics, especially in 
distributed systems which often are notoriously difficult to diagnose. 
So adding formal "semantics" to help this goal, but that are distinct 
for the core semantics is also reasonable.

Hence I don't see this as semantic 'variation' as two streams of 
semantics.  One for functional benefit.  The other for operational benefit.

> right and the other is wrong.  I think it's more productive to characterize it

A constructive debate can move the boundaries around.  I might prefer 
them in one configuration; you another.  Both of us might have good 
reasons.  The debate produces consensus on a single, common 
configuration for the boundaries.  Saying 'right' or 'wrong' in such a 
debate is typically counter-productive.

A different issue is our not sharing the same model, so that my comments 
don't even have the same meaning as yours.  At that point, it's not that 
your comments or mine are wrong, but that our failure to share the same 
model is what's wrong.

Anyhow, I put forward a drawing that shows some lines and broadly 
explained why.  If folk want to claim the diagram should look different, 
have at it and let's discuss it.

> and none is a piece of internal SPF structure that happens to leak into the

Well, I thought I was (merely) characterizing existing practice, 
especially since that's what the wg is supposed to do, except for fixing 
problems.  This might qualify as involving a problem, but I haven't seen 
claims about that.

Anyhow, as I say, if someone wants to propose a different diagram, let's 
see it and talk about it.

> that breaks their software later, they get no sympathy from the library

As an abstract comment, sure.  In terms of the current topic, I'm not 
sure what to do with what you've said.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Sep 2012 00:48:28 -0400

On Thursday, September 13, 2012 09:39:52 PM Dave Crocker wrote:
> > I think part of what we have is a disagreement about how to draw the
> > boundary around the edge of SPF.  To say it's confusion implies one
> > perspective is right and the other is wrong.  I think it's more
> > productive to characterize it as a disagreement.
> 
> > If I were to draw the line at a point that says that the SPF result is the
> > end of the SPF protocol, then I would argue that the distinction between
> > neutral and none is a piece of internal SPF structure that happens to
> > leak into the outside world.
> 
> > To translate this into software terms, sometimes bits of private API leak
> > into public view and it's appropriate to document that it's not
> > appropriate to rely on that private API.  Ideally we'd fix the bug, but
> > there's no way to do it without breaking the ABI so we're stuck with the
> > bug until we can do an ABI break.  Programmers exploit private API that
> > is incidentally visible, but when that breaks their software later, they
> > get no sympathy from the library author.
> 

The analogy I'm trying to draw here is that the neutral/none is conceptually 
similar to a piece of internal API that happens to be visible.  External 
entities ought not be using it and it is entirely appropriate to document that 
in strong terms.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 Sep 2012 23:29:30 -0700

> entities ought not be using it and it is entirely appropriate to document that

I think that's a fine thing to do, but what the document does now is
say that they MUST produce the same outcome without explaining why.  A
sentence or two that lays out what you're saying here would be a good
thing to add.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Sep 2012 13:13:05 +0200

> (you need a fixed-width font for this, of course...)

I'm having some difficulties with that diagram, probably because ASCII
art isn't so readable as it would be desired.  I view SPF as follows,
more or less:

    +------------+  +------------+           +------------+
    |  Author or |  |   Sending  |       <-->|  Handling  |<--
    |  Forwarder |  |    Host    |       <-->| Filter, Etc|<--+
    +-----+------+  +-----+------+           +------------+   |
          |               |                     ^             |
          V               V                     |             |
    +-----------+    +-----------+   ++=========|=============|=====++
    | MAIL FROM |    |   HELO    |   ||         |             |     ||
    | Identity  |    | Identity  |   ||   +-----+--------+    |     ||
    +-----------+    +-----------+   ||   | Local Policy |    |     ||
          |               |          ||   +--------------+    |     ||
          |               |          ||         ^        ^    |     ||
++ =======|===============|==========++         |        |    |     ||
||        |               |                     |        |    |     ||
||        V               V                     |        |    |     ||
||  +----------------------------+        +-----+-----+  |    |     ||
||  |      SPF  protocol         |        |    SPF    |  |    |     ||
||  |(the spec in a strict sense)|------->|  Results  |  |    |     ||
||  +----------------------------+        +-----------+  |    |     ||
||               ^                                       |    |     ||
||               |                                       |    |     ||
||  +----------------------------+      +----------------+----+-+   ||
||  |           DNS              |      | Assessment Databases  |   ||
||  +----------------------------+      +----------------- -----+   ||
||                                                                  ||
||  SPF in some broader sense                                       ||
++==================================================================++

I'm not a good ASCII artist, but the above has the advantage to locate
the local policy, thus adhering to this thread's subject.  The box
labeled "SPF protocol" would seem to be the check_host() function in a
classical De Marco DFD, while the MAIL FROM/ HELO labels, which are
semantically part of the SPF protocol, should be on the edges...

> we cannot have one ADMD dictating the behaviors of an independent ADMD.

How is "dictate" related to 2119-language?  An AS that goes into the
meaning of the results has to specify what behaviors an ADMD can
request.  To do that, it may say that "a receiver MUST/SHOULD do so
and so" in order to comply with a given request.

The point of separating AS from TS is that a receiver may want to
comply with SPF as far as getting the correct result is concerned, but
not with the request part.  Within a single document, it is impossible
to say to which part each 2119 term would be related.

I'm not a connoisseur of the historical SPF versions, but all the ones
I saw conflate those two parts, and blur the second one.  For example,
RFC 4408 does not specify how to build and maintain a local assessment
database, which is a popular requisite for implementing sensible
fail-related behaviors.

My perception is that there has never been agreement on the details of
local policies.  Indeed, the adjective "local" suggests that such
policies are the receivers', not the senders' ones --they don't match
the P of SPF.  Yet, the feeling that receivers must do something
strong on "fail" has made it into RFC 4408.  IMHO, that's an ambiguous
standardization technique that we ought to overcome.

We can even standardize a set of multiple behaviors that a receiver
may choose from, e.g. mark on fail, reject on fail, classical or
enhanced.  Or none at all.  We just need to know what we wanna do.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Sep 2012 08:24:41 -0400

On Thursday, September 13, 2012 01:40:57 PM Dave Crocker wrote:
> || 
> || 
> ||

I'm not an ASCII artist, so I won't try (I'd also suggest that while ASCII art 
has it's place in RFCs for good reasons, it's generally more efficient to use 
more modern tools for diagrams to support more ephemeral discussions like this 
one).

>From what I understand of the diagram, it represents one mode of operations, 
but not the only one.  Alternately (and I'm sufficiently convinced I don't 
follow your terminology that I won't try and associate this with precise 
elements of your chart), there is a receiving MTA, with a policy component 
that gives an SPF library a set of inputs, gets an SPF result back, and then 
makes a policy decision whether or not to reject the mail based on the result.  
If the mail is rejected, that's the end of the story.  As a real world 
reference, that's pretty precisely how the Postfix policy service works with 
SPF (and other MTAs have similar approaches).

I understand the argument that SPF processing is an input of an email 
address/host name and an IP address and an output of an SPF result and 
everything else is cruft.  I am not confused.

I disagree with that view and so does the document that we've been tasked to 
update.  That doesn't mean we can't change it, but I think it needs more 
rationale than not liking it that way.

SPF does not operate in a vacuum and it's use famously has potential 
implications for the overall email architecture.  A document that limited 
itself to this narrow scope would be virtually useless to implementers and 
operators trying to deploy SPF (note: I'm not arguing here that we need a more 
directive treatment of local policy than was present in RFC 4408 - I don't 
think we do).

When RFC 4408 was being written there were several determined efforts to make 
it shorter.  The topics that are covered are there because it was felt that 
they were important.  Now that we know more, based on more experience, we had 
additional information that seems important.  This is not surprising either.  

While things can be worded better, I think that generally what's in RFC 4408 
is what's needed in RFC 4408bis.  Trying too hard to draw a dark solid line 
about what is/is not SPF and removing/minimizing the things that are not SPF 
is not gong to result in a better product.

I think we should not worry a lot about the page count.  Splitting the 
document in two to reduce the page count doesn't help anything and is, I 
think, actively harmful to the ultimate customers of this document (not the 
IESG, the implementers).  In a single document, I can be very fine grained 
about references and pointers so that (particularly in HTML versions of the 
document) it is easy to follow non-linear narrative when needed.  I don't 
think I can do that into the body of a different document (if I can, someone 
please help me with the XML and that resolves some of my concerns about 
splitting).

IMO, the group has wandered off into a bunch of minimally productive navel 
gazing instead of doing the work we were chartered to do.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Sep 2012 09:18:45 -0400

No hat.

On Fri, Sep 14, 2012 at 01:13:05PM +0200, Alessandro Vesely wrote:
 
> the local policy, thus adhering to this thread's subject.

But your diagram has the local policy located _inside_ the "SPF in
some broader sense" box.  It seems to me there are two possibilities
here:

    1.  You want the WG to focus on the narrow sense of SPF, in which
    case we need an "SPF proper" box on the diagram so we know what
    we're working on.

    2.  You want the local policy to be part of the SPF protocol.

(2) is not on.  The IETF cannot possibly specify local policy _by
definition_.  That's what it means for there to be local policy.  We
can say what the boundaries of conformant local policy are, but we
can't say what it's going to be.

> the P of SPF.

Exactly.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Sep 2012 17:04:03 +0200

On Fri 14/Sep/2012 15:18:45 +0200 Andrew Sullivan wrote: No hat.
>     2.  You want the local policy to be part of the SPF protocol.

Both, actually.  The "SPF proper" is check_host() plus the implied
minimal additions, i.e. what the identities are, how to publish
records to obtain a given result, and what time and site are
recommended for computing results.  4408bis should be polished down to
that.

The second part could be an ambiguous AS that reflects RFC 4408's
hints in a proper language.  If we recharter, it can be something that
can be used as specified, with a negligible amount of false negatives.
 Otherwise, it can be written later, by some other WG.

> can't say what it's going to be.

I don't fully understand that.  Do you mean there is a (IETF-wide)
definition of local policy?  By "local policy" we mean all the stuff
that, although important, is blurred behind that term.  What if it
were called "requested receiver behavior" instead?

>> Indeed, the adjective "local" suggests that such policies are the
>> receivers', not the senders' ones --they don't match the P of SPF.
> 
> Exactly.

And the term "policy" seems to have been chosen in order to match RFC
5321's policy reasons.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Sep 2012 08:51:55 -0700

On 9/14/2012 4:13 AM, Alessandro Vesely wrote:
>>      I view SPF as follows,
...
> ||  SPF in some broader sense                                       ||

I think that "in some broader sense" nicely characterizes the difference 
in our views.

Unfortunately, what I think you mean by it is "more than" SPF.

I think that what you mean is the entire set of authentication, 
authorization and assessment mechanisms that produce input to the 
handling filter.

The handling filter is where message disposition is decided; that, of 
course, is the ultimate local policy.  However inside your box would be 
where assessment values, such as "this is a spammer" or "this is a 
trusted sender" get determined.

As such, there's still quite a bit of local policy included inside your 
box.  That's a point for debate.  However I think the core point is 
understanding the difference between "SPF" and "SPF and a lot more", 
which means the latter shouldn't have the label "SPF" in it.  It should 
have a broader label.

Then there would be the question of having such a diagram in an 
SPF-specific document.  The diagram I offered is meant to be 
SPF-specific.  I think there's some benefit in having it echo a 
DKIM-related diagram, but of course it has to be tailored for 
differences in SPF architecture at the network level.

> I'm not a good ASCII artist,

Actually, the diagram you produced looks like perfectly good ascii art 
to me.

> but the above has the advantage to locate

You seem to be confusing a host-side, local state diagram with a 
distributed protocol exchange.  check_host() is a component function in 
a distributed system that is the SPF protocol.

However if you want to do some form of state diagram/graph model 
representation of SPF as a protocol, that might be interesting to 
discuss.  However I doubt that it would be, since SPF is a 
uni-directional protocol.  There's no interaction sequence.

> How is "dictate" related to 2119-language?

It pertains to the activity /within/ the protocol that is needed for 
successful operation of the protocol itself.  So, normative language 
only makes sense "within the 4 walls" of the world defined by the protocol.

Once we move outside those walls -- creating input to feed into the 
protocol or taking ouotput from it -- we cannot apply normative 
language, because the actions are not required for interoperability.

To be clear: there certainly is a world that /could/ be defined that 
would have a sender dictating receiver actions.  That is, it's 
theoretically possible and might be reasonable. But it requires a world 
in which we can get receivers to agree to being told how to dispose of 
messages by senders.  A military internet might be an example where this 
would be possible.

But that's not the open Internet and we don't have receivers eager to 
get disposition directives from senders.

   An AS that goes into the
> to say to which part each 2119 term would be related.

Having a /separate/ document that specifies message disposition based on 
SPF results might be quite reasonable.  It would depend on the details 
of the document.

> I saw conflate those two parts, and blur the second one.

That matches my perception, also.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Sep 2012 19:40:02 +0200

On Fri 14/Sep/2012 17:51:55 +0200 Dave Crocker wrote:
> I think that "in some broader sense" nicely characterizes the
> difference in our views.
> 

Yes.

> authorization and assessment mechanisms that produce input to the

Some of it.

> course, is the ultimate local policy.  However inside your box would
> be where assessment values, such as "this is a spammer" or "this is a

I'd be happy with "this comes from where it says it's coming".  No
connotation of spam or trust, just DNS, but taking non-rewriting
forwarders into account.  A well defined problem, consistent with the
original SPF catch of requiring a registered domain to send mail.

The handling filter may make further considerations and assessments.

> As such, there's still quite a bit of local policy included inside
> your box.  That's a point for debate.  However I think the core point
> is understanding the difference between "SPF" and "SPF and a lot
> more", which means the latter shouldn't have the label "SPF" in it. 
> It should have a broader label.

It might include DNSxL, but not DKIM.  That way, it would be worth
against bursts of unauthorized mail.  Such attacks are possible,
albeit IME unusual.  To accept and verify the DATA may require so much
resources as to turn them into DoS attacks.

> Actually, the diagram you produced looks like perfectly good ascii art

Thanks.  However, as you say, it confuses a host-side, local state
diagram with a distributed protocol exchange.  BTW, are there formal
rules for the latter ones?

> theoretically possible and might be reasonable. But it requires a
> world in which we can get receivers to agree to being told how to
> dispose of messages by senders.  A military internet might be an
> example where this would be possible.
> 

I'm happy the Internet is open the way it is.  The point is not who
dictates what to whom, but what are the most effective ways that
legitimate MTAs can cooperate.

> Having a /separate/ document that specifies message disposition based
> on SPF results might be quite reasonable.

Yes.

> It would depend on the details of the document.

Yes, and they in turn depend on how well /we/ can cooperate.  Another
possibility is to write a dummy document, possibly still experimental,
that just repeats RFC 4408's hints, for the mere purpose of not
changing the overall specification, to be obsoleted as soon as possible.