Can anybody point me to a project/FAQ similar to this:?
1. Perl script fetches POP mail from a distant server
2. mail is fed to SA, running as a standalone module in my user account
3. SA spits out results back to perl script.
I don't have root access.  I don't need a MTA.
Sponsored by: AMD - Your access to the experts on Hammer Technology!
Open Source & Linux Developers, register now for the AMD Developer

from localhost (jalapeno [127.0.0.1])
	by example.com (Postfix) with ESMTP id 40AE616F1F
	for <zzzz@localhost>; Mon,  7 Oct 2002 13:12:51 +0100 (IST)
from n5.grp.scd.yahoo.com (n5.grp.scd.yahoo.com [66.218.66.89])
    by dogma.slashnull.org (8.11.6/8.11.6) with SMTP id g97C07K30374 for
    <zzzz@example.com>; Mon, 7 Oct 2002 13:00:08 +0100
From sentto-2242572-55914-1033992044-zzzz=example.com@returns.groups.yahoo.com  Mon Oct  7 13:14:39 2002

from localhost (jalapeno [127.0.0.1])
	by jmason.org (Postfix) with ESMTP id EF15F16F03
	for <jm@localhost>; Tue, 17 Sep 2002 23:30:37 +0100 (IST)
from jalapeno [127.0.0.1]
	by localhost with IMAP (fetchmail-5.9.0)
	for jm@localhost (single-drop); Tue, 17 Sep 2002 23:30:38 +0100 (IST)
from proton.pathname.com
    (adsl-216-103-211-240.dsl.snfc21.pacbell.net [216.103.211.240]) by
    dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id g8HKVLC25673 for
    <jm@jmason.org>; Tue, 17 Sep 2002 21:31:21 +0100
from quinlan by proton.pathname.com with local (Exim 3.35 #1
    (Debian)) id 17rP0f-0004fo-00; Tue, 17 Sep 2002 13:31:49 -0700
Re: [SAdev] Re: [SAtalk] SpamAssassin and unconfirmed.dsbl.org
yyyy@spamassassin.taint.org's message of "Tue, 17 Sep 2002 15:20:49 +0100"
From quinlan@pathname.com  Tue Sep 17 23:30:38 2002

jm@jmason.org (Justin Mason) writes:
> Folks who've been hacking on the DNSBLs: would it be worthwhile commenting
> this in HEAD, seeing as it only gets .77 anyway?
>
> Sounds like the (a) broken server and (b) low hitrate combine to make it
> not-so-useful IMO.
No, in my opinion, it's purely a bug in SA (or the libraries we use,
which is the same thing) that we don't handle outages of network
services better.
The rule is useful and it does help reduce spam, we should keep it.  I
have a feeling the DNSBL rules will cluster a bit more heavily around
the 1.0 to 2.0 range once we start using the new GA on them.
Also, 0.77 was a slightly conservative number.  Since I didn't have
real-time data, I typically used the lower or median number of different
periods (most recent month, two months, six months), depending on the
trend of the period data (better performance for recent messages ->
favor recent scores, worse performance for recent messages -> favor
lowest scores, never pick the highest number unless the rule was very
accurate and the highest number was for the most recent data).
Dan