At 12:48 PM 3/29/2005 -0500, Scott Kitterman wrote:
>>I'm, by and large, with Frank. We need to get the existing v=SPF1
>>documented in an experimental RFC and then move on to whatever comes next.
>>I do think that some added cautions wrt DNS loading and security risks may
>>be in order. I'm thinking that one over.
>
>I wouldn't slow down the progress on the SPF standard, but be prepared to
>make some changes to the parts relating to inter-operability.
>
But the current RFC effort is meant to describe the CURRENT practice. I
really think that for v=SPF1 we need to limit ourselves to codifying what's
in place. I wouldn't propose any changes to the current spec that directly
affect processing or creation of records.
Most of the potential changes can be done later at very little cost. The
one I worry about is the DNS query. SPF could be facing some very
difficult rework if the final standard mandates a one-packet
response. Also, I suspect the guardians of DNS at the IETF will be unhappy
that no changes were made to address their concerns.
As I understand it, Radu's mask proposal will allow almost all domains to
provide a one-packet response, even if the mask is only a rough
approximation to their actual server addresses. If this rejects 90% of the
forgeries, that may be good enough.
I can even see a large ISP clustering all their servers so their SPF record
might be nothing but a few masks. As long as spammers can't get access to
the addresses within the mask blocks, the masks alone are good enough.
A typical top record might look like this one for rr.com:
v=spf1
m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
-all
The ... redirects and such might never be needed if rr.com decides it can
clean out the zombies in each of those /24 blocks.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *