begin quoting Tom Gal as of Wed, May 18, 2005 at 07:34:00PM -0700: [attributions lost] > > Reputation-based systems fail in a lot of ways... mostly because they're > > either too limited to be useful, or you can game 'em. > > I see......and you analyze how users/spammers operate probably with > baysian and other statistical techniques, but just analyze the network > behavior as opposed to the message content.
Any statistical techniques used by anti-spammers can be used by spammers. So looking at content is fundamentally doomed, I think. (But that's just opinion.) > That's just another one of > those "part of a complete solution" deals that I'm sure down to use, > and probably could help, but won't be the answer, or help for > long....... Greylisting has the advantage is that it forces the spammer to use the same IP long enough to allow a honeypot-driven RBL to nail 'em. > > > > > I also am trying to think of the downside of changing the SMTP spec > > > > > to keep the connection open until AFTER the receiver has recieved the > > > > > body and had a chance to run the headers/body through a spam-filter. > > > > > > YOU try to convince everyone to change their infrastructure....... > > > > Not until after the consequences have been thought through. Would > > that be enough? > > Still waiting....... I didn't say I had a downside. I'm trying to think of a downside; what are the consequences of modifying the protocol in this way? How can it break? How hard is it to implement (not hard for legit senders). Is it trivially defeated by our opponenets? [snip] > > Er, "the" FUSSP list? And I'm not promoting this as the Final Ultimate > > Solution to the Spam Problem... I'm just wondering if it would push > > enough of the costs back on to the spammers to make some of the other > > strategies worthwhile. > > Well if it works on all the spammers it's a Solution to spam, but if > it doesn't then we'll only get spam from the rest of the spammers, and > good ol economic natural selection will take care of us getting some > more spam...... Sometimes, it's easier to chop down a tree if you trim off a few branches first. We may be able to modify the behaviors we see so that the remaining spammers are easier to deal with. Natural selection doesn't always result in a super-organism -- it sometimes results in extinction. [snip] > > Size isn't the issue. Killing the connection in such a way so that > > the sender gets back a useful error message is, so that valid users > > get some decent feedback. > > I'm not sure then perhaps what you were talking about. That's okay, greylisting is far more effective and doesn't require a protocol change. [snip] > > We already have a decentralized reputation scheme -- RBL. > > Naw.....we don't need to centralized control, but certainly for > example treating email from the US as inherently more legitamte much > like email from large corporations, governments and other > organizations is as well. First, bits are bits, you can't tell what country they originated from. Second, email from large corporations and other organizations is often spam. (Thank you CAN-SPAM act, I now have delmar claiming that I have a 'business relationship' with them, and despite unsubscribing, I still get junkmail from them. And several other "legit" organizations do the same thing because well-meaning relatives have 'signed me up' for a newsletter that I don't want.) > The point is not to solve the spam at the > network level, but to push it down to the organizations. If your users > are spammers then you risk your authenticated domain as being a known > spammer. We already have this with RBL. If your users are spammers, they might show up in the RBLs I listen to, and I will block access to your users. Plus, I get to decide which RBLs I consider trustworthy. > If the system is tight enough that there is auditable > ooversight and some degree of control that will be enough. And who enforces these rules? Auditable oversight implies some sort of centralized control. And once you get centralized control, who keeps oppressive governments from using this handy infrastructure for nefarious ends? Who keeps the megacorps from adding themselves as exceptions? > > [snip] > > > hmmmm, I'd suspect they meant TCP connection, and again I'd LOVE to > > > see you convince someone that useless resource and bandwidth usage is > > > an integral part of an effective spam solution. > > > > If it has no effect, it would be useless. If it has the desired effect, > > it is not useless. And I'd like to see a solution that doesn't involve > > additional resource and bandwidth usage... > > That's all fine and dandy, anything from crypto to statistics takes > resources. But if something works then it's justifiable. If it's just > 1 of 672 cogs in your multifaceted super duper spam system then it's > nothing but an incremental and poorly quantified solution. I guess it I'm a big fan of KISS. > all stems from the poor mathematical closure of most solutions. If > you're gonna propose a solution it should at least COMPLETE solve a > certain set of problems so that the others can be dealt with > individually as well. Nah. Deal with the fundamental issues, and the problem can fall into the 'managable' range. The fundamental problem is that it's cheap for a spammer to spam, so shotgun advertising is cost-effective. > All the solutions out there have flaws in > functionality they hinder or don't provide, but quite a few of them do > solve a decent number of problems in every way. Most spam 'solutions' break a lot of the features of email that are quite nice, but that most users don't think about. Decentralized control, good. Easy to add new users, good. Anonymous senders, good. Etc. etc. "Corporate" email systems don't need, want, or allow these things. They want auditability, accountability, tracking, reception verification, delete validation, etc. etc. -Stewart "What tools help you against an oppressive government?" Stremler
pgpWUONvhCZa0.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
