[Spambayes] Email client integration -- what's needed?
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.
11/1/2002 4:55:00 PM, "Sean True" <firstname.lastname@example.org> 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
>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.
>Spambayes mailing list