Subject: [spfbis] Recommend without mandating, was SPF parsing failure should default to SPF NEUTRAL

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Aug 2012 09:00:04 -0700

On Tue 31/Jul/2012 21:01:39 -0700 Scott Kitterman wrote:
> On Wednesday, August 01, 2012 01:44:06 PM Wayne Doust wrote:
>>> Your suggested wording for 2.5.6 reads to me as if SPF can ever
>>> provide a definitive result for message acceptance.  It can't.
>>
>> I've used the wording from other parts of the same section. It
>> doesn't seem to be a problem there to recommend a course Of
>> action without mandating it.
> 
> With one exception, RFC 4408 doesn't specify receiver policy.  The
> furthest is goes is to say, if you do X, then do it this way.
> That's significantly different than what I think you are
> suggesting.

For the sake of clarity, it would be better to mention that protocol Y
specifies how to do X.  Examples may improve readability without
conflating which specification is in charge of specifying how to do X.

In order to convey that attempted relays with an SPF result of R
deserve X, we must say so explicitly.  The importance of such
specifications cannot be overemphasized.  Not only they are needed for
discussing the pros and cons of possible alternative behaviors, but
they are fundamental to convey the exact meaning of R.

It has been noted multiple times that the terms of RFC 2119 are not
suitable for such specifications.  That doesn't make them any less
urgent, we just have to use other terms.

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Aug 2012 12:09:04 -0400

Wayne Doust wrote:

> I don't see how this follows. The "Bad Guy" would have to own the domain and 
> publish the SPF record. A bad guy with an invalid SPF record is in
> a worse position than a "Bad Guy" with a valid SPF record.

Right, but your proposal would relax the invalid SPF record to an 
indeterminate ("throw your hands up/give up") neutral condition which 
means it passes/skips SPF testing.

>> But lets remember that ABUSE is also not just the user but also 
>> the receiver getting slammed with malicious abusive spoofers.
> 
> This is OT, but the only case where I see this applies is publishing 
> a costly SPF record and then spamming possibly causing DOS.

Abuse does not need to reach a DoS, but the attempt to do so and also 
just taking up CPU processing time and system resources, increasing 
your TCO. It may depend on volume.  The bigger you are, the more you 
can absorb it (or not), but the smaller system will feel it (or not), 
they will be more apt to notice it.

One way to measure it is with higher SMTP session times.

>> What will you do if it was a bad guy with syntax errors?  Accept the mail?
> 
> Treat them as a bad guy with no SPF record. I don't see many bad 
> buys WITH SPF records (yet).

There are quite of bit of them, and if want to lump Spammers and
eMarketers with the "bad guy" label, there are quite a bit that want
to give the "good guy" appearances of compliancy and following all the
best current practices.

>> Is there anything in SPF that can cause a PERMERROR in this similar manner?  
>> Where it can be too STRICT and needs to be RELAXED?
> 
> The grammar for SPF is quite strong. However IME, there are mail 
> scanning "devices" that have choked on proper SPF entries.

One case where a PERMERROR to REJECT translation can be a problem are 
with the artificial limits placed on SPF.  Why 10?  Why not 8 or 12, 
or even 20?

This seems like Deja Vu to me, but Scott may wish to consider how 
SenderID RFC4406 has it written:

    5.1.  Neutral, None, SoftFail, or PermError

    An SMTP server receiving one of these results SHOULD NOT reject the
    message for this reason alone, but MAY subject the message to
    heightened scrutiny by other measures, and MAY reject the message as
    a result of this heightened scrutiny.

    Such additional security measures MAY take into account that a
    message for which the result is "SoftFail" is less likely to be
    authentic than a message for which the result is "Neutral".

The thing is that the "heightened scrutiny" was learned and if a 
policy is perpetually in permerror, then as RFC 4408 has it as open 
ended, it does require an manual intervention or as I like to shoot 
for, automated logic to take action on those domains with invalid 
policies.  Making it neutral is cool, but if its not fixed, eventually 
that needs to be seriously address and rejected - IMO.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 01 Aug 2012 12:39:23 -0700

Hello,

I would like to remind the working group that all IETF Contributions 
are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 
4879).   Please read the "Note Well" ( 
https://www.ietf.org/about/note-well.html ).

Section 5.2 of RFC 5378 states that:

   "No information or document that is subject to any requirement of
    confidentiality or any restriction on its dissemination may be
    submitted as a Contribution or otherwise considered in any part of
    the IETF Standards Process, and there must be no assumption of any
    confidentiality obligation with respect to any Contribution.  Each
    Contributor agrees that any statement in a Contribution, whether
    generated automatically or otherwise, that states or implies that the
    Contribution is confidential or subject to any privilege, can be
    disregarded for all purposes, and will be of no force or effect."

Working participants are deemed to have accepted all IETF rules of 
process, including the above about disclaimers.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Aug 2012 14:53:18 -0700

On Tue, Jul 31, 2012 at 9:36 PM, Wayne Doust
<[email-masked]>wrote:

> Currently, there is no recommendation for PermErrors at all. I think it
> should be clearly stated that PermErrors should be treated as no worse
> than None.
>

I think this argument reduces to "Don't bounce mail, because software at
either end could be buggy."  One might even argue that a bug somewhere in
the evaluation might trigger the "-all" at the end of the record for an
otherwise legitimate message, and that's also obviously bad.

But I'm not sure that we have to deal with it here.  A faulty
implementation of anything can have serious results that become pain points
for either end of the protocol.  SPF isn't special in that regard.

I suppose, though, that some informative discussion of this particular
issue somewhere (an appendix) with the above in mind might be prudent.

-MSK

---

From: "Wayne Doust" <[email-masked]>
Date: Thu, 2 Aug 2012 09:10:29 +1000

-----Original Message-----
This seems like Deja Vu to me, but Scott may wish to consider how SenderID RFC4406 has it written:

--

I think this would foot the bill very nicely!

********************************************************************************************************
Disclaimer: This email message and any attachments are confidential.   
The information contained in this email message and any attachments may be 
confidential information. If you are not the intended recipient, any use, interference with, 
disclosure or copying of this material is unauthorised and prohibited.
This email and any attachments are also subject to copyright.  
No part of them may be reproduced, adapted or transmitted without the written
permission of the copyright owner.
If you have received this email in error please immediately advise the sender 
by return email and delete the message from your system. 
Although this email has been checked for viruses and other defects, no responsibility 
can be accepted for any loss or damage arising from its receipt or use.
Racing Victoria Limited respects your privacy. Our privacy policy can be accessed 
from our web site: "http://www.racingvictoria.net.au"
********************************************************************************************************

---

From: Stuart Gathman <[email-masked]>
Date: Thu, 02 Aug 2012 20:55:28 -0400

Long ago, Nostradamus foresaw that on 07/30/2012 05:36 PM, Derek Diget
would write:
> =>The SPF specification *mandates* a result of PERMERROR (not fail or
> =>softfail) for parsing failures.  It already recommends treating
> =>PermError like neutral.  
>
> Can you point me in the direction where RFC4408 says that?  I don't see 
> it in section 2.5.7 nor anywhere else in the doc.
4.6. Record Evaluation

After one SPF record has been selected, the check_host() function parses
and interprets it to find a result for the current test. If there are
any syntax errors, check_host() returns immediately with the result
"PermError".

Implementations MAY choose to parse the entire record first and return
"PermError" if the record is not syntactically well formed. However, in
all cases, any syntax errors anywhere in the record MUST be detected.

-----------

However, I don't find a local policy recommendation either - I must have
been remembering the many discussions.  Which is just as well, because
PermError should get rejected with a 5xx and a diagnostic for the syntax
error.  That's what happens when a mail admin makes other boneheaded
mistakes that are easy to fix and easy to prevent (run a record checker).

---

From: "Wayne Doust" <[email-masked]>
Date: Fri, 3 Aug 2012 15:41:03 +1000

I think Derek was referring to the second part of what you mentioned,
not the first part (I have deleted the first part for clarity)

-----Original Message-----
>> => It already recommends treating 
>> Can you point me in the direction where RFC4408 says that?  I don't 
>> see it in section 2.5.7 nor anywhere else in the doc.
-----------
mistakes that are easy to fix and easy to prevent (run a record
checker).
-----------

I disagree. There are a number of reasons a PermError can be generated.
Rejecting because of PermError simply punishes a domain for publishing
an SPF record. It should be treated no worse than None - and the spec
should indicate that just as it does for Neutral, and for precisely the
same reasons.

At worst, a 4xx can be issued with a detailed reason why. There are a
HUGE number of syntactically incorrect SPF records out there. This week
alone I've advised five hosting services that their SPF records are
incorrect and will not work. Most of them are simple typos, others
betray a fundamental misunderstanding of how SPF works.

Of course, there's nothing stopping you (an informed email sysadmin that
checks their logs) from doing so. What I'm saying is this is the best
"default" case for the (unfortunately) vast majority of sysadmins that
have just heard about SPF or has just ticked a box that says "spf".

Putting it another way, what should the Out-of-the-box behaviour for M$
Exchange 50 user small business edition be as administered by the office
accountant after doing a 5 day course on system administration?

---

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

same reasons.

I can't see how your proposed solution does anything other than reduce to a
statement such as: "SPF attempts to establish a strong email policy layer,
but you should never actually enforce it because there could be a bug."

> betray a fundamental misunderstanding of how SPF works.

Speaking practically, temp-fails are effectively delayed perm-fails.
Nobody looks in the queues for things that are temp-failing and attempts to
debug them before a final bounce occurs.  Or, at a minimum, that case is
exceedingly rare.

> have just heard about SPF or has just ticked a box that says "spf".

We've been very careful in all protocol documents lately (ADSP, DKIM, SPF,
and greylisting all come to mind) to talk only about what one could do with
the results of those various systems, and not prescribing specific actions.
That is, enable informed decisions, but don't prescribe specific actions.
To that end, I'd be fine using soft language to suggest possible courses of
action, but I'm not sold on the idea that requiring PermError to be the
same as None is the right thing to do.

> accountant after doing a 5 day course on system administration?

What's the likelihood that the office accountant with a 5-day course on
system administration will read the document we're about to produce?
Aren't implementers the real targets here?

As was already pointed out by one of the co-chairs, this disclaimer
contradicts IETF IPR rules, and it means we can't use your contributions as
part of our work.  You probably should stop sending it.

It's also obnoxiously large, and you could get warlorded.  :-)

-MSK

---

From: "Wayne Doust" <[email-masked]>
Date: Fri, 3 Aug 2012 16:51:37 +1000

On Thu, Aug 2, 2012 at 10:41 PM, Wayne Doust
<[email-masked]> wrote:

	I disagree. There are a number of reasons a PermError can be
generated.
	Rejecting because of PermError simply punishes a domain for
publishing
	an SPF record. It should be treated no worse than None - and the
spec
	should indicate that just as it does for Neutral, and for
precisely the 

	same reasons.

I can't see how your proposed solution does anything other than reduce
to a statement such as: "SPF attempts to establish a strong email policy
layer, but you should never actually enforce it because there could be a
bug."

I don't see that as being equivalent. Consider the possible scenarios:

1)      (Most likely) Faulty syntax in the SPF record: The publisher
should know better, but doesn't. So treat them like they haven't
published it all.

2)      Incorrect parsing: Less likely, but it DOES happen.

In either case, a PermError tells us precisely nothing about the SPF
record. So why treat it as anything other than None? We aren't refusing
to enforce a policy because we don't know what that policy is.

The very name "PermError" can (and does) lead implementers to lump
PermError in with Fail. Of course there's nothing stopping someone from
consciously doing it, but should that be the default action?

	At worst, a 4xx can be issued with a detailed reason why. There
are a
	HUGE number of syntactically incorrect SPF records out there.
This week
	alone I've advised five hosting services that their SPF records
are
	incorrect and will not work. Most of them are simple typos,
others
	betray a fundamental misunderstanding of how SPF works.

Speaking practically, temp-fails are effectively delayed perm-fails.
Nobody looks in the queues for things that are temp-failing and attempts
to debug them before a final bounce occurs.  Or, at a minimum, that case
is exceedingly rare.

This is OT: But I temp-fail on SPF Fail with the reason why and a phone
number to ring. This gives the sender a chance to call us and have them
placed in our white-list. I also auto white-list all outgoing email
addresses. The users know that if someone can't email them, then sending
the SENDER an email usually "fixes" that.

As the adoption of SPF moves forward, I will probably start using an
initial temp-fail on SPF SoftFail.

We've been very careful in all protocol documents lately (ADSP, DKIM,
SPF, and greylisting all come to mind) to talk only about what one could
do with the results of those various systems, and not prescribing
specific actions. That is, enable informed decisions, but don't
prescribe specific actions.  To that end, I'd be fine using soft
language to suggest possible courses of action, but I'm not sold on the
idea that requiring PermError to be the same as None is the right thing
to do.

No, I'm not saying it should be proscribed either. I'm saying the
possibilities should be mentioned, and I do understand the NEUTRAL is a
special case.

	Putting it another way, what should the Out-of-the-box behaviour
for M$
	Exchange 50 user small business edition be as administered by
the office
	accountant after doing a 5 day course on system administration?

Yes they are. The implementers being those who make email filtering
software and appliances. In the absence of any defaults in the spec,
they will make them up. The "office account" will simply tick a box and
be done with it. When someone complains that their email is being
blocked because of SPF and says "everyone else can receive my email
except YOU guys..", he will simply uncheck that box and do no SPF
checking at all.

As was already pointed out by one of the co-chairs, this disclaimer
contradicts IETF IPR rules, and it means we can't use your contributions
as part of our work.  You probably should stop sending it.

Point taken. J

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Aug 2012 08:00:52 -0700

On Thu, Aug 2, 2012 at 11:51 PM, Wayne Doust
<[email-masked]>wrote:

>
> I can't see how your proposed solution does anything other than reduce to
> a statement such as: "SPF attempts to establish a strong email policy
> ** **
> I don’t see that as being equivalent. Consider the possible scenarios:****
>
> ** **
>
> **1)      **(Most likely) Faulty syntax in the SPF record: The publisher
> should know better, but doesn’t. So treat them like they haven’t published
> it all.****
>
> **2)      **Incorrect parsing: Less likely, but it DOES happen.****
>
> ** **
>
> record. So why treat it as anything other than None? We aren’t refusing to
> enforce a policy because we don’t know what that policy is.
>

I think in the case where everything's working, PermError indicates, quite
emphatically, that the SPF record could not be used to make a positive
determination about the message's path authorization.  That's far from
"precisely nothing".

In the case of a parsing bug, it indicates the presence of a problem
somewhere, but is ambiguous about where.  That's also not "precisely
nothing", but it is certainly a less direct indication.

Anyway, I believe the issue you're having is that "PermError" rejection is
only able to send its message in one direction, namely back to the sender.
If the receiver has a bug (less likely, as you said), it's never actively
notified of this; one would have to check logs to observe that there's a
problem.

> ****
>
> ** **
>
> The very name “PermError” can (and does) lead implementers to lump
> PermError in with Fail. Of course there’s nothing stopping someone from

I don't think that's the logic implementers are applying.  It's rather the
desire to be as protective of the receiver as possible, essentially a
choice between a "default deny" posture and a "default allow" posture.  In
some sense that's a product decision and not something the document can or
should specify.

****
> No, I’m not saying it should be proscribed either. I’m saying the
I think discussion is fine, but I don't think we should go further than
that.

With that in mind: Scott, do you have usable text from upthread someplace
to consider, or would you like some?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 03 Aug 2012 11:14:47 -0400

> some sense that's a product decision and not something the document can or

In applications I've developed these are separate knobs that can be turned 
independently, so I concur with your assessment.  In my case I've tended to 
use a default deny approach, but it's easy enough to adjust.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Aug 2012 22:37:08 -0700

As a suggested resolution to this thread, I propose this for a new
subsection of Section 9:

9.x. Handling Of "permerror" Results

The "permerror" result (see Section 2.5.y) indicates the SPF processing
module at the receiver determined that the received SPF policy record could
not be interpreted.  This gives no true indication about the authorized use
of the data found in the envelope.

As with all results, implementers have a choice to make regarding what to
do with a message that yields this result.  SMTP allows only a few basic
options.

Rejection of the message is an option, in that it is the one thing a
receiver can do to draw attention to the difficulty encountered while
protecting itself from messages that do not have a definite SPF result of
some kind.  However, if the SPF implementation is defective and returns
spurious "permerror" results, only the sender is actively notified of the
defect (in the form of rejected mail), and not the receiver making use of
SPF.

The less intrusive handling choice is to deliver the message, perhaps with
some kind of annotation of the difficulty encountered and/or logging of a
similar nature.  However, this will not be desirable to operators that wish
to implement SPF checking as strictly as possible, nor is this sort of
passive problem reporting typically effective.

There is of course the option placing this choice in the hands of the
operator rather than the implementer, but this adds one more piece of
complexity to an already non-trivial environment.

Both implementers and operators need to be cautious of all choices and
outcomes when handling SPF results.

-MSK