> > > > I like the idea of greylisting > > > > > > > I'm not sure what greylisting is > > > > hmmmmmm whitelisting = good senders, blacklisting = bad senders, grey > > listing = use all of the other junk that you normally use like baysian > > filters etc. on it becasue you don't have a reputation associated with > > it either way. Is that what you were trying to say? > > Me? No. > > http://projects.puremagic.com/greylisting/ > > 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. 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....... > > > > 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....... > > please refer back to the FUSSP list for some comments on this one. > > 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...... > > What do you think the likelyhood of convincing people who's business > > profit comes from efficient utilization of hardware and networks to do > > that. > > You think handling all this spam is efficient utilization? > > > Mind you there is already a mechanism for cutting the transfer > > of short if the amount coming is too big so........... > > 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. > > > > It keeps the connection open while scanning, which (presumably) > > > > slows the rate that spam can be sent, and increases the chance > > > > that the spammer will end up in an RBL, which increases the cost > > > > to the spammer. > > > > Yes, but RBL's are a relic and certainly not the future. You can spend > > Well, that's a claim, certainly. > > > lots of time trying to block the bad guys, or just only accept mail > > from people with good reputations (which would also include people who > > use reputable service providers) which is the way things are going > > anyway. > > Well, that's where the hype is going. And there's certainly a lot of > corporate momentum behind it -- and it certainly favors the corporate > re-structuring of the system. Centralized control over who can send > email to whom is a corporate wet-dream, and it leaves us little guys > out in the cold. > > 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. 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. If the system is tight enough that there is auditable ooversight and some degree of control that will be enough. > [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... > > -Stewart "What so bad about another couple of packets anyway?" Stremler > 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 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. 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. T -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
