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