Re: AWL pokes, and SAGray.pm

[Justin Mason <jm...@jmason.org>]

-----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-----

Re: AWL pokes, and SAGray.pm

["Eric A. Hall" <eh...@ehsco.com>]

On 6/15/2005 3:20 PM, Justin Mason wrote:

> 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).

I don't disagree that it would be handy in general, but I'm not sure it's
useful strategy for this plugin given some of the synchronization issues
at play here. In particular, AWL runs after all of the eval rules, and
that is too late in the cycle for my rule to update the message.

This is kind of tricky. On the one hand, the plugin needs to run after all
of the other eval tests so that it can get the current spam score. But if
it is going to assign a booster score to the message (+1.0 for being
first-time spam from unknown source, and getting the outcome recorded in
the appropriate header field), then it also needs to run before the end of
the message processing so that SA is still in a position to modify the
score (and the underlying message) appropriately. This means it has to be
pretty much the last rule to run, which is proving to be pretty
challenging in its own right.

On top of that it also has to pull data from the AWL database, but without
allowing AWL to actually run against the message (it would be too late for
my eval rule to update the message at that point). Therefore, the easiest
way for me to find out if the message has been seen by AWL is to just ask
AWL directly, using the exposed method (but that doesn't seem to be
working, for reasons unknown).

So I agree with you as to general utility, but it won't really help with
this plugin. I need to get the AWL method figured out, and I need to get
the timing factors figured out (eg, how do I make the rule be last). I'm
stuck on both of those, although I'll readily admit that I'm not really
trying very hard either, since I've got other stuff to work on.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/