ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/mail/anti-ube-pointer

Internet Message Format | 2004-05-05 | 30.9 KB

Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
Message-ID: <mail/[e-mail]>
Supersedes: <mail/[e-mail]>
Expires: 2 Jun 2004 12:58:04 GMT
X-Last-Updated: 2002/09/01
Organization: none
From: <[e-mail]> (Jari Aalto+mail.procmail)
Subject: Fighting email spam and anti-UBE pointers
Summary: This post contains many of Spam/UBE fighting tools and urls
  from a larger document called Procmail Tips.
Newsgroups: comp.mail.misc,comp.answers,news.answers
Approved: [e-mail]
Followup-To: poster
Precedence: bulk
Originator: [e-mail]
Date: 04 May 2004 13:01:17 GMT
Lines: 648
NNTP-Posting-Host: penguin-lust.mit.edu
X-Trace: 1083675677 senator-bedfellow.mit.edu 568 18.181.0.29
Xref: senator-bedfellow.mit.edu comp.mail.misc:79467 comp.answers:57063 news.answers:270896

Archive-name: mail/anti-ube-pointer
Posting-Frequency: 2 times a month
Maintainer: Jari Aalto <[e-mail]>
X-Last-Modified: $Docid: 2002-09-01 Jari Aalto $

Announcement: "Anti-UBE pointers"

    Availability

        FAQ archive is at http://www.faqs.org/faqs/

        This message is an excerpt of a bigger "Procmail Tips" section
        "29.0 Anti-UBE pointers" available at http://pm-doc.sourceforge.net/

    Terms used in this post

        ._UBE_ = Unsolicited Bulk Email
        ._UCE_ = (subset of UBE) Unsolicited Commercial Email

        _Spam_ = Spam describes a particular kind of Usenet posting (and
        canned spiced ham), but is now often used to describe many kinds of
        inappropriate activities, including some email-related events. It
        is technically incorrect to use "spam" to describe email abuse,
        although attempting to correct the practice would amount to tilting
        at windmills.

        _Spam_ = definition by Erik Beckjord. "Some people decide that Spam
        is anything you decide you want to ban if you can't handle the
        intellectual load on a list." Remember, not to be confused with
        real spam, which is unwanted bulk mail.

        People are nowadays seeking a cure which will stop
        or handle UBE. That can be easily done with procmail (under your
        control) and with sendmail (by your sysadm). In order to select the
        right strategy against UBE messages, you should read this section
        and then decide how you will be using your procmail to deal with it.

    Foreword and recommendation

        There are two highly recommended software that you should check if
        you're serious about taking actions agains UBE:

        o   `rblcheck' which has proven to be very efficient, fast and system
            load friendly for ISPs that filter mail at MTA level.

        o   `Ricochet' which is a Perl program that examines
            the headers to find out right complaint destinations. You no longer
            need to be a Email header expert to understand how the headers have
            been forged. To find the program, use google search
            keywords "Ricochet perl spam"

    29.1 NoCEM, CAUCE and others

       "The war of spam -- pointers to reseurces"
        http://spam.gunters.org/links.html

       "NoCEM"
        http://www.cm.org/

       "The Coalition Against Unsolicited Commercial Email (CAUCE)"
        http://www.cauce.org/faq.html
        ...The Problem: Unsolicited commercial mail, more commonly known as
        "spam", is a growing problem on the Internet. If you've used the
        Internet for any length of time, you've probably received
        solicitations via mail to purchase products or services.

        A Solution: A group of Internet users who are fed up with spam have
        formed a coalition whose purpose is to amend 47 USC 227, the
        section of U.S. law that bans "junk faxing", so that it will cover
        electronic mail as well.

       "SpamCon Foundation"
        http://www.spamcon.org/
        The SpamCon Foundation protects email as a
        viable communication and commerce medium by supporting measures to
        reduce the amount of unsolicited email that crosses private
        networks, while ensuring that valid email reaches its destination.

       "Spamcop - report bulk mail intrucions here"
        http://www.spamcop.net/

       "Lot of good articles about spam"
        http://www.sun.com/sunworldonline/swol-12-1997/swol-12-spam.html

       "Select mail court cases -- Lots of them"
        http://www.jmls.edu/cyber/cases/spam.html
        America Online, Inc. v. Cyber Promotions, Inc.,
        Compuserve Inc. v. Cyber Promotions, Inc., etc.

    29.2 General Filtering pages (more than procmail)

       "Nancy McGough <[e-mail]> - Mail Filtering FAQ"
        .http://www.ii.com/internet/robots/procmail/qs/
        .http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/

       "Information Filtering Resources"
        http://www.ee.umd.edu/medlab/filter/ Doug Oard <[e-mail]>
        ...This page lists all known internet-accessible information
        filtering resources.

    29.3 Junk mail and spam

       "Spam FAQ"
        ftp://rtfm.mit.edu/pub/Usenet/alt.spam/
        http://www.cs.ruu.nl/wais/html/na-dir/net-abuse-faq/spam-faq.html

       "The mail abuse FAQ"
        http://members.aol.com/emailFAQ/emailFAQ.html
        What is UBE, UCE, EMP, MMF, MLM, Spam, it is all explained here.

       "Get that spammer -- A VERY GOOD LINK"
        http://www.toppoint.de/~zoc/gspam.html
        ...All about Spam; traceroute, netabuse etc. Full of links and docs

       "Spam Spade Tools -- Track down that spammer!"
        Includes address digger, obfuscated URLs, reverse DNS, traceroute,
        whois, rwhois, Dejanews author search, USPIS,
        blackhole list check

       "Fight Spam on the Internet!"
        http://spam.abuse.net/

       "Whois"
        http://www.networksolutions.com/cgi-bin/whois/whois/

       "Advertising on Usenet: How To Do It, How Not To Do It"
        ftp://rtfm.mit.edu/pub/Usenet/advertising/

       "Dealing with Junk Email"
        http://www.jcrdesign.com/junkemaildeal.html
        ...What you should do (and not do) when you have been victimized by
        a junk mailer. This document teaches you how to read headers in
        order to trace the origin of junk mail, and includes detailed
        examples to show you how it is done. Headers are designed for
        computers to read, not people, so they can be a little hard to
        follow. Therefore, I hereby grant permission to print or
        electronically save a copy of this page on your local machine for
        your personal use while tracing junk mail. Please check back for
        updates and corrections, though.

        o   What Not To Do: Stuff that doesn't work
        o   What to do: effective techniques, including how to trace junk
            mail back to its source
        o   Stay Calm (take a deep breath...)
        o   Stay Mad (don't get discouraged)
        o   How to identify the sender and who gives them Internet access
        o   Who to complain to, abuse addresses, online services
        o   What to say and how to say it, effective complaining

       "Practical Tools to Boycott Spam"
        http://spam.abuse.net/spam/
        ...We have been actively engaged in fighting spam for years. Recent
        events, including pending court battles, prompt us to present this
        page to the public. Fight spam to keep the Internet useful for
        everyone.

        o   Filtering mail to your personal account
        o   Blocking spam mail for an entire site
        o   Blocking Usenet spam for an entire site
        o   Blocking IP connectivity from spam sites
        o   Other tools and techniques for limiting spam
        o   Sample Acceptable Use Policy statements for ISPs

       "news.admin.net-abuse.* Homepage"
        Timothy M. Skirvin <[e-mail]>
        http://www.killfile.org/~tskirvin/nana/

       "Preventing relaying in Sendmail"
        ...This package adds two independent features to sendmail,
        access control and relay control. They will be described here
        simultaneously, but you can elect to include support for only one
        of them (either one) on your mail server. Access control lets you
        deny access to the server based on the senders envelope address or
        his IP address. Relay control lets you decide who gets to relay
        mail through your server.
        ftp://ftp.xyzzy.no/sendmail/access.tar.Z

       "Anti-Spam Provisions in Sendmail 8.8"
        http://www.sendmail.org/antispam.html
        http://mail-abuse.org/
        http://www.informatik.uni-kiel.de/%7Eca/email/check.html#check_rcpt

        o   Preventing relaying through your SMTP port
        o   Refuse mail from selected hosts
        o   Restrict mail acceptance from certain users to avoid mailbombing

        [1998-06-15 PM-L walter] Somebody's starting to exploit a hole in
        sendmail 8.8, where giving a HELO longer than 1024 bytes causes
        buffer overflow, and all following "Received:" headers are lost. If
        it's done off a relay, we have no clue who sent it. There may be a
        more elegant solution, but here's a quick-n-dirty procmail filter
        for this stunt...

       "Preventing relaying in Netscape Messaging Server"
        http://www.tsc.com/~bobp/nms-no-relay.html
        ...discusses anti-spam configurations for Netscape
        Messaging Server (NMS). These include proper anti-relay config,
        spam filters, and using blacklists such as MAPS from NMS. I was
        compelled to compile this page because of the extremely poor
        Netscape documentation which includes anti-relay configurations
        that are easily defeated. --Bob Poortinga <[e-mail]>

       "US Federal Trade Commission"
        http://www.ftc.gov/
        ...staff publicized the Commission's UCE mailbox, "[e-mail],"
        and invited consumers to forward their UCE to it. spam complaints
        <[e-mail]>

       "Misc"
        http://www.junkbusters.com/
        http://www.well.com/~jbremson/spam

    29.4 Comprehensive list of spammers

       "Against Spam -- The garbage collecting."
        http://www.spam-archive.org/
        To support this archive please forward mail spam to
        <[e-mail]>. Everybody is invited to bounce Mail-Spam
        he/she has got to this list. This is a mailing list to distribute
        actual spam-eMail. All incoming mail will be checked by subject and
        from/sender-address wether it has already been distributed or not.
        No discussions in this list. To discuss about this list please
        subscribe to <[e-mail]>.

        To subscribe to _blacklist-update_  mailing list
        TO:   <[e-mail]>
        BODY: subscribe blacklist-update [e-mail]
        Mail <[e-mail]> to discuss about blacklist if
        your name is on it. (maintained by Axel Zinser <[e-mail]>)
        Get the updated blacklist from
        ftp://ftp.spam-archive.org/spam/blacklist/

    29.5 Misc pointers

          Is there a way to block local users from spamming other sites?
          Maybe somehow force sentmail to read a rc file that would maybe
          then grab the from field and see if the user exists on the system
          or not. Or run it through some sort of filters.

        [philip] You can and should do this purely in sendmail. I ended up
        crafting a check_from ruleset that verifies that the envelope
        sender address is either a) not local; b) a local user; or c) a
        local alias. At the time I did this mainly to force people to
        configure their Eudora clients so they didn't say "Return Address:
        [e-mail]" but it also covers the outgoing bogus source
        address spam case. For those interested in this kinda thing I've
        (just) put it up for FTP:

            ftp://ftp.gac.edu/pub/guenther/

       "IBM's Secure Mailer: postfix - open source"
        http://www.postfix.org/

          [1998-12-15 PM-L Matthew McGehrin <[e-mail]>] The
          official project is known as 'IBM's Secure Mailer'. The
          unofficial codename was Vmailer, but they had to rename that, to
          Postfix to agree with the lawyers. I should know, I have been
          alpha testing this mailer for the past year, and it so blazing
          fast, its amazing. It's faster and simplier to use than sendmail,
          and also faster and more secure than qmail. It works fine with
          procmail. (look in my headers). set
          "mailbox_command=/usr/bin/procmail" in /etc/postfix/main.cf

          [1998-12-15 PM-L Liviu Daia <[e-mail]>] it has
          explicit hooks for both procmail and RBL. In fact it's incredibly
          easy to setup, I got it compiled and configured (with an actually
          usable configuration) in about 15 minutes after downloading it.
          Adding masquerading and a virtual domain took another 2 minutes.
          :-) You should really give it a try, it's faster than QMail and
          _much_ faster than sendmail. So far, I'm quite impressed.

       "Qmail"
        http://pobox.com/~djb/qmail.html
        http://www.qmail.org/

       "Sendmail"
        http://www.sendmail.org/

       "Fetchmail -- old pop3 replacement"
        ftp://ftp.ccil.org/pub/esr/
        http://www.ccil.org/~esr/
        http://www.tuxedo.org/~esr/fetchmail/

       "Maildrop filter utility"
        http://freshmeat.net/projects/maildrop/
        ...Alternative to procmail

    29.6 UBE related newsgroups or mailing lists

        alt.kill.spammers
        alt.hackers.malicous
        alt.2600

        [1997-08-13 alt.privacy.anon-server by anonymous poster] Proper
        etiquette demands you contact their ISP. However, if the ISP are
        not interested in helping you, you should consider a posting in
        alt.kill.spammers (or even alt.hackers.malicous or alt.2600) - give
        as many details as you can about the spammer.

        A certain spam-provider targeted the alt.hackers.malicious
        newsgroup. Not the most sensible thing to do. The ISPs IPs were
        found, their MX host was hacked. All their DNS entries was
        published on alt.2600 (so that everyone could add filters to ignore
        all mail from this company). Oh yeah, their password file also made
        it to the group! The ISP then posted a complaint to alt.2600, much
        to the enjoyment of everyone who took part. That host basically
        died a horrible death. I'm pretty sure that not many people are
        going to lose any sleep over this! I might as well mention that the
        ISP's complaint mentioned that their "freedom" was being
        abused. hehehe. Most of these postings can be seen in dejanews
        or altavista archives of Usenet.

       "SPAM-L mailing list and Doug Muth's Page"
        http://www.claws-and-paws.com/spam-l/
        ... "The SPAM-L FAQ" - A FAQ for SPAM-L, an anti-spam mailing list.
        This FAQ discusses how to join the list and what to post there, AND
        it also delves into the technical aspects of spam. For instance,
        the various kinds of forgeries seen in spams are discussed here,
        along with information on how to recognise them. If you hate spam,
        this is something worth checking out... "TheGoodsites List" - I
        maintain this list, which is part of the Spam Boycott, to show
        which Internet providers out there act responsibly when dealing
        with spam. If you're looking for an ISP and want to know where they
        stand on spam, this is the list for you.

        Send an mail message to <[e-mail]>
        with the words "subscribe SPAM-L <First name> <Last name>" in the
        body of the message (no quotes). f you would like to contact the
        owner, the convention is the same as with all listserv lists. Just
        send e-mail to <[e-mail]>

    29.7 Software: adcomplain -- Perl junk mail report

        <[e-mail]>
        http://www.rdrop.com/users/billmc/adcomplain.html

        Adcomplain runs under Unix, Windows-NT, and Windows-95. Adcomplain
        is a tool for reporting inappropriate commercial e-mail and Usenet
        postings, as well as chain letters and "make money fast" postings.

        It automatically analyzes the message, composes an abuse report,
        and mails the report to the offender's internet service provider.
        The report is displayed for your approval prior to mailing.
        Adcomplain can be invoked from the command line or automatically
        from many news and mail readers.

        #todo: url missing

          [a user happy user reports] ...About 95% of all cases can be
          traced correctly --- unless they come from a known spamhouse;
          where complaining to them would not do much good anyway. Mailing
          lists with strange Received-Headers also can present problems in
          tracing

    29.8 Software: Ricochet (Perl junk mail report)

        http://www.vipul.net/ricochet/
        <[e-mail]> Vipul Ved Prakash

        MailingList: <[e-mail]> with subject
        "subscribe"

        A lot of unsolicited mail goes unreported because tracing the
        origins of a possibly forged mail and finding the right people to
        report to is complicated and time-consuming. Ricochet, a smart net
        agent, automates this process. It traces the names and add resses
        of the systems where the spam originated from along with the
        servers that provide domain name resolution services to these
        systems (in most cases their ISPs). Then it collects/generates a
        list of mail addresses of tech/billing/admin/abuse contacts of
        these system and mails them a complaint and a copy of the spam.
        Detailed description of its workings can be found in the README
        file that comes with the package.

    29.9 Software: RBL lookup tool (C language)

        [1997-12-04 PM-L Edward S. Marshall <[e-mail]>]

          ...rblcheck is a lightweight C program for doing checks against
          Paul Vixie's Blackhole List. It works well in conjunction with
          Procmail for filtering unwanted bulk mail (under QMail, for
          example, you can invoke it with the value of the environment
          variable TCPREMOTEIP). rblcheck is extremely simple:

            % rblcheck 1.2.3.4

          where 1.2.3.4 is the IP address you want to check.

        This is a quick note to announce the availability of a new tool for
        using Paul Vixie's RBL blacklist (see http://mail-abuse.org/  for
        more information about the blacklist itself, if you don't already
        know). Most tools which use the blacklist block mail on a
        site-wide basis. For many networks, this treads on both the ideals
        of the administration, and on the perceived freedoms of the end
        user.

        Personally, I don't care either way. :-)

        This tool was to fill the need I personally had to reject mail,
        since one of the systems I receive mail through cannot, for various
        political reasons, implement the available RBL filters on a
        site-wide basis.

        rblcheck is a simple tool meant to be used from procmail and
        other personal filtering systems under UNIX in the absence of a
        site-wide filter, as an alternative to imposing site-wide
        restrictions, or as a means of imposing restrictions on systems
        that cannot support the existing RBL filter patches.

        Simply put: you hand it an IP address, and it determines if the IP
        is in the RBL filter, providing the caller with a positive or
        negative response. With the package, a sample procmail recipe is
        provided, and examples of using it under QMail and Sendmail are
        given.

        .http://mail-abuse.org/
        .http://www.isc.org/bind.html            The official home page
        .http://www.xnet.com/~emarshal/rblcheck/

        It has only been tested under Linux 2.x and Solaris 2.5.1. Success
        stories, patches, questions, suggestions, and flames can be
        directed to me at <[e-mail]>.

        [PM-L Aaron Schrab <[e-mail]>] Here is my rbl
        setup, but, this depends both upon the format of the Received:
        lines, and the way that mail passes through your mail system.

        I currently grab the IP address from the first Received: header
        inserted by my ISP (I'm a sysadmin at the ISP, so I have a good
        knowledge of how mail gets passed around internally). Here's the
        recipe that I use.

            # if there's a Received: header from one of these servers, it's
            # (probably) the right one

            BACKUPSERVER    = "([yz]\.mx\.execpc\.com)"
            VIRTSERVER      = "(vm[0-9]+\.mx\.execpc\.com)"
            LOCALSERVER     = "([abc]\.mx\.execpc\.com)"

            # Match a header containing:
            #   Received: <anything> [<ip address>]) by <local server>

            :0
            * $ $SUPREME^0 ^Received:.*\[\/[0-9.]+\]\)$s+by$s+${BACKUPSERVER}
            * $ $SUPREME^0 ^Received:.*\[\/[0-9.]+\]\)$s+by$s+${VIRTSERVER}
            * $ $SUPREME^0 ^Received:.*\[\/[0-9.]+\]\)$s+by$s+${LOCALSERVER}
            {
                IP = $MATCH

                # trim it down to just the IP address

                :0
                * IP ?? ^^\/[0-9.]+
                {
                    IP = $MATCH

                    :0 W
                    * ! ? /home/aarons/bin/rblcheck -q $IP
                    {
                        SPAM = "$SPAM $IP is rbl'd$NL"
                    }
                }
            }

          It seems to be a procmail issue with letting the IP info
          from sendmail pass through to the rblcheck program. I have not
          been able to find anyone using rblcheck successfully with
          procmail as a delivery agent...

        [1998-03-26 PM-L Edward S. Marshall <[e-mail]> ] This is a
        standard problem; you should be able to change the invocation of
        procmail the same way as the example (run env, which in turn runs
        procmail). Make sure that there is a '-p' argument passed to
        procmail; this preserves the environment you're constructing with
        env (newer sendmail revisions sanitize the environment for you, so
        that's not really an issue).

        If you're still having troubles, make sure you're using the latest
        incarnation of rblcheck, with the latest supplied procmail recipe;
        earlier revisions had rather insidious bugs.

        [1998-03-26 PM-L Xavier Beaudouin (kiwi) <[e-mail]>] Also it
        seems that sendmail 8.9.0Beta3 has builtin rules. I use it with
        sendmail 8.8.8 and tcpwrapper every day and there is about 80%
        spam rejected. Sounds very good. In your /etc/hosts.allow just add
        the following lines :

            sendmail: ALL: spawn /usr/local/bin/rblcheck -q %a && \
                        exec /usr/sbin/sendmail -bs || /bin/echo \\
              "469 Connection refused. You are in my Black List !!!\r\b\r\n"
              && \
              (safe_finger -l @%h 2>&1 | /bin/mail -s "%d-%h %u" root)

        In your /etc/inetd.conf just add this line :

            smtp stream tcp nowait root  /usr/sbin/tcpd  \
                 /usr/sbin/sendmail  -bs

        And check that your sendmail is _not_ working as a daemon. That's
        all. Also if you have huge queue you can add a /usr/sbin/sendmail -q
        in the root crontab... This should help to send some waiting
        messages. I think we can use this to wait for official 8.9.0
        sendmail since there is some cf/feature/rbl.m4 there.

        [timothy] ...I think there's a much more efficient way to do
        this: you can compile sendmail -DTCPWRAPPERS and let it run as a
        daemon

    29.10 Software: mapSoN

          Note: You can do exactly the same as below with procmail with one
          of the listed procmail modules: pm-jacookie.rc. See the code.

       "mapSoN (NoSpam backwards) -- The no spam utility"
        http://mapson.gmd.de/
        ftp://ftp.gmd.de/gmd/mapson/

        Most spam filtering tools I've seen so far are based on procmail, or
        a similar tool, and use a list of keywords or addresses to drop
        unwanted junk mail. While this might be nice to filter mail from
        known spam domains like "cyberpromo.com", it won't catch faked
        headers.

        mapSoN must be installed as filter program for your incoming mail,
        usually by adding an appropriate entry to your $HOME/.forward file.
        This means that mapSoN will get all your incoming mail and it will
        decide whether or not to actually deliver it to your mailbox.

        o   First of all, an user defined ruleset is checked against the
            mail. If any keywords or patterns match, the mail will be dealt
            with according to your wishes. This is useful to drop some
            sender's mail completely, or to sort mail into different mail
            folders.
        o   If no rule matches the mail, mapSoN will check whether the mail
            is a reply to an e-mail you sent, or whether it is a reply to a
            USENET posting of yours. If it is, the mail will always be
            delivered.
        o   If no signs of a reply-mail can be found, mapSoN will check
            whether the sender stated in the From: header has sent you mail
            before. If he has, the mail will pass. If this is the first time
            you receive an e-mail from this address, though, mapSoN will
            delay the delivery of the mail and spool it in your home
            directory. Then it will send a short notice to the address the
            mail comes from, which may look like this:

            From: Peter Simons <[e-mail]>
            To: [e-mail]
            Subject: [mapSoN] Request for Confirmation

            mapSoN-Confirm-Cookie: <some_weird_cryptographic_cookie>

        The person who tried to contact you will then reply to this
        "request for confirmation", citing the cookie stated in the mail.
        When your mapSoN receives this confirmation mail, it will deliver
        the spooled mail into your folder. Furthermore, the address will be
        added to the database, so that mail from this person will pass
        directly in future.

        If no confirmation mail arrives within a certain time, mapSoN can
        either delete the spooled mails, or send them to a special folder,
        or whatever you prefer.

    29.11 Software: spamgard

        [similar to MapSon]
        ftp://ftp.netcom.com/pub/wj/wje/release/sg-howto

        ...sppamgard(tm) screens from your e-mail unsolicited bulk mail. It
        does this in a way that you only have to change things if you have
        a new person from whom you _do_ want to receive mail; you don't
        have to change things every time a spamster thinks of a new trick
        to pull, or a new spamster comes along. And spamgard(tm) is
        designed so that those who aren't in your "Good Guys" list can get
        mail to you anyway until you put them there. The instructions for
        them to get mail to you are simple and newbie-tested, but will
        still keep out bulk mail. If you're on a mailing list you _want_ to
        be on, there are provisions for accepting all mail from a set of
        mailing lists that you specify.

    29.12 Software: Spam Be Gone

       "Spam Be Gone"
        http://www.internz.com/SpamBeGone/ (open source)
        ...uses machine learning and artificial intelligence technologies
        to examine incoming mail messages and determine their
        priority... is more than just a Spam filter, it's a general purpose
        mail message prioritiser. You train the system, telling it which
        are good, and which are bad messages. As Spam Be Gone! learns it
        becomes customised for each individual user.

        Note: 2000-03 this software has changed a lot, so the above
        comment may not apply any more. If you have used the latest version,
        please send your impressions to this page's maintainer if they
        differ from the text below.

         PM-L R Lindberg & E Winnie <[e-mail]> comments:

          I have to agree with the recent comments about Spam Be Gone, I
          found it tends to be inaccurate. I first set it up about a week
          ago, followed the directions and trained it on several (15 to 20)
          messages. One from each list we get, and the remainder from my
          logs of SPAM messages.

          The first day it missed about half the SPAM, and nailed about 1/3
          of the real messages. So I tuned the key-words a bit, trained it
          on about 100 more SPAMs and trained it on all the good messages
          it nailed. Since then it has nailed every SPAM received, however
          the second day it nailed about 20% of the good messages, which I
          then trained it to like. Since then it has been nailing about
          10% of the good messages, despite continual training. I also
          added every list to the address book, and it still nails posts
          from this list, and my wife's lace list.

          I even went through my entire log of SPAM and trained it on every
          one that didn't come out a 5 (bad). Being the kind of person I
          am, I also checked after I trained it, and found four SPAMs, the
          despite my training it that they were bad (5) came out as not so
          bad (4). I don't dare kill 4's as far too much of my mail (like
          this list) ends up as 4's.

          For me, this program is not ready for prime time. If the comments
          are correct that it only learns on Subject and From headers, it's
          not even worth trying. Since lists use the TO and CC headers to
          be identified, and there are several excellent other headers
          (X-Advertisement comes to mind) that would be assests for killing
          SPAM.

    29.13 Software: TinyGnus - Emacs Gnus plug-in

        ._Availability:_ <[e-mail]>
        .http://tiny-tools.sourceforge.net/
        ._Platform:_ Win32 and Unix Emacs versions.

        *TinyGnus* Is Emacs lisp extension package that integrates directly
        to Gnus mail/newsreaders. It includes simple but efective UBE
        fighting hotkeys that make it possible to complain bunch of UBE
        messages at once. In order to use it, you have to have permanent
        Internet connection and nslookup(1) tool. Features:

        o   USER MUST DECIDE and hand select WHICH IS *ube* MAIL. No software
            can decide 100% which mail is UBE, so the responsibility is on
            the Human user.
        o   User selects messages that are ube with Gnus select commands,
            like (#, select current message)
        o   Hotkey C-c ' u examines messages' headers and runs `nslookup(1)'
            for each Received header to determine *abuse* *spam* and
            *postmaster* addresses where to send the complaint.