Mailing List Archive

Calling RFC lawyers: DNS limits
The following should give permerror when connecting from 1.2.3.5:

v=spf1 a a a a a a a a a a ip4:1.2.3.4 a

BUT, should the result be pass or permerror when connecting from 1.2.3.4?
(I.e., is counting done before evaluation?)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
In <Pine.LNX.4.44.0610161642010.1445-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> The following should give permerror when connecting from 1.2.3.5:
>
> v=spf1 a a a a a a a a a a ip4:1.2.3.4 a
>
> BUT, should the result be pass or permerror when connecting from 1.2.3.4?
> (I.e., is counting done before evaluation?)

(note: I counted 10 'a' mechanisms before the ip4: mechanism.)

I believe that the result should be Pass. Similarly, if you replaced
the ip4: mechanism with an all: mechanism, the result would also not
be PermError.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
On Monday 16 October 2006 16:44, Stuart D. Gathman wrote:
> The following should give permerror when connecting from 1.2.3.5:
>
> v=spf1 a a a a a a a a a a ip4:1.2.3.4 a
>
> BUT, should the result be pass or permerror when connecting from 1.2.3.4?
> (I.e., is counting done before evaluation?)

No because in some cases you can't count until you evaluate. RFC 4408
supports this...

4.6. Record Evaluation

...Implementations MAY choose to parse the entire record first and
return "PermError" if the record is not syntactically well formed....


10.1. Processing Limits
...If this number is exceeded during a check, a PermError MUST be returned....

The part of the RFC that talks about MAY parse the entire record first (4.6)
is specific to syntax errors. Processing limits is a different, non-syntax
issue. Processing limits (10.1) specifically talks about limits during a
check.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
On Monday 16 October 2006 16:54, Scott Kitterman wrote:

> No because ...

meaning no it shouldn't be a permerror.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
Scott Kitterman wrote:

> The part of the RFC that talks about MAY parse the entire record first (4.6)
> is specific to syntax errors. Processing limits is a different, non-syntax
> issue. Processing limits (10.1) specifically talks about limits during a
> check.

Convincing. Nice test case. It's fairly easy to get this detail wrong.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
On Mon, 2006-10-16 at 16:54 -0400, Scott Kitterman wrote:
> No because in some cases you can't count until you evaluate. RFC 4408
> supports this...

I disagree.

> 4.6. Record Evaluation
>
> ...Implementations MAY choose to parse the entire record first and
> return "PermError" if the record is not syntactically well formed....
>
>
> 10.1. Processing Limits
> ...If this number is exceeded during a check, a PermError MUST be returned....
>
> The part of the RFC that talks about MAY parse the entire record first (4.6)
> is specific to syntax errors. Processing limits is a different, non-syntax
> issue. Processing limits (10.1) specifically talks about limits during a
> check.

But the wording of limits "during a check" doesn't imply to me that you
have to accummulate and apply the limits only at the specific points in
which you are evaluating whether each mechanism matches. It simply
means (as I read things) limits encountered within the check_host
function itself.

This viewpoint is supported by usage of the word "check" in the text of,
among other places, Sections 2.2 and 2.4:

2.2. The MAIL FROM Identity
...
SPF clients check the "MAIL FROM" identity by applying the
check_host() function to the "MAIL FROM" identity as the
<sender>.

2.4. Checking Authorization
...
When a mail receiver decides to perform an SPF check, it MUST
use a correctly-implemented check_host() function (Section 4)
evaluated with the correct parameters

So when 10.1 says:

10.1. Processing Limits
...
SPF implementations MUST limit the number of mechanisms and
modifiers that do DNS lookups to at most 10 per SPF check,
including any lookups caused by the use of the "include"
mechanism or the "redirect" modifier. If this number is
exceeded during a check, a PermError MUST be returned.

I read that as meaning that if you have a single record with eleven "A"
mechanisms, then since from the very beginning you already have a record
with more than (10 mechanisms that do DNS lookups) within a single
(parent) execution of check_host, that an implementation can give a
PERMERROR without any need to actually evaluate any of those "A"
records.

That is, because there are more than 10 mechanisms that do DNS lookups
according to the instructions in the record, you must PERMERROR once
you've realized that fact. The fact that you might have realized it
before you've actually done more than 10 DNS lookups is a separate
issue, (though possibly some implementations might not do the count
until they've fully evaluated that many mechanisms up to that point.)

Or for a second example: If you have a record that has an include:
followed by two "A"'s, where the included record has eight "A"'s, the
limits within the recursed check_host would trigger the outer
check_host's processing limits, without requiring the two "A"'s in the
top record to be evaluated.

So in those two cases, I don't see any requirement to actually evaluate
those A: records.

--
Mark Shewmaker
mark@primefactor.com

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
On Sat, 28 Oct 2006, Mark Shewmaker wrote:

> On Mon, 2006-10-16 at 16:54 -0400, Scott Kitterman wrote:
> > No because in some cases you can't count until you evaluate. RFC 4408
> > supports this...
>
> I disagree.

Neither side has convinced me totally. The test suite carefully avoids
testing exactly *when* the limit is detected - it only checks that
the limit is detected.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
On Mon, 30 Oct 2006 10:19:02 -0500 (EST) "Stuart D. Gathman"
<stuart@bmsi.com> wrote:
>On Sat, 28 Oct 2006, Mark Shewmaker wrote:
>
>> On Mon, 2006-10-16 at 16:54 -0400, Scott Kitterman wrote:
>> > No because in some cases you can't count until you evaluate. RFC 4408
>> > supports this...
>>
>> I disagree.
>
>Neither side has convinced me totally. The test suite carefully avoids
>testing exactly *when* the limit is detected - it only checks that
>the limit is detected.

Ultimately that's the right answer.

The test suite should push towards consistent results among the different
implementations for interoperability.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Calling RFC lawyers: DNS limits [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Shewmaker wrote:
> On Mon, 2006-10-16 at 16:54 -0400, Scott Kitterman wrote:
> > No because in some cases you can't count until you evaluate. RFC 4408
> > supports this...

It can be deduced from the spec that processing limits are NOT meant as
some sort of "advanced syntax check" that must be done during parsing and
before evaluation. Here's how:

10.1/6 says:

| SPF implementations MUST limit the number of mechanisms and modifiers
| that do DNS lookups to at most 10 per SPF check, including any lookups
| caused by the use of the "include" mechanism or the "redirect" modifier.
| If this number is exceeded during a check, a PermError MUST be returned.
| [...]

If that meant that processing limits had to be checked before evaluation,
then the limits could NOT cover any mechanisms encountered via "include:"
and "redirect=". Furthermore, the second sentence would then have read
instead:

| If this number is exceeded in an SPF record, a PermError MUST be
| returned.

But it doesn't. So the processing limits clearly apply during evaluation
only, not during parsing. Thus, Stuart's initial example _can_ return
"Pass".

> But the wording of limits "during a check" doesn't imply to me that you
> have to accummulate and apply the limits only at the specific points in
> which you are evaluating whether each mechanism matches.

To me it does. Try figuring how the sentence would have been worded if
_your_ semantics had been intended. Certainly not as it has been. But
this really only touches the second sentence of 10.1/6. The "include:"
and "redirect=" interaction with the processing limits makes it pretty
clear that you cannot check the processing limit before evaluation.

> [...]
> Or for a second example: If you have a record that has an include:
> followed by two "A"'s, where the included record has eight "A"'s, the
> limits within the recursed check_host would trigger the outer
> check_host's processing limits, without requiring the two "A"'s in the
> top record to be evaluated.

But the _original_ record would have to be evaluated in order for the
"include:"d record to be reached (and parsed) in the first place.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFW1mxwL7PKlBZWjsRAnEjAJwKGnIAkrNpaLh4WvHGGdAxt6wn+wCgg+eO
XwgJ3jDB3CkbyjE8GSsE5ww=
=lrhO
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007