[Spambayes] Re: Important information for Outlook users

[Mark Hammond]

> In my case I found it necessary to do some manual cleanup and ensure
> that I didn't have any other folders with that attribute (e.g., I
> didn't catch that I had some scored messages in my Deleted folder).
> That could be from not deregistering the addin first.

I'll try and get back to the meat of this later, but I saw Paul mention her
was fairly sure unregistering the addin had some effect.

I am fairly certain that unregistering the adding will have zero effect on
any of the field workings.

I'll try and summarize here my understanding of the field mechanism.

Terminology:

Extended MAPI is a complicated, low-level COM based API for messaging.  It
is generally only available via C++, as it has no type library, and uses
very complicated memory management.  Python bindings for this exist which
almost make it seem usable.  This is the cornerstone of Exchange (Server and
Client) and also the Outlook client.  It is built for speed and flexibility.
It achieves both at the cost of complexity.

CDO, which used to be known as MAPI (<frown> - hence "Extended" as added
above) is an IDispatch COM based interface to Extended MAPI.  It was created
so VB and other scripting language could use this API.

Outlook now comes with its own COM, IDispatch based object model.  It is
richer than CDO in non-messaging related functions.  Outlook fully
implements Extended MAPI (both as its own message store, and connecting to
other MAPI providers such as exchange).  Outlook supports CDO as a
by-product of supporting extended MAPI, but CDO is officially "deprecated"
for this.

SpamBayes:

The SpamBayes outlook plugin does almost everything via Extended MAPI.  It
does not use CDO at all.  The Outlook object model is used only for this
field mess, and for User Interface and New Message event handling.

Properties:

Extended MAPI/CDO have a rich property system.  User defined "property
names" can be created with a fairly global name-to-ID mapping.  Any
individual item in the message store can have any set of properties
associated with it - including these user defined properties.

These properties have an interesting type system - although the name-to-ID
mapping is global, each instance of a property can potentially have a
different type.  In practice, the same type is used for a given ID.  MAPI
has no concept of a "property format" - just an ID and type.

Thus, for any and every message in your store, it is possible to have a
field called "Spam", all of which share the same ID, but having different
types.  And indeed, I recently changed the type that new properties of this
ID are written with.

Outlook itself has a richer model for "User Defined Fields".  A User Defined
Field, as you can see from the UI, has more "user oriented" data types (eg,
formulas, both "number" and "percent", etc).  It also introduces the concept
of a "Format", and introduces the concept of "adding the field to the
folder".  Although Outlook does indeed store each individual message's
user-defined property value as a MAPI property, it is not documented (nor
yet discoverable by me) how MAPI properties and these other extended Outlook
concepts fit together.

So, what is this means is:  The plugin successfully uses MAPI properties for
all filtering and scoring purposes.  This appears to always correctly set
the field for each individual message item processed by the plugin.
Unfortunately, for concepts not covered by MAPI, such as the fields in the
Field Chooser list, we must revert to Outlook, and this model doesn't work
too well.  To make matters worse, deleting a field from the Outlook UI does
*not* change *any* existing messages - it only changes this undocumented
Outlook specific extension to the model - ie, all existing MAPI properties
remain unchanged.

So, at the end of the day, the plugin has zero effect on any of this.  The
definition of MAPI properties, and of Outlook user-defined fields is quite
independent of the plugin.  Uninstalling the plugin will leave all
properties and fields in exactly the same state.  A stand-alone script can,
and does, create such fields, and these fields exist well after the script
has finished/been-deleted/whatever.

Hope this makes some sense - well, as much sense to you as it does to me
<wink>

Mark