Re: RE: rr.com and SPF records
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
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.
The Commerce Company - Making Commerce Simple(sm)
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?
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
please go to
|<Prev in Thread]
||[Next in Thread>
- RE: RE: rr.com and SPF records, (continued)
- Re: RE: rr.com and SPF records, Radu Hociung
- RE: RE: rr.com and SPF records, Scott Kitterman
- Re: RE: rr.com and SPF records, Mark Shewmaker
- Re: RE: rr.com and SPF records,
Commerco WebMaster <=
- RE: RE: rr.com and SPF records, Guy
- Re: rr.com and SPF records, Frank Ellermann
- Re: Re: rr.com and SPF records, Stuart D. Gathman
- Re: Re: rr.com and SPF records, Radu Hociung
- RE: Re: rr.com and SPF records, Guy
- RE: Re: rr.com and SPF records, Len Conrad
- RE: Re: rr.com and SPF records, Stuart D. Gathman
- Re: Re: rr.com and SPF records, Radu Hociung
- Magic 10 (was: rr.com and SPF records), Frank Ellermann
- Re: RE: rr.com and SPF records, william(at)elan.net