--On 20 January 2009 21:07:48 -0500 Rich Kulawiec <rsk(_at_)gsp(_dot_)org>
wrote:
On Tue, Jan 20, 2009 at 01:40:59PM +0000, Ian Eiloart wrote:
I disagree fundamentally about the centralise reputation system.
Every attempt made at these thus far has been an absolute failure.
(See "TrustE" and "Habeas", for example.) I can't think of any
reason why the outcome will change if the experiment is run again.
BTW, I don't consider DNSBLs and RHSBLs to be reputation systems.
That's not a knock on them: on the contrary, they are, by an enormous
margin, the most effective anti-spam measures we have. But they're
not trying to be reputation systems, and they don't need to be.
I guess that depends on the nature of the RBL. Some of them really are
reputation systems. IP addresses get listed because someone has seen spam
coming from them. Spamhaus' SBL is an example. If you don't agree that
that's a reputation service, please explain.
Others aren't, Spamhaus' Policy Blocklist, for example is a list that IP
address owners have added. I'm not sure why they don't just firewall the
hosts, though. Perhaps so that some can be whitelisted. Of course each site
can have its own local reputation policy that would trump a centralised
reputation server - that's what whitelisting is about.
However, currently it's hard to know what to whitelist. There's only one
widespread, easy to use mechanism for managing information about which IP
addresses an organisation is likely to send messages from - that's SPF. OK,
so if you wanted to be sure to get mail from me, you could whitelist my /24
address block, but are you sure that I'd keep you updated if we outsourced
our email?
And, you can't reliably whitelist my domain, because spammers could then
easily bypass your filters. If I had a domain whitelist for my site, then
spammers would be on a pretty good bet that forging any .ac.uk address
would make their email more deliverable. It would also make it more likely
to be read. So, I can't whitelist those domains unless the email is coming
the right IP addresses. Only SPF can tell me that.
The key thing is that you can't use any kind of email domain or email
address based reputation system unless you have evidence that the sender
address isn't forged.
I disagree, because I don't really *care* whether mail is forged or
not, and regard that as largely an insignificant problem, when compared
to the monumental problem posed by spam. (Morever, for most purposes, it
doesn't matter: when a known spammer domain shows up, reject the message.
If it was really from them: correct decision. If it was from someone
dumb enough to forge a known spammer domain: still correct.)
Yes, the problem of course is when a spammer forges a domain that I'd like
to trust. If I'm filtering mail from the domain of my chief funders, then
false positives can be really painful. If I whitelist them, then spammers
can easily bypass my filters. So what I'm discussing IS all about forgery.
I think perhaps I have this viewpoint because my focus is on my biggest
(ongoing) problem: what to do about the 99% of incoming mail that needs
to be rejected outright before it can get anywhere near a user.
You mean you want to know how to identify it? Or what to do with it after
you've identified it?
Now, if
I get past that and focus on the remaining 1% that I'd actually like to
allow in, *then* I can see some reason to think about possible problems
with that: authentication, integrity, privacy, etc.
---Rsk
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
--
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg