isn't "...isn't perfect, but it's something now"

Fri Aug 13 00:37:14 UTC 2004

DC> Date: Thu, 12 Aug 2004 00:17:47 -0700
DC> From: Dave Crocker

DC> [ snip my "SPF isn't perfect but is something now" ]
DC>
DC> This is a very popular view these days.

One only need to read a few NANOG-L analogy wars to understand
why.  Consensus?  Ha.  Majority?  Yeah, right.  I'd much rather
have a system that is better thought out yet would require bigger
changes.  Good luck getting that to fly; until then, I'll settle
for incremental improvements.

DC> However there are some fundamental problems with it:
DC>
DC> 1. It mistakes activity for progress.

Let's define "progress" as "improvement beyond the status quo".
I hinted at that, but perhaps need to spell it out explicitly.

DC> 2. It ignores opportunity cost, diverting energies to efforts
DC>    that are likely to have no effect on spam rather than
DC>    allocating those resources to basic improvement in the
DC>    service.

I've suggested authenticated SMTP with restricted sender
addresses a la SAV.  There's something that would have real
effect on joejobs.  Are people implementing it?  Or are they
adopting SPF?

Note that auth/restrict and SPF are somewhat orthogonal.  The
former relies on the sender operating in good faith, whereas the
latter requests the receiver do so.

However, I don't see as many drawbacks with auth/restrict.  Few
people need more than a few addresses, or perhaps domains, so
there's not much admin headache.  Blocking the problem at the
source saves others the pain.  (Remember blocking based on sender
address/domain, before forged spam caught on?)

You tell me why something with intraprovider implementation, real
benefits, and lower side effects isn't flying.  I agree that
energies are misdirected... so how does this get changed?

DC> 3. It ignores the difficulties with administration and
DC>    operation of the mechanism, as it scales, such as its
DC>    Procrustean limitation of usage scenarios that are
DC>    reasonably supported.

1. See above chunk
2. Let's hope nobody uses SPF as a definitive blocking mechanism
3. Prepare for "SPF override" whitelists.

DC> 4. It treats a short-term mechanism as if it had long-term
DC>    benefit; yet modification of a global infrastructure is
DC>    always and only subject to long-term processes.
DC>
DC> If SPF is wonderful, it had better satisfy a higher criterion
DC> than that it "isn't perfect, but it's something now".

I believe I said "I'm trying to decide if SPF is good".  That's
hardly calling it "wonderful".

Strict SPF will break popular greeting cards, eBay "send to a
friend", Webmail, autoforwards, and many other things that "just
work" now.  Hence why I view SPF as a handy input -- much like we
use DNSBLs as inputs as opposed to authoritative "do not accept
mail" rules.

The fact remains that SPF *does* provide additional intelligence
in a standard method amenable to automated processing.  I call
that an improvement from a status quo, which translates to
progress.

Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_________________________________________________________________
DO NOT send mail to the following addresses:
davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net
Sending mail to spambait addresses is a great way to get blocked.