Subject: Re: [spfbis] What is a sender policy?

From: S Moonesamy <[email-masked]>
Date: Tue, 18 Sep 2012 11:52:48 -0700

Hello,
At 20:55 27-08-2012, Scott Kitterman wrote:
>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.

John Leslie mentioned that '"sender policy" should reflect what the 
sender _does_ - not what the sender hopes some other MTA will do'.

If there is agreement on the above arguments, the WG could look at 
this in from an angle where issues are identified.  For example, 
Alessandro Vesely commented on receiver behavior in a message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02864.html

If the WG agree that an issue is indeed a problem that has to be 
fixed, the next step is to find the fix.  For example, Arthur Thisell 
proposed the following text:

   'A "softfail" result says that the ADMD would like the result treated
    somewhere between "fail" and "neutral"/"none".  The domain owner
    believes the host is not authorized but is not willing to make a
    strong policy statement.  SPF verifies that treat "softfail" results
    as harshly as a "fail" can cause ADMDs not to publish such a strict
    SPF policy, or not to publish an SPF record at all.'

Is this an acceptable approach to tackle Section 2 of 
draft-ietf-spfbis-4408bis?

Regards,
S. Moonesamy

---

From: Commerco WebMaster <[email-masked]>
Date: Tue, 18 Sep 2012 13:38:57 -0600

SM,

On 9/18/2012 12:52 PM, S Moonesamy wrote:
>> Upon reflection, I could have put this more clearly. The sender policy
>> is the

That seems reasonable, however, because SPF has a number of possible 
options available to publishers, it seems rather important to explain 
what the consequence of one option is over another within the 
specification for SPFbis.

The publishing of an SPF record simply indicates what a DOMAIN owner 
claims are one or more authorized machines that can send email out on 
behalf of the DOMAIN.  Perhaps I am stumbling over a case of semantics 
(because SPF is "Sender Policy Framework" rather than "Domain Policy 
Framework"), but when I read "sender" in John Leslie's quote, I started 
thinking the sending MTA.  I am pretty sure the spirit of John Leslie's 
words are right on target, but we might want to clarify wording to avoid 
confusion with an actual sending MTA in the discussions.  Of course, a 
sending MTA does not even need to be SPF aware.

Also, if the expectation is that some syntax be published in order to 
make a declarative statement about what a publisher contends is true of 
their domain (e.g., "v=spf1 -all" = The domain for which this txt record 
is published should not be sending email), then it seems like it would 
be minimally helpful for a publisher to understand and have an 
expectation for what the rough result of their publishing choices might 
be from the receiver's perspective in order to correctly choose an SPF 
syntax to implement.

Some expectation of what a receiver might do with the publisher's syntax 
is ultimately not telling the receiver what to do, but rather help the 
publisher understand what they should be putting in those DNS TXT 
records in order to achieve their desired result from publishing SPF TXT 
records in the first place.

>
> If there is agreement on the above arguments, the WG could look at this
> in from an angle where issues are identified. For example, Alessandro
> Vesely commented on receiver behavior in a message at
> If the WG agree that an issue is indeed a problem that has to be fixed,
> the next step is to find the fix. For example, Arthur Thisell proposed
> the following text:
>
> _______________________________________________

Best,

Alan M.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 18 Sep 2012 14:40:04 -0700

Hi Alan,
At 12:38 18-09-2012, Commerco WebMaster wrote:
>options available to publishers, it seems rather important to 
>explain what the consequence of one option is over another within 
>the specification for SPFbis.

Let's talk about that when we get there.  In other words it is easier 
to solve one problem at a time.

>claims are one or more authorized machines that can send email out 
>on behalf of the DOMAIN.  Perhaps I am stumbling over a case of 
>semantics (because SPF is "Sender Policy Framework" rather than 
>"Domain Policy Framework"), but when I read "sender" in John 
>Leslie's quote, I started thinking the sending MTA.  I am pretty 
>sure the spirit of John Leslie's words are right on target, but we 
>might want to clarify wording to avoid confusion with an actual 
>sending MTA in the discussions.  Of course, a sending MTA does not 
>even need to be SPF aware.

May I suggest that we focus on Section 2 first?  I picked that 
section as Arthur Thisell proposed some text.  If it seems to follow 
the spirit of John Leslie's words, it is an alternative worth considering.

>Also, if the expectation is that some syntax be published in order 
>to make a declarative statement about what a publisher contends is 
>true of their domain (e.g., "v=spf1 -all" = The domain for which 
>this txt record is published should not be sending email), then it 
>seems like it would be minimally helpful for a publisher to 
>understand and have an expectation for what the rough result of 
>their publishing choices might be from the receiver's perspective in 
>order to correctly choose an SPF syntax to implement.

The above sounds helpful to me.  Let's see how to make productive use of it.

>Some expectation of what a receiver might do with the publisher's 
>syntax is ultimately not telling the receiver what to do, but rather 
>help the publisher understand what they should be putting in those 
>DNS TXT records in order to achieve their desired result from 
>publishing SPF TXT records in the first place.

How important is it for me to believe the above? :-)

It's going to be difficult to sell that line to the IETF community.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Sep 2012 18:33:12 -0400

>draft-ietf-spfbis-4408bis?

RFC 4408 has normative requirements for some aspects of receiver policy for neutral and softfail results.  I believe that removing these requirements would represent a change to the protocol.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 18 Sep 2012 23:25:29 -0000

> RFC 4408 has normative requirements for some aspects of receiver
> policy for neutral and softfail results.  I believe that removing
> these requirements would represent a change to the protocol.

If you mean the part that says that neutral and softfail mean the same
thing, that seems fine.  To split hairs a little, that is telling
readers what the sender's policy is, not what receivers should do with
the result.

It seems analogous to the part of RFC 5321 that says that for most
SMTP reply codes, only the code matters, not the text after it.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Sep 2012 22:59:22 -0400

> SMTP reply codes, only the code matters, not the text after it.

Close.  There's two items:

1.  Neutral and None mean the same thing so you MUST treat the the same.

2.  Receivers SHOULD NOT reject based on an SPF softfail result alone.

The second one is appropriate because softfail is supposed to be used for 
testing and rejecting based on a test failure alone will interfere with 
interoperability and deployment.

Scott K