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

[Piers Haken]

it would seem to me that instead of trying to cram these message store
capabilities into a protocol that just doesn't support it (POP3), why
not use a protocol that does (IMAP4)?

i'd suggest writing a simple IMAP 'proxy' (possibly single-user) that
retrieves messages from a 'real' mail server via POP3, scans the
incoming messages, classifies them, then puts them in the corresponding
folders. the IMAP server can then reclassify/retrain on the messages
when they are moved between folders (just as the outlook plugin does).

piers.

-----Original Message-----
From: Tim@mail.powweb.com [mailto:Tim@mail.powweb.com]
Sent: Sunday, November 03, 2002 2:38 PM
To: Spambayes
Subject: Re: [Spambayes] Email client integration -- what's needed?


Yeah, forward generally loses headers... My mailer has a redirect
function, which sends the entire thing, headers and all... much better
for this kind of thing.

So this leaves us back at the question of training a database with
mailers that do not provide for the export of mail into file system
artifacts.  Most mailers do 
only have a forward function, which lops off most of the headers... the
smtp could use the mail cached by the pop3proxy, assuming it is
running... which 
makes me believe that perhaps the pop3proxy and smtpproxy should be
different threads on the same process.  That way, users don't have to
have two 
processes running, and the two sides of the equation can more easily
keep themselves in sync.

- TimS

11/3/2002 10:41:59 AM, Richie Hindle <richie@entrian.com> wrote:

>Hi Toby,
>
>> Forwarding to spam@ or ham@ has some disadvantages because the
forwarding 
>> process destroys some information. Most mail clients dont forward
headers. 
>
>The inbound part (pop3proxy, hammie, the Outlook stuff, whatever) could
>cache the messages, then the SMTP proxy could compare the forwarded
>messages with the cache (somehow - there'd be no Message-Id to compare)
to
>find the original to train against.
>
>You're right - losing headers will make a difference, even with the
fairly
>minimal header tokenising we currently do.  When I added the Unsure
>classification to pop3proxy, I tested it by forwarding a bunch of spams
to
>myself and they all came out Unsure where they had been Yes before - at
>first I thought it was a bug, but then a couple of genuine spams rolled
in
>and were classified correctly.
>
>-- 
>Richie Hindle
>richie@entrian.com
>
>
>_______________________________________________
>Spambayes mailing list
>Spambayes@python.org
>http://mail.python.org/mailman/listinfo/spambayes
>
>
- Tim
www.fourstonesExpressions.com 



_______________________________________________
Spambayes mailing list
Spambayes@python.org
http://mail.python.org/mailman/listinfo/spambayes