Re: Removing/blocking spam

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