Click here to get rid of any annoying frames

TOC


Any good client-side spam killer?

Newsgroups: comp.mail.misc

Date:        Wed, 17 Dec 2003 19:37:13 GMT

I'm trying to find a good client side spam killing program. My POP server is showered with spams, the s/n ratio is less then 10%. I want to kill those spams before downloading them, saving both bandwidth and time.

I've found and tried some, but still not satisfied with them. What is your recommendation?

According to SaveMyModem, <http://savemymodem.sourceforge.net/>; it is better than mailfilter <http://mailfilter.sourceforge.net/>;:

There are some other delete-on-server mail-filter programs, like mailfilter, but I've not found one with all these functions:

    * portable (it runs natively on Linux and Windows)
    * complex rules with logic operators (and,or,...)
    * extended regular expressions match
    * rules can use the message size (beware of large executable files)
    * black list check for spammers
    * interactive mode (to test and improve your rules)
    * batch mode (if you trust your rules)
    * UIDL database (if you use the "keep messages on server" pop3 feature)
    * APOP (secure pop3 authentication)
    * plugin architecture(other mail filters/mail protocols can be easily added)
    * high configurable bandwidth usage (you can choose how many lines/bytes you want to download and check of each message)
    * bounce message(simulate your mailbox is unavailable)
    * multithreaded download(avoids slow DNS / pop3 servers)
    * SpamAssassin based check(mix the power of spamassassin with smm lightweight bandwidth usage)

But I found that SaveMyModem is still not good enough:

SUBJECT

        SIZE   
        SENDER
        TO     
        CC     
        HEAD   
        BODY.  

No "Any-Sender", which could be "From:", "Apparently-From:", "Sender:", "Reply-To:", "X-Sender:", "Envelope-From:" and "X-Envelope-From:":

Neither have "Any-Recipient", which could be "To:", "Apparently-To:", "CC:", "BCC:", "Envelope-To:", "X-Envelope-To:", "Original-Recipient:", "X-Resent-For:", "X-Resent-To:" and "Resent-To:".

No way to work on other headers. So there is no way to take advantage of headers from SpamAssassin, or construct rule like from_daemon in procmail.

Well, so much for my homework. Any good suggestion? Thanks


Any good client-side spam killer?

> I'm trying to find a good client side spam killing program. My POP
> server is showered with spams, the s/n ratio is less then 10%. I
> want to kill those spams before downloading them, saving both
> bandwidth and time.

Write a netcat script that will hit the server, give you the number of mails with the STAT command, then bring down only the headers with the TOP command, run these through a procmailrc that will save the numbers of the mails that fail your tests, and then feed that list to the server using the DELE command. Bring down the mails you want to take a closer look at with the RETR command and run them through a different procmailrc.

This is how the new version of my own program is going to work, but it is still on the drawing board. Very simple, actually. The script looks something like this:

(this brings down the headers and sends them to procmail)

    #! /bin/sh

    (echo user bigfoot@overjoy.net
    echo pass xxxxxxxx
    echo stat
    while true
    do
    sleep 1
    if [ -s mailfile ]
    then
    num=`tail -1 mailfile | sed -n 's/\(+OK \)\([0-9][0-9]*\)\
    \( [^ ][^ ]*\)/\2/p'`
    break
    else continue
    fi
    done
    echo list
    sleep 1
    j=1
    until [ $j -gt $num ]
    do
    echo -n $j >> numfile
    echo -n " " >> numfile
    j=`expr $j + 1`
    done
    sleep 1
    for i in `cat numfile`
    do
    echo top $i 0
    done
    echo quit)| netcat -vvv pop.overjoy.net 110 > mailfile

    cat mailfile | sed '1,/^$/d' | formail -ds procmail ~/procmailrc1  

    rm mailfile

exit 0

Alan Connor


Any good client-side spam killer?

> > > I'm trying to find a good client side spam killing program. [...]
> >
> > Write a netcat script that will hit the server [...]
>
> Absolutely fascinating. Thanks Alan!
>
> To me, you've made the impossible possible. I'm anxious to hear the
> rest of your story, because to me the next "impossible" is to use the
> procmail script to map the spam to their original mail # on the
> POP server, so that the corresponding DELE commands can be
> issued.

Here's the approach I'm going with for the moment, though the real procmail experts may suggest a better one:

The procmailrc that's used to pre-filter the headers has two basic recipes.

# if you want the whole of that mail to be brought down

    :0
    * ^From: whoever@whatever.com # or whatever
    | cat ~/messnum >> ~/yesfile ; incrementscript

    # if you want to delete it on the server

    :0
    * ^Subject: whatever
    | cat ~/messnum >> ~/nofile ; incrementscript

messnum just contains a single number, the number of the current mail being processed.

Putting this at the top of that procmailrc will set the number to 1 when procmail shuts down after processing a batch of mail (headers in this case).

    TRAP=`echo "1" > ~/messnum`

incrementscript:

    #!/bin/sh

    num=`cat ~/messnum`

    echo `expr $num + 1` > ~/messnum

    exit 0

Simple, eh?

> A side question, if I want to retrieve the first 5 body lines, is
> changing the "echo top $i 0" to "echo top $i 5" good enough?

Yes. Get a copy of RFC-1939

Alan Connor


[ANN] SpamFree (was: Any good client-side spam killer)

> > I'm trying to find a good client side spam killing program. [...]
>
> Write a netcat script that will hit the server [...]

Hi, Alan:

Thanks to your ingenious idea and code sample, I submerged into programming mode right after your posts, now I've turn your blueprint into a solid product -- SpamFree.

The major improvements are:

Other features worthwhile to mention:

Please check it out at http://spamfree.sourceforge.net/

Also available on the site:

A word of precaution, as the first release, it works for me, but might not work for you. So test it before put it into real use. It is now happily removing spams from my pops for me. I've also test it with huge mails, a over 16M file attachment, first time encoded with mime64, and second time with yEnc. I know yEnc has CRC check built in, so I'm quite confident that it is getting mails exactly as-is.

Tong

<< 2003.12.26 Fri


Last updated on: Fri Dec 26 17:35:25 EST 2003

TOC

SourceForge.net Logo