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

Tim Peters tim.one@comcast.net
Sun Nov 3 19:27:08 2002

[Robin Munn]
> ...
> something that could integrate into, say, Outlook Express and add
> a "Block this junk mail" button (which adds the message to the spam
> corpus) to the E-mail reading interface.

AFAIK, Outlook Express has no hooks at all for programmers -- it's a closed
end-user app (as opposed to Outlook, which is highly programmable).  OTOH,
OE's file format is relatively easy to reverse-engineer (again unlike
Outlook's), which gives some hope for a separate process to watch what the
user does indirectly.  I doubt there's any way to filter incoming mail in OE
short of having the user (1) redirect to a pop3 proxy, and (2) set up an OE
rule to look for a header injected by the proxy.

> ...
> 1. It must integrate into the user's email client as seamlessly as
> possible. This means researching the plugin API of Outlook, Eudora,
> Pegasus Mail, Mozilla, et al.

If you're interested in the masses, you could make life easier by
restricting this to clients actually used by the masses <wink>.

> 2. The algorithm and filtering component must also run in the background
> without any user intervention required after the initial install. This
> means being able to install as a Windows NT service or into the StartUp
> folder of Windows 9x.

The current Outlook 2000 client runs as an in-process server, via COM.  That
means it starts up automatically whenever the user starts Outlook, and
closes itself down when the user quits Outlook.  IOW, services and startup
groups aren't required for Outlook integration.  They may be for OE, but
nobody here has shown a sign of looking at an OE approach (appart from
Richie Hindle, who had OE in mind when he wrote pop3proxy -- although this
may be news to him <wink>).

> 3. There *MUST* be good documentation. We all know the user is going to
> run the installer program before reading the documentation, but we must
> include a "How to train your filter to recognize junk mail" document
> that the installer displays after finishing installation. This means
> actually writing said documentation. :-)

OTOH, the masses don't read docs.  In a previous life I worked at a company
doing commercial software "for the masses", and doing usability testing for
mass use is extremely time-consuming and expensive.  The masses don't see
what techies see when they look at a UI, they don't read docs, and they do
very surprising things.  One of my sisters suffered a network outage at
work, and, in frustration, picked up her keyboard and slammed it on her
desk.  The network happened to come back up again then.  I won't say any
more, apart from noting that she has an ongoing problem with broken
keyboards <wink>.