[Spambayes] Email client integration -- what's needed?

Tim@mail.powweb.com Tim@mail.powweb.com
Mon Nov 4 17:09:14 2002


It occurs to me that there are a couple of issues floating around here 
regarding integration with email clients, and they're related, 
although the relationship hasn't been brought forward yet.

Issue #1 Using proxys (POP3 and SMTP) for integration into the mailers 
that the masses use.

Issue #2 Putting a user interface onto the pop3proxy


So here goes:

I've been running an SMTP proxy that recognizes mail being sent to 
special addresses and does a train using the message, rather than send 
it to the actual SMTP server.  This works very well, though it 
requires a rather arduous training regimen to get it all started. 
::sigh::  Richie's pop3proxy then picks up the training to classify 
incoming mail, which is filtered into spam by my mailer's standard 
filtering mechanism.  There are two problems with this approach.  
First, it's manual, message-by-message, which means *re-training* is 
kinda out of the question.  The second is that the 'Forward' or 
'Redirect' function of most mailers strips at least some of the 
headers in which valuable clues can be found.

So... some have proposed that we make the pop3proxy so that it caches 
incoming mail.  This cache could be used by the smtpproxy to recover 
the original headers, using a unique id that the pop3proxy embedded in 
the mail somewhere.  Or... we could give the pop3proxy a user 
interface that allows users to select mail in the cache to do training 
on.  This approach eliminates the need for the smtpproxy in the first 
place, and allows a corpus to be built up by the proxy for retraining 
purposes.  While the ui for a caching pop3 proxy might be a bit of a 
challenge, I think this approach bears some examination.

Arguments for:

* Simpler overall system
* Allows the building of an easily usable corpus for average mail 
users like me
* Headers are maintained exactly as they were received, before a 
mailer has the chance to get in and mess 'em up

Arguments against:

* A new user interface that is not a normal part of a user's everyday 
existence
* Now documentation will have to include "User's Guide" as well as 
"Install Guide"
* Some ongoing cache maintenance... expiry of cached messages, etc.

Other considerations?

P.S.   How's this, Skip?

- TimS