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

Tim@mail.powweb.com Tim@mail.powweb.com
Fri Nov 1 23:02:29 2002

This proposal has a lot of attractions.  Forwarding to ham@ and spam@ would be a bit of a pain at first, but it would work for existing bodies of mail.  Training 
would be MUCH simpler with this method, and would not require some fancy-schmancy installation or configuration glorp.

Multiple pop account management is a requirement for sure.  I'd say most people that use pop use more than one.

Non-pop users?  There might be < 362 on non-windoze platform, but count web-mail in, and the vast majority of them are non-pop users...  We're not going to 
be able to help them directly, we'll need to do some server-side enablement somehow.  Perhaps a spambayes web-mail system is called for... who knows... 
not my itch.

- Tim

11/1/2002 4:55:00 PM, "Sean True" <seant@iname.com> wrote:

>> Yup!  Thanks to Sean and especially Mark lately, the non-Windows platforms
>> are a month behind on that too.  It's a curious thing about Windows:
>> because it is closed-source, the Windows market is homogenous enough that
>> one major effort there can make millions of happy campers.  I still hope
>> that the pop3proxy can do that for non-Windows systems too, and that's the
>> only advice I can offer:  find a way to use the proxy instead of pursuing
>> "deep integration" with unbounded dozens of quirky twenty-user email
>> clients.
>Mark, mostly. I just complain.
>I'd like to second the pop3proxy architecture as the way forward. If it
>weren't for the fact that virus scanners weren't already sometimes adding
>both pop3 and smtp proxies to the mix on Windows,
>I would have pushed (er, whined) in favor of that architecture even for
>Outlook. (There is also the problem of how to configure proxies for the case
>of multiple pop3 accounts). You can mangle the host, user, and password
>together in a horrible looking user name, but it is really a pain.
>Nonetheless, it has a relatively clean API, and the same architecture could
>be used to proxy SMTP output traffic, catching messages to ham@wherever and
>spam@wherever, in order to talk to the training
>system. The same code then might run pretty happily on both the client and
>the server, depending on the needs of the installation.
>-- Sean
>Spambayes mailing list
- Tim