-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric A. Hall writes: > I'm looking to do a quick-n-dirty plugin that: > > 1) reads the spam threshold score from config (eg, default is "5.0") > > 2) reads the spam score for the current message > > 3) compares if the current score is greater than the threshold score, > > AND if the auto-whitelist learner has not seen this sender tuple > > 4) append header field that says probable spam from unknown sender > > The purpose of this is to allow my MTA to defer accepting messages that > have this header field, providing a psuedo-greylisting feature that is > keyed to spamassassin score which reuses the AWL tracking. Using this > approach, I can do selective keying on spam instead of everybody (thus > minimizing collateral damage to the honest mail systems that don't respond > well to greylisting), and can avoid implementing yet-another tracking > system (if I can get away with reusing AWL). > > [I should state the obligitory -- this module won't do much for people who > call SA from procmail. But in my setup, postfix is calling spamassassin > during the transfer process and I'm currently rejecting spam over 8.0, and > rerouting mail in the 5.0-8.0 range to a per-user "Junk mail" folder for > quarantine. This module would simply defer mail in the 5.0-8.0 range the > first time they try, while subsequent transfers would be quarantined as > current behavior.] > > Looking through the permsgstatus docs, getting the threshold and current > spam score values looks pretty simple. But there doesn't seem to be much > support for working with the AWL system, and I'm looking for suggestions > here. I don't want to manipulate the database since it may not exist > (maybe its using SQL storage or something). > > What I specifically need from AWL is number of instances for the current > sender tuple, with the value of "one" (for the current message) being the > magic number. Any suggestions would be appreciated. Eric -- you may have to patch the AutoWhitelist class to throw those numbers into variables hanging off the PerMsgStatus object. Then the plugin can access those values safely. I'd be +1 on applying a patch that simply sets a variable or two on the PerMsgStatus object as the AWL logic is run, that wouldn't have any noticeable effect during normal use (and it seems handy in general). - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFCsH9sMJF5cimLx9ARAv1fAKCxMoeG9ywtj/3ytJizPq56tN1p+QCeNpW7 lwgYzTwFBl3+KWDRbfkEljU= =5f6D -----END PGP SIGNATURE-----
