Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
Russell Nelson [EMAIL PROTECTED] writes: The DUL and the RBL have NOTHING (vehemently so) to do with each other. Well, no, but they are served in the same way, both MAPS projects, and both work to help reduce spam on my network. --Michael
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
Paul Gregg [EMAIL PROTECTED] writes: So, Why wouldn't this work? Because you're using a technical solution to fix a social problem. The spammers will just find another way around the system. So far, flame.org has rejected just under 1000 messages due to being on the RBL, 40 due to being on the DUL (dialup list, run by the RBL people) and 203 due to header based regular expression filtering. That's about 31% of all spam that hits my box. The problem is, the rules sets need to be constantly updated. It is right to say that rule based filtering will fail, but laws help. For instance, in California, it is not illegal to send spam to another californian, but if it doesnt have "Subject: ADV:" in the front, it is. And I can charge $50/message. And I've used that as a way to scare the shit out of would-be repeat offenders. --Michael
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
At 02:05 PM 1/19/99 +0100, Pavel Kankovsky wrote: On Tue, 19 Jan 1999, Mark Delany wrote: Then what will you match on? The content? How much code does it take to randomize the content? You (as a spammer) can't randomize the contents beyond the point where an average reader would stop being able to understand it. Of course, but what a human can understand and what a pattern matcher can recognize are not particularly related in any way. Regards.
Possible Anti-spam solution (was Re: Example of the anti-fax effect)
DJB wrote: I'm interested in credible plans for eliminating spam: e.g., using the legal system to bankrupt spammers, and widely advertising the results; or using digital cash to incorporate secure prepayments into Internet mail. I'm not interested in security through obscurity. How about this. I can't take credit for the ideas - I'm just joining two potential solutions. 1 - We already have the RBL. 2 - We setup a "dummy" address to which when our mail system receives a spam it records some pattern from that email and matches this pattern against further emails from that host - any matches are rejected/discarded or placed somewhere else. Idea from this originally belongs to Elie Rosenbloom (nyx.net) So lets design a system where we, as contributing MTAs, register a few dummy addresses with a central (or distributed) RBL type setup. We all make up these arbitrary addresses and seed the spammers databases with them (by posting to usenet or putting them on webpages) and register these addresses with the "RBL". If any emails come into these seeded addresses then we register some info about that email with the RBL. All incoming emails are checked against this RBL-type database to see if we should accept or deny this email. It is likely that we'll need some double level check to happen - probably a stage 1 check like the real rbl which checks to see if the incoming ip address may be a problem one. If so then we check the emails headers against the database to see if this is indeed a spam. The spammers would never be able to figure out the seeded addresses and the only real way around this system would be to use different source IPs for sending emails (not practical) if sending direct to MX. If they use an open relay then it'll quickly kill off connections from that machine - but we would need to build in a TTL since the last spam registered from that host (e.g. 12 or 24 hours). So, Why wouldn't this work? Paul Gregg -- Email pgregg at tibus.net | Email pgregg at nyx.net| Eight out of every Technical Director| System Administrator | five people are math The Internet Business Ltd | Nyx Public Access Internet | illiterates. http://www.tibus.net | http://www.nyx.net | - Anon.
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
If any emails come into these seeded addresses then we register some info about that email with the RBL. Which info would you record? The forged envelope sender or the unwitting third-party relay? sending emails (not practical) if sending direct to MX. If they use an open relay then it'll quickly kill off connections from that machine - but we would need to build in a TTL since the last spam registered from that host (e.g. 12 or 24 hours). So, Why wouldn't this work? Because most open relays are not well administered, if at all. All you'd succeed in doing is RBLing most open relays. But, we already know who they are (or did with dorkslayers et al) and can block them without the need for an elaborate scheme. Probably spamtools is the place for this discussion as the politics of dealing with open relays is the controvery not the technology and it has nothing specific to do with qmail. Regards.
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
Mark Delany wrote: If any emails come into these seeded addresses then we register some info about that email with the RBL. Which info would you record? The forged envelope sender or the unwitting third-party relay? 1) IP address of the remote host and 2) From / Subject / To ? The thing spammers are least likely to much with is the subject. But if you recorded all 3 you could do a reasonably quick "intelli" match on other emails from that host. sending emails (not practical) if sending direct to MX. If they use an open relay then it'll quickly kill off connections from that machine - but we would need to build in a TTL since the last spam registered from that host (e.g. 12 or 24 hours). So, Why wouldn't this work? Because most open relays are not well administered, if at all. All you'd succeed in doing is RBLing most open relays. But, we already know who they are (or did with dorkslayers et al) and can block them without the need for an elaborate scheme. No, I don't think you've grasped the concept. If I received an email to a seeded address then Qmail-? would immediately update the "RBL" with 12 above. Then when the spammer gets around to spamming mira.net customers your "RBL" check will kill it mid flight. It's a co-operative thing where only the first few emails will get through and 99% of subsequent emails (from this spammer) will be blocked at the co-operating MTA. Probably spamtools is the place for this discussion as the politics of dealing with open relays is the controvery not the technology and it has nothing specific to do with qmail. Yes it isn't Qmail specific at all, I was just responding to Dan's suggestion for something that would work. Paul. -- Email pgregg at tibus.net | Email pgregg at nyx.net| Eight out of every Technical Director| System Administrator | five people are math The Internet Business Ltd | Nyx Public Access Internet | illiterates. http://www.tibus.net | http://www.nyx.net | - Anon.
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
From: Paul Gregg [EMAIL PROTECTED] :1) IP address of the remote host and 2) From / Subject / To ? :No, I don't think you've grasped the concept. If I received an email to :a seeded address then Qmail-? would immediately update the "RBL" with 12 :above. This is both 1) Not the job of an MTA and 2) a DOS attack in the making. Besides, this would be easy enough to implement with a .qmail file and some nifty bash scripting. :Paul. --Adam
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
Which info would you record? The forged envelope sender or the unwitting third-party relay? 1) IP address of the remote host and 2) From / Subject / To ? The thing spammers are least likely to much with is the subject. But if you recorded all 3 you could do a reasonably quick "intelli" match on other emails from that host. Well, only until you put a tool in place that matches on Subject. How much code does a spammer have to write to randomize the Subject? Then what will you match on? The envelope details? How much code does it take to randomize the envelope details? Then what will you match on? The content? How much code does it take to randomize the content? Then what will you match on? What you need to do is put yourself in the position of the spammer and ask, "Can I think of a way around this technique". If so, well, so too can spammers. No, I don't think you've grasped the concept. Well, I think I have actually... Seeded detection of spam is not new. If a spammer sufficiently randomizes their headers, content and their relay, how will you detect them reliably? Answer: you can't. But I could be wrong. What's say you supply the 'reasonably quick "intelli" match' and I'll see if I can supply a program that generates spams that get thru. Let's use perl as the language. Regards.
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
Paul Gregg [EMAIL PROTECTED] wrote: DJB wrote: I'm interested in credible plans for eliminating spam...I'm not interested in security through obscurity. [snip] 1 - We already have the RBL. 2 - We setup a "dummy" address to which when our mail system receives spam it records some pattern from that email... [snip] So, Why wouldn't this work? This suggestion has two parts. First, it is a way to attract spam. Second, it leads to "pattern matching" as a spam-fighting technique. I think the first part is fine, if you want to be proactive about identifying spammers. The second is, I think, what DJB means by "security through obscurity". In an earlier post, he observed: You seem to think that spam is a pattern-recognition problem. It isn't. You're ignoring the anti-fax effect: anti-spam rules become useless when enough people start using them. Spammers adapt. In general, I agree with this observation--in the long run, any particular pattern-matching approach to stopping spam is doomed; each pattern will work for some period, and then fail. Ultimately, spam will evolve into something which perfectly mimics legitimate email. For example, if an email is 100% 822-compliant, has exactly one envelope recipient which matches the single "To:" recipient, and exactly one "From:" address, which matches the envelope sender and is valid, what pattern-matching by the recipient can be sure whether it is spam? Now suppose that this spam is trickled out, just below VMailer's "mailbomb" threshold, through a non-blacklisted ISP...and remember, a _valid_ From: address need not be the _sender's_ From: address. Len. -- I wasn't talking about sendmail+shell versus sendmail. I said you would need dozens of subshells to make _qmail_ as slow as sendmail. -- Prof. Dan Bernstein
Re: Possible Anti-spam solution (was Re: Example of the anti-fax effect)
Mark Delany [EMAIL PROTECTED] wrote: Well, only until you put a tool in place that matches on Subject. How much code does a spammer have to write to randomize the Subject?...Then what will you match on? The content? How much code does it take to randomize the content? At which point spam is virtually undetectable, of course. Not much code is required--this is fairly well-understood technology. See http://www.geocities.com/Tokyo/Towers/5190/complaint.htm for an amusing example. Plenty of others exist, including one which generates post-modernist essays ready for publication. That demonstrates something about academia, I'm sure... Len. -- It is an abomination to kings to commit wickedness: for the throne is established by righteousness. --Proverbs 16:12
