[Spambayes] Plugins, user extensions, Spambayes/SpamAtBay -- was 'Whitelisting'

[Sean True]

> I believe that Sean is also working on some sort of grand 
> super master filtering system that would be able to integrate 
> different filters, including a white list and spambayes.  You 
> could probably also use Outlook's rules to move 'white listed' 
> mail out of the reach of spambayes, particularly using the 
> timer option.
>  
> =Tony Meyer
> 

OK, that's Sean and _Mark_ (with any luck, don't know when that guy sleeps).

I have in mind a framework that would let a user add his own mail filtering
code (using, say, SPEWS or whatever), or would let Mark add a pretty
amazingly cool looking rules based system. The framework is intended to work
inside all Spambayes based Outlook add-ins, and would let Mark and my team
deal with the nasty Outlook interface while the more clever among us can
work on code that improves performance for every one.

The general scheme is:

A plug-in is placed in the users application data directory;
It is loaded by the outlook addin at startup;
It provides methods to be called at :

	startup 
	before message is scored
	after message is scored
	get status
	[user interface, still working on how to handle this one]
	shutdown

The before/after methods can do interesting things to/with the message,
including overriding or extending the normal behavior:

	* Move this message from hotmail inbox to my normal inbox 
	  (Outlook rules don't filter hotmail accounts)
	* Declare a message as spam, or not based on non-spambayes notions
	* Delete the message (if you want to delete all messages with
spamprob==100%,
	  this is an easy place to do it
	* Send/forward the message elsewhere
	* Reply with a vacation response

Here's the source for my hotmail plug-in:
============================================================================
======
#This plug-in moves all non spam messages arriving in Hotmail to the
standard Inbox
from pluginclass import MessagePluginBase, Message

class MessagePlugin(MessagePluginBase):

    def name(self,**options):
        return "Hotmail plug-in"

    def after(self, score, message,**options):
        # options["email"] has message as parsed by email package
        # options["config"] has a copy of the SB config object
        subject = options["email"]["Subject"]
        to = options["email"]["To"]
        ishotmail = to.endswith("@hotmail.com>")
        isnotspam =  (score < options["config"].unsure_threshold)
        print "===Checking '%s' '%s'" % (subject, to), ishotmail, isnotspam,
score, options["config"].unsure_threshold
        if ishotmail and isnotspam:
            print "===Moving Hotmail '%s' from '%s' to Inbox" % (subject,to)
            return[("move","\\inbox"),
                   ("skip", "ham")]
        return []
============================================================================
========

Multiple plug-ins are intended to cohabit nicely, so we can all use the
industrial strength rules module that Mark is thinking about, while
developing other speculative or personal code (It's a new moon, I'm going to
call it all spam today? Never spam-bucket a message with the word Python in
it? Spam-maybe anything with an all caps message?).

BTW, the timer based code that we installed for letting Outlook rules run
(which Mark is now implementing for SB) is working really well. A user at
ZopeCorp (Python labs parent) had a really bad time with both SB and
SpamAtBay until we got that working right. He had been lobbying hard for the
plug-in architecture so that he could reimplement his Outlook rules in
Python and not have to give up SB/SpamAtBay. After we got the timer code
working right, he stopped asking for the plug-in. ;-)

Anyone who would like to start developing plug-ins should contact me. Mark
and I are still exchanging design notes, but I know we will come to some
convergent point before long.

Note: people writing code for the SB framework are entitled to free
permanent licenses to SpamAtBay -- and the plug-in framework will get
contributed back to SB source when Mark feels it's up to snuff. So working
in the SpamAtBay environment should neither be expensive or exclusive.

Note: the SpamAtBay team does occasionally make improvements that go back
into SB -- but we generally filter everything through Mark. At this point I
think we have two of our bug fix/performance improvements in the code or
being conceptually incorporated. 
	
That turned out to be longer and more specific than I had intended. This
code is _really_ ripe yet, although I'm already using it in my own personal
production environment. By the time Mark thinks it's ripe, I bet it's darned
tasty.

-- Sean

Sean True and the SpamAtBay team.