procmail
[Top] [All Lists]

acceptlists, blacklists, spam, and twits, oh my! (was: Re: Certified Mail Delivery agent)

2001-12-13 11:20:42

My configs work like so:

        [MTA: acess.db blacklist]
                MTA based blacklist - with it, I trash netblocks associated
                which Chinese, Korean, and Taiwaneese operations which have
                demonstrably been affiliated with spam.
        [MTA: Cyrus-SASL SMTP AUTH]
                Allows individual users to authenticate to send mail even if
                they're technically connected via an ISP that would trip an
                RBL (such as the DUL).
        [MTA: RBLs: RSS, DUL, maps RBL, etc]
                blocks out known spamhosts and dialup users.

        [Procmail: /etc/procmailrc]
                Primarily used to catch viruses.

        [Procmail: my personal filters]

                [specific administrative filters]

                [acceptlist]
                        an address appearing in the acceptlist bypasses twit
                        and spam checking.  Not simply immediatley delivered -
                        just bypasses the twit and spam checks.

                [notwit]
                        Primarily intended to catch a custom header I inject
                        into messages when reprocessing them from an archive
                        so that they don't simply re-trip the twits filter.

                        [twits]
                        filters out twits using a twitlist.  Also has a few
                        rules for filtering out list-specific adverts (you
                        sub to some lists and they send out periodic
                        "announcements" - I don't treat these as spam since I
                        elected to receive the list].

                [nospam]
                        similar to notwit.  Contains addresses which shouldn't
                        be subjected to spam filtering (perhaps mailing lists,
                        but should not be added to the acceptlist because if
                        one did that, you'd bypass twit filtering).

                        [spam]
                        heuristic tests of messages to identify spam.  Also
                        employs a blacklist of specific addresses (such as
                        companies which engage in spam advertising), and
                        uses my "megagrep" to scan the headers for approx
                        350,000 domains I'd just as soon not receive email
                        from or through.  Messages are dumped into an archive.

                [regular mail filtering]

[Mark said]
forward this spam to. Then, ever so frequently, I use the human eye to
determine which of those emails really is spam, and whether domains or
IP-ranges need to be blocked. I like that co-operative approach. Instead of
making an overly zealous determinination what is a spam, users get to have a
choice in what they forward as spam. Mind you, a choice, not a voice. :) I
ultimately make the determination what gets blacklisted or not.

Another technique is to have a spamsink address: an address which is present _only_ to receive spam. You can use it to seed your spam database.

Naturally, I have a few Perl scripts to sift out IP addresses and relays
from /var/log/maillog and such, but the decision remains a human one. I
never send a message back to spammer, not personally or automated.

Good policy. The closest I get is sending in a formletter (I just delete the parts that don't apply) with the full headers and body of the spew to the abuse contacts at the ISPs involved with the spew. That includes the ISP used for a dropbox/removebox, the web hosting outfit if the spew points to a website (free or hosted), the network used to relay and originate the message, and the outfit of the "from" domain (even if not actually used, they can sue for damages).

That usually only tells them they have a responsive address.

(which is one of the major problems with the CMD automated whitelist approach).

I just add their name with a REJECT in the access database;

I'm going far afield of procmail here, but as long as we're on the topic, let me provide a suggestion:

use make

I use it for my spam database, sendmail, named, apache, etc - all configurations which are reliant on multiple files, and which I've broken out into separate datafiles (or db entries) for different domains, hosts, whatever. Makes administration a LOT easier.

With your access.db stuff, you can maintain a _regular_ access db portion, say "access.base", plus one which is _built_ from a spam db, "access.spam", and "access.twits" (which is actually processed through a script which randomly chooses a different reject message for the different users listed in it). You toss all of these together and emit them to "access.txt" (along with a header that says "DO NOT EDIT THIS FILE - IT IS BUILT FROM OTHERS"), then build the access.db hash (if it's dependant files have changed), and depending on other changes, also restart the sendmail daemon.

The access.twits list is used to deny access to an exclusive list of morons so that they cannot access the mailing lists hosted on that server. By randomly selecting a new reject message every time the file is rebuilt, you keep 'em guessing as to why their message is rejected - perhaps making them think it really is a problem at their own end ("550 Mail loop detected. Message dropped.", "550 Message lacked valid From: identifier", etc)

---
 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

<Prev in Thread] Current Thread [Next in Thread>