On Thu, Sep 23, 2004 at 02:54:34PM +0100, Tony Finch said:
>
> > > I suggest you read my analysis of the barriers to deployment of SPF
> > > http://www.imc.org/ietf-mxcomp/mail-archive/msg04462.html
> >
> > please read it very carefully,
>
> I wrote it!
>
> > it talks about sender-id (not spf) and altough this guy says he will not
> > implement spf, he does not give any reason for it.
>
> SPF is broken for the same fundamental reasons that Sender-ID is.
>
> > At the end this is only the opinion of a mail admin. Sure there are some
> > other people that think so, but this is far away from 'there is a
> > consensus the spf is broken'
>
> Unfortunately the lack of consensus is because the majority of anti-spam
> activists are unable to think for themselves, and just follow the first
> shiny thing that comes along without thought for the breakage it will
> cause.
I think people get confused about SPF / Sender-ID in regards to spam.
SPF will not stop spam. Spammers even use SPF now. SPF's main utility
is to reduce collateral spam/damage from malware or joejobs. It will not
eliminate it unless there is a 100% adoption rate (fat chance of that
happening.)
At best, information gathered from SPF can be useful as a spamassassin
score, but even that may not be valuable due to spammers also using SPF.
In short, SPF's real-world usefulness is just about zip.
This returns us to what works fairly well today: DNSBL's of known
spammer IP's, open relays, dynamic address space for dialup / cablemodem
/ DSL, etc., DNSBL's for content (URL's of spamvertized sites), and
traditional content analysis. If I turn off these checks, I get nearly
1000 spams a day - with these checks I'm lucky to get one. The known
false-positive rate (reported rejections) is quite low - about 1 per
week for a userbase of nearly 500 which I consder very acceptable.
SPF / Sender-ID / domainkeys / whatever is unlikely to do better than
what I (and many others) already do.
If we want to make sure that an email is really from sender X, a PGP or
S/MIME signature is really needed where the certificate / public key is
issued / stored by a trusted third party.
If the reasons for people looking at these alternative plans is spam
reduction, then these people really don't understand the problem. None
of these proposals will eliminate spam, or even reduce it.
