That's interesting. I'll look into it. What I don't see anywhere, though, is the notion of the elimination of spam through comparison of messages in different mailboxes. Most of the algorithms I have found so-far analyze a _single message to determine if it "looks like spam."
At 06:58 PM 4/7/02 -0700, Bart Schaefer wrote: >Been away on vacation and just caught up with this ... > >On Wed, 3 Apr 2002, Sundial Services International, Inc. wrote: > >> In other words, this script is going to connect through POP3 to the other >> mail server, get the text of all the pending mail (up to 5MB of data), >> compare and run it through the wringer, DELE the bad stuff, and exit. It'll >> do that about twice an hour. > >Rather than attempting to implement this entirely in Perl, I suggest that >you look at <http://www.tuxedo.org/~esr/fetchmail/>. It has a daemon mode >that will allow it to poll periodically, so you don't even need cron. > >Set up fetchmail to run periodically on the ISP, using the -m option (or >corresponding config file) to deliver the mail into procmail. Invoke >spamc from the procmail configuration as usual. If the message DOES NOT >get tagged as spam, use EXITCODE to cause procmail to exit with a nonzero >status; this will in turn cause fetchmail to leave the message, undeleted, >on the POP3 server. > >If the message IS tagged as spam, I strongly suggest that the procmail >config re-delivers it to a mailbox that can occasionally be checked for >"false positives." Filtering is not foolproof. > >The (large) hole in this scheme may be the behavior of fetchmail on the >nozero exit of procmail. It definitely won't DELE the message in that >case -- but it might also give up completely and not attempt to process >the rest of the mailbox. It's not clear from the documentation (and my >experience with fetchmail is rusty). However, fetchmail is open source >and it shouldn't be very difficult to modify it for this situation. > >Either way I think the result might be more efficient and reliable than >trying to build the equivalent entirely in Perl. > > Sundial Services International Inc. ============================================================= - Scottsdale AZ (480) 946-8259; fax (480) 874-2068 - Innovative solutions for complex database issues! - http://www.sundialservices.com/ - PGP public key at http://www.sundialservices.key/pgp.key _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
