Subject: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits

From: "Wayne Doust" <[email-masked]>
Date: Wed, 12 Sep 2012 10:57:08 +1000

> My initial thought for the start of this message was to quote this
section as well.  Right to left parsing with errors only if the error
condition is triggered is a recipe for what appears to be random
failures when a record works some times and not others.
> In any case prohibiting total record error detection and requiring
left to right processing would be a substantiative change to the
protocol.  I don't think it would be a good one either.

------

Personally, I think the spec should mandate one way or the other.
Otherwise we have a situation where the actual result will depend upon
the implementation - leaving no consistency. A publisher can say their
SPF record is okay because they tested it with a validator, but find it
Permerrors (possibly leading to rejection) elsewhere according to the
method implemented. At least one implementer checks the complete record
first.

Admittedly, this is usually (but not always) related to a mistake in the
spf record. Despite this, a consistent result should be returned across
the board. For a classic example of this, look at the spf record for
Hilton.com. This record contains two "-all" entries. Scanning
sequentially through the record will always work as processing stops at
the first "-all", however pre-scanning will always result in a
permerror.

I'm actually not committed to either method, however I think it should
be consistent. Testing Hilton.com against SK's validator will pass the
record whilst some in-the-wild implementations do not.

Regards,

Wayne

---

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

> the first "-all", however pre-scanning will always result in a

Why is a double "-all" a permerror?  There's nothing in RFC4408 that
forbids it.  It's like putting "exit" in a shell script or "return" in
a C function before you reach the end; there's nothing syntactically
wrong with it, but it renders part of the whole thing dead.

Settling on "to pre-scan or not to pre-scan" won't solve this problem.
 It's a bad implementation.

-MSK

---

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

On Wednesday, September 12, 2012 10:57:08 AM Wayne Doust wrote:
...
> method implemented. At least one implementer checks the complete record
...

You're solving the wrong problem here.  Since RFC 4408 says that no matter how 
you do it, errors must be detected in all cases, you have consistency.

The problem is that virtually no SPF record validators include processing 
limits in what they validate.  Mine does, but the reason I set it up in 2006 
was because none of the ones that existed at the time did.  I don't have any 
firm recollection of any appearing either (but I may be wrong as it's not 
something I pay a lot of attention to).

The problem is incomplete validation caused by validators that don't check all 
aspects of validity.  Fixing the spec, won't fix that.

Scott K

---

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

>  It's a bad implementation.

There are lots of ways to write dumb records that are syntactically valid.  
One common one is to use the MX mechanism and then put the hostname of the MX 
host when what's wanted is either A and the hostname of the MX host or MX and 
the domain that the record is for.

We can't design a spec that precludes syntactically valid, but operationally 
incorrect records.  Tools to support SPF record validation however, can, and 
should, provide useful advice when they encounter something that is clearly 
not useful (mine gives a warning on the empty MX lookup problem I described 
above, but not double ALL (I confess to having never seen that one before)).

Scott K

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 12 Sep 2012 13:34:12 +1000

> You're solving the wrong problem here.  Since RFC 4408 says that no
matter how you do it, errors must be detected in all cases, you have
consistency.

I think it is ambiguous. In-the-wild implementations seem to support
that notion. Should the entire record be scanned first or not? My
personal opinion is that it shouldn't. I'm more concerned that the spec
should mandate the circumstances under which permerror results are
generated.

In the case of "v=spf1 a mx include:example.com -all". If I publish this
record because occasionally an example is sent from example.com with my
MAIL FROM: domain. And example.com decides to go from 8 to 10 DNS
lookups after publication of the SPF record, will I permerror on every
single email? Or only on the those from example.com (or those that
should be trapped by -all)?

Evaluating from L to R will give a pass for most email. Pre-evaluating
will report permerror.

> The problem is incomplete validation caused by validators that don't
check all aspects of validity.  Fixing the spec, won't fix that.

Very True.

However, consistency in response is what I'm talking about.

Regards,

Wayne

---

From: SM <[email-masked]>
Date: Tue, 11 Sep 2012 22:26:54 -0700

>Evaluating from L to R will give a pass for most email. Pre-evaluating

 From Section 4.6.2 of RFC 4408:

  "Each mechanism is considered in turn from left to right.  If there
   are no more mechanisms, the result is specified in Section 4.7."

 From Section 5.1:

   'The "all" mechanism is a test that always matches.  It is used as the
    rightmost mechanism in a record to provide an explicit default.

    For example:

       v=spf1 a mx -all

    Mechanisms after "all" will never be tested.  Any "redirect" modifier
    (Section 6.1) has no effect when there is an "all" mechanism.'

The SPF record for hilton.com is below:

"v=spf1 include:imx.hilton.com a:ctg1.hilton.com a:ctg2.hilton.com 
a:ctg3.hilton.com a:ctg4.hilton.com a:ctg5.hilton.com 
a:ctg6.hilton.com include:spf.messagelabs.com -all" " 
mx:hiltonint.com ip4:62.95.91.206 ip4:62.95.91.207 
a:mail.hiltonres.com a:mail2.hiltonres.com ip4:192.251.124.90 -all"

The syntax seems correct.

Regards,
-sm

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 12 Sep 2012 15:38:52 +1000

"v=spf1 include:imx.hilton.com a:ctg1.hilton.com a:ctg2.hilton.com
a:ctg3.hilton.com a:ctg4.hilton.com a:ctg5.hilton.com a:ctg6.hilton.com
include:spf.messagelabs.com -all" " 
mx:hiltonint.com ip4:62.95.91.206 ip4:62.95.91.207 a:mail.hiltonres.com
a:mail2.hiltonres.com ip4:192.251.124.90 -all"

> The syntax seems correct.

The syntax is correct. Evaluating from L-R will always terminate in the
first "-all", so the record will always be valid. Pre-evaluating
however, will exceed the DNS lookup limit:

include:imx.hilton.com 		1
a:ctg1.hilton.com 		1 / 2
a:ctg2.hilton.com 		1 / 3
a:ctg3.hilton.com 		1 / 4
a:ctg4.hilton.com 		1 / 5
a:ctg5.hilton.com 		1 / 6
a:ctg6.hilton.com 		1 / 7
include:spf.messagelabs.com 	2 / 9
-all 					0
mx:hiltonint.com 			1 / 10
ip4:62.95.91.206 			0
ip4:62.95.91.207 			0
a:mail.hiltonres.com 		1 / 11 - permerror
a:mail2.hiltonres.com 		1
ip4:192.251.124.90 		0
-all					0

---

From: "Wayne Doust" <[email-masked]>
Date: Wed, 12 Sep 2012 16:01:00 +1000

> Off the top of my head I don't see anything syntactically wrong with
the third and fifth ones.  They should get processed and then fail of
their own accord.

Third one has whitespace where it shouldn't be. You're right about the
5th one. I'll have to look closer at why it threw a permerror.

Back on topic:

The point of the proposed text is to make it clear to implementers that
whilst pre-processing for syntax errors may be valid, pre-processing for
DNS lookups is definitely not valid. 

Agree / Disagree ?

The example I have given is a real (if bizarre) one. However this could
more commonly occur with include: statements.

Regards,

Wayne

---

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

> DNS lookups is definitely not valid.

I think I agree.

To be precise, returning "permerror" based solely on the fact that the
SPF policy might (or even will) exceed the DNS lookup counts is
probably not valid.  I might have 30 mechanisms listed, but if on
evaluation it never gets past the fifth one, what's the harm?

-MSK

---

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

> more commonly occur with include: statements.

In the double "all" case, it's not an error, because terms to the right of the 
all don't get processed (except "exp"), so there's no case where the extra 
lookups can get triggered.

While I think consistency demands raising an error if there are too many 
lookups in a record, I agree it should not be required to follow includes: to 
find out if there are too many (it would be distinctly odd to do a DNS lookup 
as part of the protocol meant to minimize DNS lookups).

Fundamentally a record that causes a permerror has an error and I think that 
it should be detected.  As a matter of efficiency and limiting impacts to DNS, I 
don't take it as far as following include:.  I think that the current language 
is fine.

Even in the Wayne's case once the implementor read RFC 4408 and decided they 
should do what RFC 4408 said, rather than trying to be smarter than RFC 4408, 
they got to a consistent result.  The problem here was not that the spec was 
vague, but that the implementer didn't like/agree with what it said.  Those 
kinds of problems we'll never solve.

Scott K