Thanks, this is helpful background.
Basically what I am doing is setting up a service for some folks with a very
low bandwidth connection (satellite link - 2400 baud) and have so far got quite
a nice little setup which converts the mail to plain text, strips redundant
headers out, etc. (uses demime if anyone is interested)
I am now interested in the value added features. For example I have plonked
squirrelmail on to give them webmail if they are near an internet cafe instead.
Squirrelmail has a nice interface to allow users to set a single entry for
fetchmail, hence they could pickup mail from their yahoo accounts, etc.
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. I think that
I am going to evaluate spam assassin (based on annecdotal evidence).
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, or are
all the public ones going to give me dubious readings. I really want to *only*
filter out the "this definitely is a known spam sender" IP's. However, perhaps
spam only ever gets "bounced" via someone else with an open relay, and so this
is doomed not to work...?
Thanks for your help
Ed
-----Original Message-----
From: Professional Software Engineering
[mailto:PSE-L(_at_)mail(_dot_)professional(_dot_)org]
Sent: 12 February 2002 16:26
To: procmail-users(_at_)procmail(_dot_)org
Subject: RE: spamrc.txt file not working
At 12:17 2002-02-12 +0000, Edward Wildgoose did say:
I'm curious to know how you rate the free RBL's?
Too many of them are either "gosh, we tested this server and it's an open
relay" (ordb) or "someone sent us a report that there was a bad guy and
this was his mail server, so without any validation, we stuffed it into the
db" (dorkslayers).
Granted, the first approach has it's merits, but it is entirely too likely
to result in lost mail - and if some backbone provider's network gets
scanned and blacklisted, they'll block routing for the subnet (Alter.net
did this with thr original Orbs - which meant that hosts that had to pass
through alter.net to get to orbs to do a lookup couldn't, AND that orbs
couldn't scan hosts if it had to pass through alter.net - which meant that
those host, even if spammers, would never appear in the orbs db). After
MAPS took their RBLs and made them pay-for (a token fee would have been one
thing, but geezus - you've got to pay for EACH db, and for EACH server
accessing their db (which could be circumvented with some DNS proxying),
most of the consistently-good dbs were suddenly unavailable.
If I was starting up a small e-mail service for 50 or so users and wanted
to err on the cautious side, ie some junk may slip past, but we emphasise
that we rarely reject real mail (and I am assuming that users are going to
need too much training to "opt-in", hence this will be automatic unless
they request to be "opted out"), then what would you advise me to use?
If you want to let people opt out, then the RBL checking will need to be
done from a global procmailrc, not within the MTA itself (well, I'm sure
with some wizardry, one could manage to do selective RBL-ing: access.txt
would be one way for uniquely hosted domains, but I don't think it'd work
for individuals -- but it will still require the admin to make changes
based on the whim of a user).
Also, presumably dumb question, but these RBL's will presumably have no
effect on any mail arriving via fetchmail because the RBL
Correct. Are you saying that your mail is actually transferred using
fetchmail (which of course, has nothing to do with procmail, just in case
someone reads this in the archives).
One of my favourite RBLs was the DUL - Dialup User List - (a MAPS db) it
simply contained known dialup lines for a lot of ISPs - users who should be
using their ISP mailserver to deliver mail to you, not their dialup. That
alone was capable of nixing a lot of spew.
---
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
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail