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

From: Arthur Thisell <[email-masked]>
Date: Thu, 13 Sep 2012 18:13:40 -0700 (PDT)

>   A "Neutral" result MUST be treated exactly like the "None" result;

Your daily history lesson:  the SPF spec started as more of documentation for Meng Weng Wong's perl script, than vice versa.  Sometimes running code is great, other times, not so much.

The distinction between neutral and none is important for the best-guess system.  If an evaluation of check_host(ip,domain,sender) returned neutral, then that was the result.  If the result was none, then you called best guess.  So, the spec has always been a lie, neutral wasn't treated exactly like none, the distinction was only not for informational purposes.  And, no, I don't think the RFC should even mention best-guess.

If I was writing SPF v3, I would just return a neutral result, and leave the rest up to diagnostic tools.  Diagnostic tools can do a much better job of realizing that you didn't put the SPF record in the right place, or that "v=spf1a mx -all" isn't a valid record.

Now, after some pondering, I do think we can get rid of the MUST, and say:

     ADMDs expect "neutral" to be treated exactly like "none", the 
     distinction exists only for aiding in diagnosing SPF problems.

While it is true that people can be pushed away from SPF if neutral is treated more harshly than none, I think SPF deployment is beyond the point where this is really critical.  With ~70% deployment, people must be seeing a reasonable benefit to deploying SPF records, despite people treating neutral worse. And, any receiver that treats neutral much worse than none is almost certainly hurting themselves.

*shrug*

OK, there is a second local policy item that I know of.  In the definition of softfail, it says

   A "softfail" result ought to be treated as 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.
   Receiving software SHOULD NOT reject the message based solely on this
   result, but MAY subject the message to closer scrutiny than normal.

Again, I think this is best rephrased as what the ADMD expects, e.g.:

   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.

*shrug*

I don't see this as that important of an issue, nothing is going to change what people actually do anyway.

---

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

On Thursday, September 13, 2012 06:13:40 PM Arthur Thisell wrote:
> Your daily history lesson:  the SPF spec started as more of documentation
> for Meng Weng Wong's perl script, than vice versa.  Sometimes running code
> is great, other times, not so much.
> 
> The distinction between neutral and none is important for the best-guess
> system.  If an evaluation of check_host(ip,domain,sender) returned neutral,
> then that was the result.  If the result was none, then you called best
> guess.  So, the spec has always been a lie, neutral wasn't treated exactly
> like none, the distinction was only not for informational purposes.  And,
> no, I don't think the RFC should even mention best-guess.

The spec wasn't a lie.  Meng just had a poor Perl script.  Even pyspf, which 
started life as a very faithful reimplementation of Mail::SPF::Query in Python 
has a best guess function hidden in it, but you have to try really hard to get 
it to do anything.  Best guess may have been a reasonable bootstrap mechanism 
for the protocol, but I agree, it's time is long past.

> If I was writing SPF v3, I would just return a neutral result, and leave the
> rest up to diagnostic tools.  Diagnostic tools can do a much better job of
> realizing that you didn't put the SPF record in the right place, or that
> "v=spf1a mx -all" isn't a valid record.
> 
> While it is true that people can be pushed away from SPF if neutral is
> treated more harshly than none, I think SPF deployment is beyond the point
> where this is really critical.  With ~70% deployment, people must be seeing
> a reasonable benefit to deploying SPF records, despite people treating
> neutral worse. And, any receiver that treats neutral much worse than none
> is almost certainly hurting themselves.
> 
> *shrug*

Shortly after RFC 4408 was published, I saw a lot of evidence of people 
treating neutral different than none.  It seems, AFAICT, to have largely died 
out.  What I do see people doing is treating the combination of mail from 
aol.com and neutral more negatively than they treat SPF none or SPF none from 
an unknown domain.  To me that's part of a higher level process and exactly 
the kind of thing 4408bis has no business getting involved in.

I agree it could be reworded without great harm, but I don't see why it should 
be changed.  Every time we change something in 4408bis from what's in RFC 4408 
we have created an opportunity for an implementer that's reviewing the new RFC 
to update their implementation to be confused.

In general, I think the changes we've made have been improvements that added 
enough benefit to be worth that cost, but I don't think this qualifies at all.

> what people actually do anyway.

Softfail is somewhat like DKIM testing, IMO.  Here's what RFC 6376 has to say 
about that:

      y  This domain is testing DKIM.  Verifiers MUST NOT treat messages
         from Signers in testing mode differently from unsigned email,
         even should the signature fail to verify.  Verifiers MAY wish
         to track testing mode results to assist the Signer.

Hey, it turns out that the great DKIM design that was so wonderfully done has 
just about as much local policy in it as RFC 4408 does.

I wish we'd quit rewriting stuff to rewrite it and focus on actual issues that 
need to be resolved.

Scott K

---

From: "Wayne Doust" <[email-masked]>
Date: Fri, 14 Sep 2012 16:43:30 +1000

> Softfail is somewhat like DKIM testing, IMO.  Here's what RFC 6376 has
to say about that:

I would say Neutral is somewhat like DKIM testing.

Softfail is for those who either:

 1. cannot guarantee mail will not forwarded by a non-SRS destination 
 2. haven't implemented DKIM or DMARC
 3. aren't sure if mail is being sent on their behalf from elsewhere
(rogue marketing dept for example)

Fail is for those who can positively guarantee that IFF a Fail occurs
THEN it did not come from us.

The standard (but not manadatory) local policy is then:

If FAIL: either reject with a 550 or mark and block
If SoftFail: treat as greylist OR mark and accept OR both

Since local policy is not specified, these are recommended with
non-normative language.

Regards,

Wayne

(BTW This is the last day of my contract at this place, so I will be
using my gmail address in future)

---

From: "John Levine" <[email-masked]>
Date: 14 Sep 2012 15:14:13 -0000

We're going in circles here.  I'm getting the impression that there's
a fundamental lack of understanding about how much control senders
have over their mail once it leaves their MTA.

>THEN it did not come from us.

But nobody can make such a guarantee, since there is no way to ensure
that your mail won't be delivered via a path that SPF can't describe.

As a matter of plain fact, people can and will deliver your real mail
to the right recipient via paths you don't authorize, and there's
nothing you can do about it.

>If SoftFail: treat as greylist OR mark and accept OR both

Neither of these are "standard" in the sense of being widely
implemented by mail systems that many people use.  I don't see
anything as being "standard", which I why I don't see any value
in offering advice about local policy.

R's,
John

---

From: John Leslie <[email-masked]>
Date: Fri, 14 Sep 2012 11:58:51 -0400

John Levine <[email-masked]> wrote:
> Cc: [email-masked]
> 

   This is true; but a sender policy "forbidding" forwarding _is_
possible, and could be argued to be reasonable.

> to the right recipient via paths you don't authorize,

   Modulo a definition of "right recipient", this is quite true.

> and there's nothing you can do about it.

   That is less true; and we shouldn't confuse these two clauses.

   If indeed the intended sender policy were "please reject email
arriving from any other MTA" (which it may well be, whether we like
that or not) _and_ receiver policy did so, the sender would have
succeeded in exactly what John Levine said is impossible.

> implemented by mail systems that many people use.

   I don't believe that was the intended meaning of "standard". :^(

   (We do indeed seem to be talking past each other much of the time.)

> I don't see anything as being "standard", which I why I don't see any
> value in offering advice about local policy.

   I fully believe John Levine doesn't see any such value.

   I also believe others do see some such value.

   Our actual problem isn't our differing beliefs, but an inadequate
_definition_ of what a sender policy of "-all" means.

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

   It's really easy to interpret this to mean that forwarding is not
authorized except through a limited number of explicitly authorized
forwarders.

   Indeed, I don't see any other reasonable interpretation. :^(

   4408bis _does_ go on to say:

]  Disposition of SPF fail messages is a matter of local policy. See
]  Section 9.3.2 for considerations on developing local policy.

   but this doesn't change the definition.

   There are indeed arguments to be made, based on other RFCs, that
the nature of email is such that the sender disclaims control of
what happens to any email once it leaves his/her MTA.

   But such implicit arguments don't negate a "no-forwarding" policy.
And SPF _seems_ to be a mechanism for providing out-of-band policy.

   Is it, or isn't it?

   (IMHO, we need to say one way or the other.)

--
John Leslie <[email-masked]>

---

From: "John R Levine" <[email-masked]>
Date: 14 Sep 2012 12:24:52 -0400

Can you give a step by step explanation of how you plan to keep people to 
whom you send mail from forwarding it wherever they want and otherwise 
implementing arbitrary local policies of which you disapprove?

Assume that we are fully aware of your published policy, and we choose to 
ignore it.

R's,
John

>   (IMHO, we need to say one way or the other.)

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