Subject: [spfbis] SPF parsing failure should default to SPF NEUTRAL

From: "Wayne Doust" <[email-masked]>
Date: Mon, 30 Jul 2012 11:36:32 +1000

I have to deal with SPF failures (and explaining the reasons why) on an
almost daily basis. Aside from forwarding issues, the next biggest cause
of SPF failure I encounter is problems with parsing the SPF record.
Sometimes it is a problem with MY record that cannot be parsed, other
times it is a problem with the sender's record. From what I have
gathered so far, usually the issue arises with dealing with listing
entire subnets within the SPF record. Fixing such an issue requires
(generally) some level of communication between IT departments. In my
experience, the success of this effort is inversely proportional to the
size of their IT Department. In a recent case I dealt with a very large
ISP in Australia that spent two weeks treating me like a bozo before
they finally admitted they had a problem with their Cisco Ironport
setup.

If possible, I think the SPF specification should recommend a parsing
failure should default to an SPF of NEUTRAL rather than a FAIL or
SOFTFAIL as is usually the case. In most cases I deal with the remote
sysadmin has simply implemented some off-the-shelf solution and ticked
the SPF "box" and that's the end of the story. Most have no way of
dealing with the issue other than whitelisting the entire domain -
something that to me defeats the entire purpose of SPF.

If a site HAS published SPF and a broken 3rd party mail filter cannot
parse the record, the domain is effectively penalised and in a worse
situation than had they published no record at all. At the very worst
the fallback position should be to perform rDNS checks and rely on that.

Regards,

Wayne Doust

********************************************************************************************************
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: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jul 2012 19:28:38 -0700

On Sun, Jul 29, 2012 at 6:36 PM, Wayne Doust
<[email-masked]>wrote:

> almost daily basis. Aside from forwarding issues, the next biggest cause of
> SPF failure I encounter is problems with parsing the SPF record. Sometimes
> it is a problem with MY record that cannot be parsed, other times it is a
> problem with the sender’s record. From what I have gathered so far, usually
> the issue arises with dealing with listing entire subnets within the SPF
> record. Fixing such an issue requires (generally) some level of
> communication between IT departments. In my experience, the success of this
> effort is inversely proportional to the size of their IT Department. In a
> recent case I dealt with a very large ISP in Australia that spent two weeks
> treating me like a bozo before they finally admitted they had a problem
> with their Cisco Ironport setup.
>

I'm confused a bit here.  Listing an entire subnet isn't by itself a syntax
error or parsing problem, is it?  It's a matter of having too broad of an
authorization, correct?

> ****
> ** **
> failure should default to an SPF of NEUTRAL rather than a FAIL or SOFTFAIL
> as is usually the case. In most cases I deal with the remote sysadmin has
> simply implemented some off-the-shelf solution and ticked the SPF “box” and
> that’s the end of the story. Most have no way of dealing with the issue
> other than whitelisting the entire domain – something that to me defeats
> the entire purpose of SPF.****
>
> ** **
>
> situation than had they published no record at all. At the very worst the
> fallback position should be to perform rDNS checks and rely on that.
>

How a filter actually responds to a softfail or fail isn't specified by
either version of the document.  (Or neutral, for that matter.)
Essentially the filter has made an unfortunate decision.  If RFC4408bis
doesn't adequately warn of "use cases" such as these, I agree that we
should consider mentioning them.

-MSK

---

From: Stuart Gathman <[email-masked]>
Date: Sun, 29 Jul 2012 22:29:59 -0400

Long ago, Nostradamus foresaw that on 07/29/2012 09:36 PM, Wayne Doust
would write:
> dealing with the issue other than whitelisting the entire domain --
The SPF specification *mandates* a result of PERMERROR (not fail or
softfail) for parsing failures.  It already recommends treating
PermError like neutral.  

Such recommendations are irrelevant anyway, since you are expecting
people who aren't following the spec in the first place to heed them. 
In relaxed mode, pyspf applies heuristics to PermError (translating
common errors like A:1.2.3.4 to IP4:1.2.3.4) and then (in addition)
returns the heuristic result as a "best guess" for local policy
purposes.   When the "best guess" is a "pass", my policy is to then send
an automatic DSN with the diagnostic for the PermError.

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Jul 2012 00:37:23 -0400

> either version of the document.  (Or neutral, for that matter.)

-1,  SPF is very clear about FAIL.  Lets be very clear for protocol 
developers between the deterministic and reputation world and the 
battles over the year.  SPF always offered a clear avenue for 
rejection of what was deemed BAD mail. It is was essential reason for 
its existence after the 2003 SORBIG attack that hurt everyone with a 
dual blitz attack:

   - Blitz #1 - spoof the return path address - cross fingers server 
accepted
                RCPT. Bad guys targeted accept always servers which 
were dominate
                in years past.

   - Blitz #2 - If accepted mail was not deliverable, cross fingers 
server
                bounced mail to spoofed return path address.

That is why SPF existed and LMAP like protocols were started and a 
resultant FAIL was deemed rejected mail - and expected by the 
publishing domain. Otherwise don't use -ALL

It is written in 4408 very clearly.

In the abstract, with its theme sentence regarding the problem - FORGERY.

In section 1.0

    Furthermore, if a claimed identity fails verification, local policy
    can take stronger action against such E-Mail, such as rejecting it.

In section 2.4

    Although invalid, malformed, or non-existent domains cause SPF checks
    to return "None" because no SPF record can be found, it has long been
    the policy of many MTAs to reject E-Mail from such domains,
    especially in the case of invalid "MAIL FROM".

    [5321 even provide insights for requiring and rejection invalid
     mail froms]

In section 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.  The checking
    software can choose to mark the mail based on this or to reject the
    mail outright.

We seriously need to halt the continued misconception and attempts to 
instill false understandings of SPF, that it was never about rejecting 
(SPF detected) forged mail, especially with the exclusive domain 
policies using -ALL (FAIL).  It was what SPF was all about very much 
different than other watered down low/no payoff prototols such as DKIM 
remodeled with POLICY removed and reshaped for non-persistent, 
non-consistent modeling on reputation, leaving very little payoff but 
to processing and use heuristic.  SPF is not DKIM.  It has a strong 
deterministic framework - by design.  Its not DKIM.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Jul 2012 00:49:03 -0400

Wayne,

Our input is:

The best way to do with this is to track failure, treat as none, but 
don't tolerant it after X period and then determine if its requires 
rejection.

If its a "Good Guy" then in most support cases, if they don't wish to 
fix their problem or are presently in denial, you have no choice but 
to white list them so that it doesn't add to your processing or 
support overhead.  If a bad guy, then its easy - block them.

For us, SPF is just one of a suite of testing. For an processing 
error, its treated as NONE - like it never existence, i.e. 
indeterminate, no result.  I don't think a good system can fallback to 
FAIL/SOFTFAIL if A) the domain did not declare it or b) without some 
form of analysis of the sender at some point. In the automated world, 
the risk is too high for false positives (thats not to suggest there 
is a high occurrence of bad SPF policy statements).  But the FAIL-SAFE 
is better until one can see if its an abusive system, then adding a 
block for it is par for the course.

-- 
HLS

---

From: "Wayne Doust" <[email-masked]>
Date: Mon, 30 Jul 2012 15:02:00 +1000

| I'm confused a bit here.  Listing an entire subnet isn't by itself a
syntax error or parsing problem, is it?  It's a matter of having too
broad of an authorization, correct?

Most of the parsing failures I've encountered do seem to be failing on
either IP4 or IP6 subnets. Certainly for the record I'm responsible for,
that seems to be the case. Nearly always it is due to some
out-of-the-box email filter that is the problem and I'm greeted with
"Ha! We use XYZ email filter! It must be YOUR problem."

| How a filter actually responds to a softfail or fail isn't specified
by either version of the document.  (Or neutral, for that matter.)
Essentially the filter has made an unfortunate decision.  If RFC4408bis
doesn't adequately warn of "use cases" such as these, I agree that we
should consider mentioning them.

This is essentially what I'm advocating:

A STRICT check should REQUIRE an SPF PASS.

A MODERATE check should REQUIRE an SPF PASS, NEUTRAL or NONE, but ALSO
permit a PERMERROR or TEMPERROR. This means a Moderate check should ONLY
Fail on an SPF FAIL or SPF SOFTFAIL.

A RELAXED check should ONLY Fail on an SPF FAIL.

---

From: "Wayne Doust" <[email-masked]>
Date: Mon, 30 Jul 2012 15:11:39 +1000

-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Monday, 30 July 2012 2:49 PM
To: Wayne Doust
Cc: [email-masked]
Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL

If its a "Good Guy" then in most support cases, if they don't wish to fix their problem or are presently in denial, you have no choice but to white list them so that it doesn't add to your processing or support overhead.  If a bad guy, then its easy - block them.

For us, SPF is just one of a suite of testing. For an processing error, its treated as NONE - like it never existence, i.e. 
indeterminate, no result.  I don't think a good system can fallback to FAIL/SOFTFAIL if A) the domain did not declare it or b) without some form of analysis of the sender at some point. In the automated world, the risk is too high for false positives (thats not to suggest there is a high occurrence of bad SPF policy statements).  But the FAIL-SAFE is better until one can see if its an abusive system, then adding a block for it is par for the course.
--

Please allow me to paint the picture from Sysadmin of an SME (like me) being called by a user:

1) If a user can't receive email from a third party - it's MY fault. "They can send email to EVERYONE else!"
2) If a user can't send email to a third party - it's MY fault. "They can receive email from EVERYONE else!"

If #1 happens, that's easy: I whitelist the remote user. In fact, I now auto-whitelist ALL outgoing recipient email addresses.
If #2 happens, there's not much I can do other than attempt to contact the remote IT Department. Something I do all too often.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Jul 2012 00:02:18 -0700

On Sun, Jul 29, 2012 at 10:02 PM, Wayne Doust <[email-masked]
> wrote:

> syntax error or parsing problem, is it?  It's a matter of having too broad
> of an authorization, correct?
>  ****
>
> Most of the parsing failures I’ve encountered do seem to be failing on
> either IP4 or IP6 subnets. Certainly for the record I’m responsible for,
> that seems to be the case. Nearly always it is due to some out-of-the-box
> email filter that is the problem and I’m greeted with “Ha! We use XYZ email
> filter! It must be YOUR problem.”
>

So you really are talking about syntax errors here.

Section 2.5.8 of RFC4408 seems to be pretty clear that this should result
in a "permerror", not "neutral", "none", or "softfail".  A filter that
yields one of the latter results when it encounters a syntax error in the
DNS record is plainly broken.

> ****
>
>
> | How a filter actually responds to a softfail or fail isn't specified by
> This is essentially what I’m advocating:****
>
> ** **
>
> A STRICT check should REQUIRE an SPF PASS.****
>
> Fail on an SPF FAIL or SPF SOFTFAIL.****
>
> A RELAXED check should ONLY Fail on an SPF FAIL.****
>
>
>
>
I don't think we have specific definitions of STRICT, MODERATE, or RELAXED
the way you're using them here, so we can't really say anything like what
you're saying in a normative sense.  If we did, we'd also have to include
some guidance about when each of those modes would be appropriate to
apply.  I think it's far simpler to leave that in the hands of the
(educated, one would hope) reader.  Why, for example, would I not want a
STRICT check if I have users to defend?

Essentially, RFC4408 leaves it in the hands of implementers to decide what
to do with any given result.  In particular, "fail" does not actually
require rejection of a message:

2.5.4 <http://tools.ietf.org/html/rfc4408#section-2.5.4>.  Fail

It then proceeds to say "If you're going to reject, here's how we think you
should go about it."  But none of that is required in either RFC4408 or its
planned successor.

If you post a syntactically valid SPF record and someone's broken filter
rejects your mail anyway, and that recipient is daft enough to stand by
that filter, I imagine there's not much a spec writer could do to change
that person's mind.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Jul 2012 04:04:14 -0400

> A RELAXED check should ONLY Fail on an SPF FAIL.

I think I partly follow your point now.

If the DOMAIN publishes exclusive policies for hard failures, then an 
error processing should fallback to a a FAIL SPF result.

That may have reasoning logic to consider. However, not sure what 
STRICT, MODERATE, RELAXED means or where you are going with this but 
there is only one form of SPF checking - the correct one. Everyone 
MUST follow the same protocol and expectations for proper processing.

Sounds to me that there is also a programming issue where complexity 
has become a worth factor.  What happens now is that it breakdowns to 
this:

   FORMS OF CHECKING:

   STRICT   - complete 100% correct and support of all SPF features.
   MODERATE - partial < 100% correct and support of SPF features.
   RELAXED  - Less than MODERATE support of SPF features.

I don't think we want to go there - 100% support if expected others 
the SPF receiver is not complaint and it worst, it will water down, 
weaken SPF publishing of statements dependent on subjective design 
viewpoint of "Software Complexity."   There MUST be one design 
expectation - ALL or nothing, unless of course there is an existing 
OPTION for not supporting. But it has to be written what is OPTIONAL 
or not.

Anyway, You're talking about an invalid SPF policy - thats not your 
fault. Passing the buck isn't going to help your user who can care 
less. QA/Customer Support 101 - the customer is always right.

IMTO, the best you can do is monitor, track whether the 3rd party is a 
good or bad guy.  The same issue can be applied to other issues 
already on the tracker concerning any kind temporary, permanent or 
perpetual error - does the receiver have a right to take action at 
some point?  When does a temporary but perpetual errors become 
permanent to avoid the overhead, the redundant invalid SPF policy 
processing?  These are implementation specific suggestions, although I 
believe it should be considered for a protocol.

-- 
HLS

---

From: Benny Pedersen <[email-masked]>
Date: Mon, 30 Jul 2012 21:32:50 +0200

Den 2012-07-30 03:36, Wayne Doust skrev:
> Our privacy policy can be accessed from our web

our maillist :/

---

From: Derek Diget <[email-masked]>
Date: Mon, 30 Jul 2012 17:36:14 -0400 (EDT)

On Jul 29, 2012 at 22:29 -0400, Stuart Gathman wrote:
=>Long ago, Nostradamus foresaw that on 07/29/2012 09:36 PM, Wayne Doust
=>would write:
=>>
=>> If possible, I think the SPF specification should recommend a parsing
=>> failure should default to an SPF of NEUTRAL rather than a FAIL or
=>> SOFTFAIL as is usually the case. In most cases I deal with the remote
=>> sysadmin has simply implemented some off-the-shelf solution and ticked
=>> the SPF "box" and that's the end of the story. Most have no way of
=>> dealing with the issue other than whitelisting the entire domain --
=>> something that to me defeats the entire purpose of SPF.
=>>
=>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.

Thanks.

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: "Wayne Doust" <[email-masked]>
Date: Tue, 31 Jul 2012 14:57:36 +1000

> If the DOMAIN publishes exclusive policies for hard failures, then an error processing should fallback to a a FAIL SPF result.

Close, but not quite.

The (generally reasonable) assumption for a PERMERROR is an error in the syntax of an SPF record. However, I *know* that my SPF record is syntactically correct, however I still get mail rejected because of PERMERROR. And I don't mean from small sites. I've had problems with large ISPs, a government department and Australia Post reject email with a 45x on the basis of a PERMERROR.

>That may have reasoning logic to consider. However, not sure what STRICT, MODERATE, RELAXED means or where you are going with this 

>but there is only one form of SPF checking - the correct one. Everyone MUST follow the same protocol and expectations for proper processing.

I agree. However perhaps the specification can go beyond the immediate categories to recommending how to deal with each of the results under different conditions.

> I don't think we want to go there - 100% support if expected others the SPF receiver is not complaint and it worst, it will water down, weaken SPF publishing of statements dependent on subjective design 

I think we already ARE there. Not everyone implements pySPF. Most implementors exposure to SPF is via a GUI that has stuff like this:

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 31 Jul 2012 01:19:26 -0400

On Tuesday, July 31, 2012 02:57:36 PM Wayne Doust wrote:
> The (generally reasonable) assumption for a PERMERROR is an error in the
> syntax of an SPF record. However, I *know* that my SPF record is
> syntactically correct, however I still get mail rejected because of
> PERMERROR. And I don't mean from small sites. I've had problems with large
> ISPs, a government department and Australia Post reject email with a 45x on
> the basis of a PERMERROR.
 
Assuming racingvictoria.net.au is the correct domain, you're correct.  
Erroneous permerror can come from implementation errors in the receiver 
system.  It would be interesting to know the domain/IP address that's gotten 
such an error recently.
 
> >That may have reasoning logic to consider. However, not sure what STRICT,
> >MODERATE, RELAXED means or where you are going with this 
> 
> 
> >but there is only one form of SPF checking - the correct one. Everyone MUST
> >follow the same protocol and expectations for proper processing.
> 
> I agree. However perhaps the specification can go beyond the immediate
> categories to recommending how to deal with each of the results under
> different conditions.
 
> > I don't think we want to go there - 100% support if expected others the
> > SPF receiver is not complaint and it worst, it will water down, weaken
> > SPF publishing of statements dependent on subjective design 
> 
>  
> 
> I think we already ARE there. Not everyone implements pySPF. Most
> implementors exposure to SPF is via a GUI that has stuff like this:
 
Nothing in the picture has anything to do with the SPF protocol.  How 
receivers handle SPF results is entirely up to them.  BTW, such a GUI with no 
explanation about what the options mean or the potential impacts is a complete 
disaster waiting to happen.  It's a good sign you're using the wrong software.

pySPF is nothing more than a library that implements RFC 4408, there are 
several.

Scott K

---

From: "Wayne Doust" <[email-masked]>
Date: Tue, 31 Jul 2012 16:05:08 +1000

> Erroneous permerror can come from implementation errors in the
receiver system.  It would be interesting to know the domain/IP address 
> that's gotten such an error recently.

I can provide several. However, most of them fixed the issue with a
whitelist. Next time I get a live one, I'll email you.

> Nothing in the picture has anything to do with the SPF protocol.  

If we remember that all we are doing with SPF (and other ant-spam
devices) is fixing an IETF specification that started out broken (SMTP);
then we must assume that it is incumbent upon us to develop a spec that
assumes a worst-case scenario rather than a best-case.

Implementors of email systems and mail filters will never expose mail
system administrators to the nuts and bolts. That will only generate
service-desk calls. They will make is as dumbed down as they can. The
problem is that without guidance, vendor A's dumbing down will be
different to vendor B's. Why not provide recommendations for dumbing
down in the spec? That recommendation SHOULD include treating PERMERROR
and TEMPERROR in same category as a NEUTRAL. It could be a "Best
Practice for SPF" recommendation.

> BTW, such a GUI with no explanation about what the options mean or the
potential impacts is a complete disaster waiting to happen.  It's a good
sign you're using the wrong software.

This is the GUI from MailMarshal. It is one of the "better" mail
filtering tools - and possibly one of the most popular. Others are MUCH
worse.

Like it or not, this is the way SME's - and even larger organisations -
are implementing SPF.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 31 Jul 2012 02:22:22 -0400

On Tuesday, July 31, 2012 04:05:08 PM Wayne Doust wrote:
...
> Practice for SPF" recommendation.

I would encourage you to review the group's charter.  We have a pretty tightly 
specified set of work we're scoped to do.  IMO, independent of if this is a 
good idea or not, it's outside our scope.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Jul 2012 00:36:44 -0700

> > assumes a worst-case scenario rather than a best-case.

You mean a 1980s protocol failed to foresee the environment present in
2010?  How could that possibly happen?

But seriously, I don't think the premise is valid here.  SPF is not an
attempt to fix something that's broken.  It's a policy layer on top of a
system that does exactly what it was designed to, and does it just fine.

> good idea or not, it's outside our scope.

I think considering advice like this is probably fine, assuming we can come
to consensus on such, but certainly altering the protocol or establishing
new normative requirements for receivers is not what we're authorized to do
here.

-MSK

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 1 Aug 2012 09:32:33 +1000

-----Original Message-----

I would encourage you to review the group's charter.  We have a pretty
tightly specified set of work we're scoped to do.  IMO, independent of
if this is a good idea or not, it's outside our scope.

Scott K
_______________________________________________

I accept that introducing new blanket classifications is possibly
outside the scope of the charter, however this does not mean that
recommendations on how to deal with the various results cannot be made.

Section 2.5 - Interpreting the result already does this. It provides
recommendations on dealing with the results. Sections 2.5.6 and 2.5.6
could easily be amended to recommend treating them the same as SPF
Neutral.

Section 2.5.4 "SHOULD use an SMTP reply code of 550"
Section 2.5.5 "can use and SMTP reply code of 451"

IMO Section 2.5.6 should be modified to remove the recommendation
"SHOULD use a reply code of 451". Section 2.5.7 should be modified to
recommend treating the PERMERROR as NEUTRAL or NONE.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 31 Jul 2012 19:37:31 -0400

On Wednesday, August 01, 2012 09:32:33 AM Wayne Doust wrote:
...
...

There are important if statements in those sections before the bits you quote 
that mean they don't at all do what you're claiming they do.  All they as is 
that if you are going to take certain actions, here is how you should 
communicate them.  They say nothing at all about what one should do.

Scott K

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 1 Aug 2012 09:48:58 +1000

-----Original Message-----

There are important if statements in those sections before the bits you
quote that mean they don't at all do what you're claiming they do.  All
they as is that if you are going to take certain actions, here is how
you should communicate them.  They say nothing at all about what one
should do.

Scott K

Using other sections as a template. The following sections could be
modified as follows:

2.5.6.  TempError

   A "TempError" result means that the SPF client encountered a
   transient error while performing the check.  Checking software can
   choose to accept or temporarily reject the message. If the message
   is rejected during the SMTP transaction for this reason, the software
   SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
   code with a note the first time the message is received, but accept
   it the second time.

2.5.7.  PermError

   A "PermError" result means that the domain's published records could
   not be correctly interpreted.  This signals an error condition that
   requires manual intervention to be resolved, as opposed to the
   TempError result.  Be aware that if the domain owner uses macros
   (Section 8), it is possible that this result is due to the checked
   identities having an unexpected format. A "PermError" result may also
   be due to a local parsing failure or DNS resolution error rather than
a
   problem with the published SPF record. For these reasons, Receiving 
   software SHOULD NOT reject the message based solely on this result,
   but MAY subject the message to closer scrutiny than normal. 

These changes should be within the scope of the charter.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 31 Jul 2012 22:42:38 -0400

> you should communicate them.  They say nothing at all about what one

I think you are repeating the mistakes of some of the early SPF evangelists.   
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.

If I read your rewrite of 2.5.6 correctly, I believe that what you're after is 
a receiver policy specification that based on temperror the only local policy 
actions that are acceptable are accept or defer.  I gather that what you want 
is to suggest reject on temperror is a bad idea?

I'm guessing similarly that for 2.5.7 you want to suggest rejecting on 
permerror is a bad idea.

What's an example of a permerrror that could be caused by local parsing 
failure or DNS resolution problems (I think all DNS errors end up as 
temperrors)?

Scott K

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 1 Aug 2012 13:44:06 +1000

> 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.

>  I gather that what you want is to suggest reject on temperror is a
bad idea?

Basically. As in section 2.5.5 - which recommends that treating it as
"greylisted" is the most extreme method of treating 
The response. Why should TEMPERROR or PERMERROR be treated more harshly
than Softfail?

permerror is a bad idea.

Correct.

> What's an example of a permerrror that could be caused by local
parsing failure or DNS resolution problems (I think all DNS errors end
up as temperrors)?

<450 4.7.1 <[email-masked]>: Recipient address rejected:
SPF-Result=mail01.mvrc.net.au: 'SERVFAIL' error on DNS 'SPF' lookup of
'mail01.mvrc.net.au'>

NB: I rarely see a 550 error on SPF. I think most sysadmins (including
myself) prefer to use 45x when rejecting messages based on SPF.

The following SPF record caused problems with some receivers -
apparently due to difficulty with parsing two lines of record:

afl.com.au. 600 IN TXT "v=spf1 mx ptr include:servers.mcsv.net ~all"
afl.com.au. 600 IN TXT "v=spf1 a mx ip4:203.89.249.0/26 ~all"

This record passes the Beveridge check but fails SK's check:

Mail sent from this IP address: 69.167.149.85 
Mail from (Sender): [email-masked] 
Mail checked using this SPF policy: v=spf1 mx ptr
include:servers.mcsv.net ~all 
Results - softfail domain owner discourages use of this host

Change the record to a single line:

afl.com.au. 600 IN TXT "v=spf1 a mx ptr ip4:203.89.249.0/26
include:servers.mcsv.net ~all"

and the result is:

Mail sent from this IP address: 69.167.149.85 
Mail from (Sender): [email-masked] 
Mail checked using this SPF policy: v=spf1 a mx ptr ip4:203.89.249.0/26
include:servers.mcsv.net ~all 
Results - PASS sender SPF authorized

The simple reality is that in RL, Receivers are lumping TempErrors and
PermErrors along with Fails. The spec should
recommend something along the lines of this type of "order of goodness"
for SPF results:

Pass
Neutral
None
TempError
PermError
SoftFail
Fail

In Meng's terminology of "Good" "Bad" and "Ugly", that could be:

Good: Pass
Bad: Fail (optionally)
Ugly: SoftFail, TempError, PermError
Neutral: Neutral, None

With "Neutral" potentially being lumped in with ugly.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Aug 2012 00:01:39 -0400

> 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.

> The response. Why should TEMPERROR or PERMERROR be treated more harshly

That's a matter for local policy, not protocol in the RFC 4408 design and I 
don't think we should change that.

> myself) prefer to use 45x when rejecting messages based on SPF.

Those are properly temperrors, which is why they get 45X responses.  45X is 
not a reject, it's a deferral.  So not a permerror.

> Results - PASS sender SPF authorized

Having two SPF record is a permerror.  That's not a permerror due to local DNS 
parsing.  It's a permerror due to bad record publishing.

I agree that temperrors can happen due to bad DNS on the receiver side, but 
not permerror.

> With "Neutral" potentially being lumped in with ugly.

Ironically, the one piece of receiver poilcy in RFC 4408 is that Neutral MUST 
be treated the same as None.  I think the fact that you're suggesting that 
perhaps the one place where receiver policy is specified should be changed 
should be an indicator of the folly of trying to do so even more.

Receivers are going to do what they are going to do.  Considering you are in 
your last mail incorrectly conflating temperrors and permerrors, claiming 
permerrors are inappropriate when they are not, and ascribing issues to 
receiver side processing that belong to the sender side I suspect to you ought 
to go revisit some of your assumptions and analysis before proceeding further.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Aug 2012 00:19:45 -0400

Wayne Doust wrote:

> Why should TEMPERROR or PERMERROR be treated more harshly
> than Softfail?

Does it?

First, TEMPERROR and PERMERROR are not domain policies where SoftFail 
is, they are local policy design concepts.

The main problem with any sort of error processing is that it presents 
a "security loophole" and it erroneous illusion of strong policies.

In other words, a bad guy could use a HARDFAIL (-ALL) or SOFTFAIL 
(~ALL) to give the appearance of a strong exclusive policy allowing 
for rejection, but then intentionally embeds an invalid syntax error. 
  If we relaxed the protocol with an PERMERROR fallbacks to a NEUTRAL 
result (possibly overriding the DOMAIN policy) then it become a 
potential security loophole to preemption, skipping or indeterminate 
(no result) condition, and the mail is accepted (after perhaps it 
passes any other testings, if any).

IMV, this is an implementation design to consider and how it could be 
offered to deployments.

That package you mentioned used a STRICT, MODERATE, RELAXED concept. I 
don't think this is general protocol material, but it could be 
information (not specifically this way) that can be provided as 
insight in 4408BIS.

But lets remember that ABUSE is also not just the user but also the 
receiver getting slammed with malicious abusive spoofers.

What will you do if it was a bad guy with syntax errors?  Accept the mail?

Even in SMTP, there are software that have a strict or relayed 821 
compliance level or 2821 or 5321.  That is why it more interesting to 
find out if there some particular issue with SPF syntax processing 
that can false positives.  But if this is a matter of "lazy" software, 
well, thats not our fault.

In SMTP, for mail form, technically, there is no space after the colon 
and before the left angle bracket.

   MAIL FROM:<address>    # VALID: No space after the colon

Having a space is a SMTP syntax violation.  Yet, here is a history to 
be relaxed here to accept the form with a space:

   MAIL FROM: <address>   # INVALID: space after the colon

Some SMTP software may enforce this strict rule.

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?

-- 
HLS

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 1 Aug 2012 14:36:20 +1000

I'll restrict my comments to PermErrors.

> 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.

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.

>> "greylisted" is the most extreme method of treating The response. Why

>> should TEMPERROR or PERMERROR be treated more harshly than Softfail?

> That's a matter for local policy, not protocol in the RFC 4408 design
and I don't think we should change that.

That doesn't seem to be a problem for 2.5.2 and 2.5.5

 - A "Neutral" result MUST be treated exactly like the "None" result 
 - A "SoftFail" result should be treated as somewhere between a "Fail"
   and a "Neutral".

I'm advocating similar wording for 2.5.7. 

> Those are properly temperrors, which is why they get 45X responses.
45X is not a reject, it's a deferral.  So not a permerror.

However the deferrals just go on and on... the email is still never
delivered. In most cases, 45x is the most extreme result given.

This is what I mean. You don't 45x on a SoftFail. The spec even says
that if you do this, only do it once. Why treat a PermError more harshly
than a SoftFail? It's not good enough to say it's local choice because
the spec doesn't even give a recommendation when it does do so for
Softfail and Neutral? With a recommendation it is still a local choice
even if the word SHOULD is used.

> Having two SPF record is a permerror.  That's not a permerror due to
local DNS parsing.  It's a permerror due to bad record publishing.

Okay, they publish a bad SPF record. So the default for many sites is to
block their email on the basis of SPF?

The correct way to deal with this should be to treat it as though they
have no published record.

> I agree that temperrors can happen due to bad DNS on the receiver
side, but not permerror.

These two get lumped in together an awful lot. In many cases, the SPF
Failure reason is not given or is simply ambiguous.

> Ironically, the one piece of receiver poilcy in RFC 4408 is that
Neutral MUST be treated the same as None.  I think the fact that you're
suggesting that perhaps the one place where receiver policy is specified
should be changed should be an indicator of the folly of trying to do so
even more.

I'm suggesting that SHOULD is the appropriate mechanism.

Logically, any site publishing an SPF record should not be punished for
either of the two situations:

1) They publish a bad SPF record. 
2) The receiver can't correctly parse a good SPF record.

In either case, it seems to me sensible that they should treat the
domain as having no SPF record rather than issuing a 45x or 550. 

To go one step further, a recommendation would be to reject email once
with a 45x with the message "Your SPF record is incorrect. Please advise
your systems administrators to fix it." And then accept it a second
time. This recommendation is not without precedent. A similar
recommendation is found in section 2.5.5:

   ... the receiving MTA could give the sender a
   message using a technique called "greylisting" whereby the MTA can
   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
   first time the message is received, but accept it the second time.

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 1 Aug 2012 15:09:37 +1000

-----Original Message-----
In other words, a bad guy could use a HARDFAIL (-ALL) or SOFTFAIL
(~ALL) to give the appearance of a strong exclusive policy allowing for rejection, but then intentionally embeds an invalid syntax error. 
  If we relaxed the protocol with an PERMERROR fallbacks to a NEUTRAL result (possibly overriding the DOMAIN policy) then it become a potential security loophole to preemption, skipping or indeterminate (no result) condition, and the mail is accepted (after perhaps it passes any other testings, if any).
-----

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.

> 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.

> 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).

> 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.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Aug 2012 02:12:01 -0400

> should be clearly stated that PermErrors should be treated as no worse

The original name for permerror was "unknown".  It's been a matter of some 
discussion in the SPF community about what the best approach is.  If you teat 
it like None, then bad records persist.  The theory behind reject is then the 
problem gets noticed and fixed.  The difference between a temperror and a 
permerror is that permerrors can't be fixed without an operator making a 
change, so there's value to not just depending on people reading their mail 
logs (which apparently almost no one bothers to do).

I've distributed software for over half a decade that defaults to reject on 
permerror with no complaints about it.  It also initially defaulted to 
deferring on temperror, but that caused problems and got complaints, so I 
changed it.

> >> should TEMPERROR or PERMERROR be treated more harshly than Softfail?

That is purely an example.  Receivers can treat softfail more harshly than 
none/neutral in whatever way they think makes sense.

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

That's the one exception to the no receiver policy rule.  It makes sense to 
require treating ?all the same as no record so that senders aren't punished 
for publishing partial records.  For organizations of any size it can be quite 
complex to get everything figured out.  This is much different than the basic 
syntax and DNS operations errors that permerror and temperror address.

> I'm advocating similar wording for 2.5.7.

The softfail wording doesn't give any operational guidance.  Only 2.5.2 affects 
the protocol design and specifies what receivers SHOULD do.  That's there for a 
very specific reason to avoid discouraging deployment that I don't think 
applies to any other results.

> delivered. In most cases, 45x is the most extreme result given.

Some temperrors resolve themselves.  Some don't.  This is a problem that we 
have an open issue to try and address.  If they really take operator 
intervention to fix, they should be permerrors not temperrors.  We have some 
words in the draft that try to address this by suggesting that receivers may 
want to keep state and treat persistent temperrors as permerrors instead.  
Whether they are then accepted or rejected,  I think it's better than staying 
in the queue for the life of the queue and then being rejected.

> even if the word SHOULD is used.

The spec only gives the greylisting idea as an example.  It's completely non-
normative.  The spec really doesn't give a recommendation for softfail other 
than between neutral/none and fail, which is extremely broad and in my opinion 
meaningless.

If faced with a choice between removing the rule that neutral has to be 
treated like none and extending receiver policy guidance to the rest of the 
results, I'd prefer removing it for none (not that I think it's a good idea).  
I can tell you that none == neutral is probably the most ignored item in RFC 
4408.  It simply doesn't help to write in an RFC what receivers HAVE to do.  
They won't.

> have no published record.

People have different opinions on this.  You aren't the only one that thinks 
that.

> Failure reason is not given or is simply ambiguous.

In the cases you've given, it's been you that lumped them together despite 
clearly identifiable unambiguous reasons for failure.  I haven't seen a lot of 
trouble with this, so I'm not sure your generalizations are correct.

>    first time the message is received, but accept it the second time.

Users don't generally see the 45X message.  It only goes in the mail log.  
After some period, users might get warned.  In the case of postfix, the MTA 
with which I'm most familiar, the default is 4 days.  Deferring once only 
helps if the sender is reading mail logs closely.  Senders that do that are 
not, in my experience, the ones likely to have broken setups.

It's true that a temperror can be caused by broken DNS at the receiver.  I 
still don't see any examples of a case where anything other than the sender 
screwing up can cause a permerror.

I think you need to go back and reconsider again as you're still mixing 
temperror and permerrror.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Aug 2012 02:14:48 -0400

On Wednesday, August 01, 2012 03:09:37 PM Wayne Doust wrote:
> (~ALL) to give the appearance of a strong exclusive policy allowing for
> rejection, but then intentionally embeds an invalid syntax error. If we
> relaxed the protocol with an PERMERROR fallbacks to a NEUTRAL result
> (possibly overriding the DOMAIN policy) then it become a potential security
> loophole to preemption, skipping or indeterminate (no result) condition,
> and the mail is accepted (after perhaps it passes any other testings, if
> any). -----
> 
> 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.
> This is OT, but the only case where I see this applies is publishing a
> costly SPF record and then spamming possibly causing DOS.
> The grammar for SPF is quite strong. However IME, there are mail scanning
> "devices" that have choked on proper SPF entries.

Yes.  There is buggy software on the Internet.  This is not a surprise.

Part of what we're trying to do in this working group is to make RFC4408bis 
more useful for producing more correct implementations that RFC4408.  Improved 
clarity is a good thing.

There will still be bugs.  We can't design protocol around bugs.

Scott K