[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