spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: PermError: Too many DNS lookups at Microsoft.com

2006-05-07 14:53:53

----- Original Message -----
From: "Julian Mehnle" <julian(_at_)mehnle(_dot_)net>

You are the guys that came up with artificial SWAG limit.

You still haven't answered my questions what specific value you would have
preferred, and what empirical methodology you would have used to determine
it.

I believe I did.  You just didn't understand I believe.

o Recursion, Redundancy and  Timeouts.

First, recursive limit is a must.  The original idea was ok, but too high in
my opinion.  It was set at 20 and that was really asking for too much for a
domain to construct.  Plus emperical data showed the abuse was realized with
recursion at the 2nd or 3rd pass.   I suggested a lower number but there was
no feel for what that value was.  5-10 is probably sufficient for recursion.
The main point here is that even if you think there is a overal DNS lookup
limit, it is a separate limit from that of a recursion limit:  For example:

        RecursionLimit    10          # include, redirect
        DNSlookupLimit  30         # mx, ptr, a

And again, that is just a "recommendation."   The error in the specs is that
its locked itself at 10.    All the specs needed to do is make the issue
aware and make it a receiver policy and we SPF vendors and/or library
writers will handle it from there.   A future BCP can come up witih a
recommended value.

Second, you need to track redundancy, one form is recursion but its more
about caching (duplicate names).  DNS caching is important.  I don't think
the libraries have caching with its direct DNS protocol lookups.  For
implementations that use the OS DNS clients, you have caching. So it is less
of an issue for them.

Third,  the SPF system should definitely have lookup time limits.  This is
important if only for one reason, SPF works best as part of a dynamic SMTP
system.  So inherently, you have a 5 minute timeout on a call out response.
But that is the the theoritical top boundary value.  Not one I would
recommend for a socket response.   I believe the specs says 20 seconds.  I
wasn't sure of that is for the total SPF processing.    If so, again, that
is an artificial limit. 30 is the typical socket timeout value most commonly
used.     But you can't get too locked in because in general, this typically
means there is a DNS problem somwhere.

All in all, these are implementation issues and the best the RFC can do is
give quidelines to work with.    The mistake here is the "Must limit to 10"
semantic.    It was taken as a rule, implemented and now you have new
PERMERRORS for transactions that never had this problem.

Does it say the domain SPF record is probably poor?  Probably, yes, I agree,
but I don't think you can use verifiers to enforce "poor" records.    If it
was syntaxtically incorrect or had unreasonable recursion and redundancy,
that would be a different issue.

Look, SPFv1 has _just_ become final a week ago.  We actually might do what
you suggest, but you can't expect us to have asked implementors to adapt
to whatever draft was current at the time we changed something in it.

Yes,  unfortunately,  the RFC was made official before this was caught.

I have a funny suspicion that once Microsoft is informed of this, even if
they realize they can define it better and do for the sake of RFC 4408, this
will cause some bad vibes because of the potential of other unknown sites
out there. unbeknownst to them, who may have the same issue once
implementators update to RFC 4408

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

<Prev in Thread] Current Thread [Next in Thread>