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

From: Arthur Thisell <[email-masked]>
Date: Wed, 12 Sep 2012 05:10:38 -0700 (PDT)

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

The harm in having too many mechanisms, even if they never get evaluated, is basically the same as having syntax errors, even if they never get evaluated.

Many script-type languages (unix shell scripts, JCL, etc.) don't detect syntax errors until they encounter them.  Most other computer languages will complain.

In the case of hilton.com, I could see the gut feel being that the extra mechanisms should be ignored, but in other cases, I could see the gut feel being that you should give consistent results, rather than authorized results sometimes getting permerror a small percentage of the time.

In particular, is really common to hit the "end" of an SPF record.  Having all unauthorized mail evaluated to permerror is not what people will expect.

I suspect that in the wild, there are, indeed, implementations that do it both ways.

---

From: Stuart Gathman <[email-masked]>
Date: Wed, 12 Sep 2012 14:49:22 -0400

> In particular, is really common to hit the "end" of an SPF record.  Having all unauthorized mail evaluated to permerror is not what people will expect.
The problem is that SPF policies form a tree, with include and 
redirect.  Determining ahead of time whether the Dos limit might 
possibly be exceeded (for some connect IPs) requires fetching all the 
referenced SPF records - whether they are needed for this particular IP 
or not.   This makes any Dos considerations worse.

A similar problem comes up with include and redirect.  The current SPF 
record might be syntactically valid, but some included record might not 
be.  It would be counterproductive for an implementation to actually 
fetch the entire tree of SPF records in order to check them all for 
syntax errors.

If you want consistent results, simply require that DoS limits be 
reported at the first mechanism that exceeds the limit.  This will 
always give the same result for the same connect IP.

As for syntax errors, only the SPF record currently being evaluated 
should be fully parsed for syntax errors.  It is counter productive to 
prefetch the entire tree.  While this is obvious from a common sense 
standpoint, if there is any confusion, 4408bis should make this explicit.

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Sep 2012 15:06:50 -0400

Stuart,

One way to address this or add some automated "learning" is to perhaps 
use these limits or permerrors as Temporary "Greylisting-like" Rejects 
but over a 1-2 day period with the HOPE the remote operator (if its a 
real good person) will notice and take a look at its logs and see:

   451-Your SPF is failed with a DNS Lookup limit exceeding 10.
   451-Please adjust your SPF record so that less lookups are required.
   451 This transaction will be expired in 2 days.

I can see a DNS occurring, but it will need a serious tracking to 
limit the ACCEPT+FORCE BOUNCE per domain occurrence.

Stuart Gathman wrote:
>> The harm in having too many mechanisms, even if they never get 
>> evaluated, is basically the same as having syntax errors, even if they 
>> never get evaluated.
>>
>> Many script-type languages (unix shell scripts, JCL, etc.) don't 
>> detect syntax errors until they encounter them.  Most other computer 
>> languages will complain.
>>
>> In the case of hilton.com, I could see the gut feel being that the 
>> extra mechanisms should be ignored, but in other cases, I could see 
>> the gut feel being that you should give consistent results, rather 
>> than authorized results sometimes getting permerror a small percentage 
>> of the time.
>>
>> In particular, is really common to hit the "end" of an SPF record.  
>> Having all unauthorized mail evaluated to permerror is not what people 
>> will expect.
>>
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS