Re: RE: rr.com and SPF records

Mark,

I really like your idea to solve the limiting problem for larger 
configurations.  The only issue I see is potential abuse by certain 
elements not interested in seeing SPF succeed.  Given the potential for a 
geometric growth in DNS requests if your plan was implemented from people 
attempting to abuse the system, I'm not clear on how one could protect the 
system from abuse in its current state.
I suggested a while back on the list that a trusted registry of SPF domain 
adopters may be in order to solve some problems that I could envision 
happening back then.
In this case, I think we could even avert some of Radu's and David's DNS 
access concerns with such a registry because the registry itself could 
serve as a caching center for first SPF requests as well as offer an 
indication of the conditions an SPF checker could expect to encounter.
In other words, is Domain.TLD going to provide a properly formed SPF record 
when you approach its DNS servers?  Even better, if the domain is not part 
of the registry, don't go annoying the DNS administrator for Domain.TLD by 
asking for their TXT records that won't be there and creating junk SPF UDP 
request traffic.  I could see a series of SPF answers for registry members 
to handle such situations as known problem SPF records that are either 
innocent or not so innocent.  I can see ways that this first barrier could 
end up being quite useful to limit abuse of the system in general.  Unknown 
or non-participating SPF sites could end up with a "~" style response, 
while a known non publishing might end up with a "+" - there are obviously 
a great many possible uses including proactive support for SPF publishers 
who have made innocent configuration errors as well as an easy vehicle to 
update SPF registry participant publishers on changes to standards, new 
features, etc.
I think that using a central registry could also off load some of the 
burden problems we have seen discussed in this thread.
While introducing a central registry system to SPF may offer some 
challenges to adoption (complexity reduces interest - a valid argument), 
the gains in implementing such a vehicle may outweigh the downside 
issues.  As to making it impervious to attack, nothing ultimately is, but 
sites like Spamhaus.Org have faced and conquered those challenges for the 
most part.  Given SPF's charter, I would suppose that it is likely 
Spamhaus.Org might want to offer the registry operators some insights into 
how best to defend against very aggressive attackers.
I would be interested in reading what others might think of this idea.

Best,

Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/



At 12:12 PM 3/22/2005, you wrote:
> On Sat, Mar 19, 2005 at 09:27:54AM -0500, Scott Kitterman wrote:
> > If other records that I include count against MY limit, I can go from
> > a good record to a broken one in no time.  The problem with overall limits
> > is that they cross administrative boundaries.
>
> Then what if they didn't count against your limit?  Would that both work
> and protect against DOS attacks? (Say the recursively-included records
> counted up separately.)
>
> For instance, the rules could be:
>
> 1.  A limit of ten lookups at the level of the initial record itself.
> 2.  A limit of ten lookups in any top-referenced record downwards.
>
> This would mean that vanity domains could include major ESP's without
> worrying about triggering the limit themselves, but ESP's would still
> have to make sure they were well within the limits.
>
> (Meaning that Road Runner shouldn't depend on these limits for the
> main rr.com domain.)
>
> It's just like Wayne's latest algorithm, except that the top-most
> record is counted by itself, and each top branch formed from the
> top record would be counted separately.
>
> So if your record had a total of ten includes or redirects and nothing
> else, your record itself wouldn't trigger any limits, but any one of
> the included records could.
>
> Would that help things without causing more problems than it solves?
>
> --
> Mark Shewmaker
> mark(_at_)primefactor(_dot_)com
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
> 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