-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David
MacQuigg
Sent: Wednesday, March 30, 2005 1:53 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Standard Authentication Query
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.
I see it as a chicken and the egg problem. Which comes first? Until m= is
deployed among SPF checkers, it has no benifit and will make records longer
(more bandwidth, potentially more queries). So there is no incentive for
domain owners to put m= in their records (and some dis-incentive). I
haven't heard SPF checking program writers, other than Radu, leap up to say
they would implement this. Until m= starts appearing in records, there
really isn't a benifit to adding it.
If SPF wasn't already significantly deployed, I might be inclined to agree
with you, but I just don't see m= getting traction. If we had a script to
produce the "include:not.me" record in conjunction with the SPF record
compiler, we could use it to evangelize the few domains that have records so
complex that they would actually require this. If, in the mean time, m=
makes progress, they can switch.
SPF is in many respects a kludge (see Frank's DNS layering discussion for
example), but it's one that works reasonably well and is deployable today.
Periodically, people show up on this list and say, "No, don't use SPF, SPF
is bad. Use .... instead", but when I go figure out how to set up ...., I
find it isn't quite ready for a "Vanity" domain owner like me.
"include:not.me" may be a kludge too, but the fact that it can be used now
with no programs that need to be upgraded on anybody's mail servers is a
huge advantage. If you want to wait for the real deal, you wait may be very
long.
Scott Kitterman