On Sun, Nov 19, 2006 at 12:45:48PM -0400, Marc G. Fournier wrote:
> "SpamAssassin 3.0 supports SPF to detect and penalize header forgery."
If your main goal is to reduce spam, _point finale_, then SPF will
help. If your main goal is to reduce spam _while not causing
unwanted side-effects_, then spamassassin's approach above does not
meet the goal.
The problems with SPF are subtle, and by no means apparent at first
glance. SPF _looks_ like a good thing, if only everyone plays nice.
As a matter of fact, though, it causes damage to the global DNS, and
doesn't actually solve the problem it should given the way people
actually use email. Moreover, the "interim" measures that people
have put into the protocol for transition purposes turn out to make
it worse than useless: all the cost has to be paid, and none of the
putative benefit is delivered. Even DKIM is a better answer than
this (and I'm no fan).
Compare this to the way MySQL delivers the enum data type. "Causes
no damage. Just an extension," some say. But the actual effects in
the field are different: it causes sloppy, poorly generalised design,
and miseducates people about how SQL works. It shouldn't be used,
because there was already a good, more general way to do the same
thing under SQL. In my view, SPF is the same sort of damage, and
shouldn't be used.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie