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

[Tim@mail.powweb.com]

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