At 04:32 PM 3/29/2005 -0500, Scott wrote:
>>Regardless of the potential for increased effeciency, I think that a
>>significant change like this is going to have a hard time getting traction
>>in the market. If this sort of approach will appeal to people,
>then perhaps
>>we ought to concentrate in the near term on selling Frank's slightly less
>>efficient approach since it's fully compatible with the current syntax.
>
>The masks will be generated automatically by a compiler. The
>compiler will
>get market traction because it is easier and more fun than
>creating records
>with a text editor, and it will be a webtool or a free download, not
>requiring any DNS patches, etc.
>
>The "include:not.me" syntax, as I understand it, can never provide a
>one-shot DNS response, and once people start using it, we will never get
>rid of it.
>
>Spammers are not going to give up their lucrative business without a
>fight. I can easily imagine them turning up the volume by a factor of 10
>or even 100. I like the idea of having as the final defense, a
>"one-query"
>mode where 90% of the legitimate mail gets through, and the spammers are
>rejected at a cost not much more than they spend in sending their sh*t.
Maybe the compiler could have an option to spit out either m= or
"include:not.me".
Feels like a kludge, especially if it encourages people to start writing
masks manually.
"include:not.me" can be deployed today.
The "not.me" syntax will need a few months to write, test, and deploy the
compiler. The m= syntax might take a little longer for SPF checkers to be
upgraded. The not.me syntax requires a minimum of two queries. The m=
syntax can provide a one-query authentication check in the critical
situation, a DoS attack. So we need to weigh the urgency of getting this
widely deployed vs a better long-term solution.
I'm leaning toward the better long-term solution. I don't see the urgency
for deployment. It will be a long time before the whole world is using
SPF. I do see some urgency in responding to the DNS worries, and getting
this into the draft.
We could also respond by formalizing the "one-query defense mode" for
receivers, and urge all senders to reduce their SPF records to one
query. The example of rr.com shows how even a really large, geographically
dispersed domain can do this. Any domain that has a more-than-one-query
record might get some temporary failure notices during a DoS attack on one
of their recipients or forwarders.
Do we need both a defense mode and an m= shortcut? I guess that depends on
how many domains truly need more-than-one-query SPF records.
-- 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 *
************************************************************ *