Re: Removing/blocking spam2002-02-12 13:01:09
At 17:13 2002-02-12 +0000, Edward Wildgoose wrote:
entry for fetchmail, hence they could pickup mail from their yahoo accounts,
Because like, from a web cafe', they can't access their Yahoo account?
Next on my list is spam removal! So I am trying to get inside the current state of "safe" spam removal, ie where the users don't really need to know how to opt out because the emphasis is on blocking the really obvious stuff.
Really obvious would include hosts which don't resolve (although they can be transient network errors). That's an MTA level check - you'd refuse the email as they attempt to send it into the server.
However, my main question, which I don't think you answered(?), is, can I reduce spam mail, *safely* by blocking using any of the public RBL's,
I don't think so, not at this point, for the reasons I cited: the public RBLs at this point are based too much on whim. I don't fault MAPS for going pay-for, merely the amount they're demanding.
I don't have a handy review of the different RBLs. If someone does, I'd be interested in seeing it (URL preferred), but what I've seen thus far says I don't want to switch to any of them just yet.
or are all the public ones going to give me dubious readings.
Note that it isn't as if MAPS never had a valid business in their RBLs, just that that valid business was stupid enough to leave their mail server config susceptible to relaying and thus got jacked by spammers. Many of the large ISPs have been in the MAPS db at one point or another. So, if you're expecting to use an RBL and not toss *ANY* valid email, you're outta luck. My mention of RBLs is that they're (well, at least MAPS) quite effective at reducing spam. If you're a big enough outfit with users receiving email from enough different places, you're bound to have a valid contact have their email refused because their server is in the RBL.
What _valid_ mail you might lose to a _good_ RBL db can be considered collateral damage, and itself should lead to that host stepping up it's work to resolve their RBL status - after all, a business can't operate if everyone is bouncing their email, and customers don't stick with ISPs (well, unless they're AOL'ers <g>) that can't deliver their email.
I really want to *only* filter out the "this definitely is a known spam sender" IP's.
Then, as spam gets into your server, you add hosts or domains to your access db (in sendmail). Or, you properly inform the users of your system that you're refusing email from large asian netblocks, and then pre-emptively add those to your access db.
I take it a step further: if it is hosted spam (that is, the spammer isn't making any attempt to use forgery and relaying), or there's a clearly identified webhost in the spew, I contact the hosting ISP - if they're unwilling to do anything about it, they - AND ALL OF THE DOMAINS THEY HOST -land in my spamhaven database, and I refuse mail from the whole lot of them. I use a database extracted from the root zones (at least for com|org|net|mil|edu|gov domains), to determine all the hosted domains, based on the ISP NS. This is a pretty radical approach, but I've found that services that don't take action on spammers are spamhavens, and a fair number of the other domains they host have tended to be similar (smut houses for instance - I've got no beef with online porn vendors, except when they spam - and it seems that the services which host one are going to host a couple dozen more as well).
I've considered "peppering" spam lists - either taking addresses of mine which are already poisoned (and have thus been ditched), or by intentionally posting an address in webpages (for spambots) or on usenet, etc - then setting up a sendmail ruleset-invoked procmail rule which checks to see if *any* of the recipients of a message are in this pepper list, and if so, automatically drop the message as well as add the mailhost and perhaps the sender address to a locally-managed RBL.
My thinking: if there were an RBL which was populated ONLY by submissions to a peppered list, and this would be distributed amongst multiple _trusted_ sites, so that it isn't JUST the mail arriving at your own server - then you could flag spam quite effectively.
The problem with this approach is that all it takes is a spammer realizing that they merely have to subscribe your pepper address to a bunch of VALID mailing lists (the mere subscription ATTEMPT - followed by a _goof_ listserv contacting you automatically for confirmation, would be enough to trip the mechanism), and in doing so, would cause VALID mail servers to become rejects.
Of course, they have to know what your pepper address is. Or perhaps (with the distributed mechanism), multiple pepper sites have to submit a host before it is added to the db (though of course, that means the spammer is out making the rounds that much longer before their mailhost gets blocked).
Oh, only if I had the time and resources to work on this...
However, perhaps spam only ever gets "bounced" via someone else with an open relay, and so this is doomed not to work...?
Open relays are the major mechanism for spam delivery. If the spammer is using their own mailserver, they might eventually get booted and relocate to new digs, which wouldn't immediatley be in the spam db. You won't achieve 100%, and you won't do it without _some_ risk with valid email.
[big snip - verbatim block quotes of previous messages are unnecessary] --- Sean B. Straw / Professional Software Engineering Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html> Please DO NOT carbon me on list replies. I'll get my copy from the list. _______________________________________________ procmail mailing list procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail