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@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked.