On Fri, 2 Jan 2004 15:45:11 +0100, Jonas Eckerman wrote:

>  Put a generic "call external application" hook into SA. This

Thoght more about this. With something like bogofilter, one might want to call the 
user routine(s) twice. Once after all the scring, to implement autoloearnig. A very 
simple architecture for that kind of extensions could be like this (straight from my 
head):

User extensions muist reside in files called something.sax (for SpamAssasin 
eXtension). The files are checked for in the same directories as SA checks for 
ordinary rule files. Each file must contain at least one function with a predefined 
name. Like this stripped example:

--8<--
# My User Function, v0.00 a0
# A nice SAX

sub spamassassin_extension {
        my $state = shift;
    if ($state eq 'register') { # gives SA the opportunity to do a minimal test of 
functionality
                return (1, 'MY_USER_FUNCTION', undef); # boolean false if errors, this 
functions name, capability info (unused for now)values
        } elsif ($state eq 'work') {
            my $mailfile = shift;
                # do your stuff
                if ($was_spam) {
                        return ($no_errors, $was_a_hit, 'MY_RULE_SPAM') # boolean 
false if errors, boolean true if match, rule name to use
                } elsif ($was_ham) {
                        return ($no_errors, $was_a_hit, 'MY_RULE_HAM') # boolean false 
if errors, boolean true if match, rule name to use
                };
                return ($no_errors, 0, "") # boolean false if errors, boolean true if 
match, rule name to use (no name means SA forgets about the result)
        } elsif ($state eq 'result') {
            my $mailfile = shift;
                my $is_spam = shift;
                my $score = shift;
                # do stuff, like bogofilter learning for example.
                return ($no_error, undef, undef); # boolean false if errors,  unused, 
unused
        }
        return 0; #boolean, false because we didn't know what to do with this state.
}
1;
--8<--

The rule name could be automagically prefixed with SAX_ (or something else if SA 
allready uses SAX_ for something) by SA to avoid collisions with built in rules.

In the rule definition you the specify something like:

# Without this, SA will simply not call the function
sax                     MY_USER_FUNCTION                1
describe                SAX_MY_RULE_SPAM        My user function thinks this is spam.
describe                SAX_MY_RULE_HAM         My user function thinks this is ham.
score                   SAX_MY_RULE_SPAM        2.0
score                   SAX_MY_RULE_HAM         -2.0

This is plenty enough for calling external filters that works on complete mails, while 
still beeing pretty simple and easy to maintain.

This thing could be made simpler yet of course, but I think external functions should 
be able to hit more than one rule without having to be called more than once.

And an important note: This is from my head without close study of SA. A close study 
of SA might well change my ideas for a suitable extension mechanism radically.

Currently I allready have a lot to do, but once I get more time on my hands I might 
take a look at actually implementing something like this and creating a patch for it.

Regards
/Jonas
--
Jonas Eckerman, [EMAIL PROTECTED]
http://www.fsdb.org/



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to