On Thu, Aug 19, 2004 at 11:23:00AM -0700, Mark C. Langston wrote:
On Thu, Aug 19, 2004 at 08:18:00PM +0200, Koen Martens wrote:
Grin,
I got your point all along.
I was just trying to get some discussion going by elaborating a bit, but so
far only Mark has joined in and he hasn't really answered the problem with
sub-domaining if you ask me.
I guess this means a.example.com is just screwed if b.example.com
misbehaves..
Not at all. Take the following example, straight from GOSSiP:
Assume a ham-sender connects from <some IP>, using the address
foo(_at_)a(_dot_)example(_dot_)com(_dot_)
Assume a spammer connects from <the same IP>, using the address
bar(_at_)b(_dot_)example(_dot_)com(_dot_)
In GOSSiP, the identity for the hammer is a.example.com:<IP>. The
identity for the spammer is b.example.com:<IP>.
Two separate identities, two separate reputations.
There has been discussion in the past few days about data aggregation
across identities, but I think everyone agrees that there may be as many
dangers as benefits to such aggregation. Therefore, there won't be any
such aggregation in the initial release, and if and when that
aggregation is added, it will require significant testing to ensure the
good doesn't get lumped in with the bad.
So, only good domains build a good reputation. Bad senders, the example
I had was 'a.spammer.com' 'b.spammer.com' 'c.spammer.com' etc.., will
just change their identity continuously as to avoid building a bad reputation.
So unless everyone without a good reputation (that includes, next to bad
reputation, no reputation) is being rejected, the scheme will be
circumvented by spammers in no-time, no?
So again, we have a problem that to avoid things like this, the identity
should be spammer.com, which is bad for the a.example.com example. And
the other way around, for a.example.com's benefit, the entities should be
a.example.com and b.example.com, not example.com, but that opens up the
gates for spammer.com...
Maybe you need some sort of bayesian network of some kind here, where
the bad reputation perculates up to domain one level up. It can then be
cancelled out by good reputation, but this still leaves the problem that
a.example.com might not have a choice but example.com of which say 90%
of the domains have a bad reputation.
Koen
--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/