[Spambayes] RE: Most Recently Received Email Not Filtered

[Mark Hammond]

> Ah, but SpamBayes does use the Spam field. :) It's used in 
> GetNewUnscoredMessageGenerator() to try to avoid processing a 
> message twice. 

I should have made the distinction clearer (and indeed, used the correct
terminology!)

MAPI has 'properties', and these can appear on almost any item.  While
folders themselves have properties, they generally don't hold 'metadata' for
the properties in the messages they contain.  MAPI itself doesn't need that
metadata - it makes no restriction on property types - different items could
have completely different data types for the same property.

Outlook presents a new 'UserProperties' concept.  These are a layer above
MAPI properties, but do use them.  Each 'UserProperty' value on an item is
stored as a MAPI property, but metadata about the UserProperty is also
stored in the folder - eg, the type of the property.

This allows Outlook to present a sane UI, for things like comparing field
values.  The field chooser, and formatting rules etc which allow you to take
actions based on 'properties') use Outlook 'UserProperties' - for a field to
appear in Outlook itself, it is not enough it have the MAPI property, it
must be correctly defined as an Outlook 'UserProperty'.

> I thought the reason SB did the Ensure was to 
> avoid the error that might be caused by doing a Restrict with 
> a user property that didn't exist. But, the only place I knew 
> for sure that this was done was in the new unscored message 
> generator. If that's the only place it's done, why Ensure at 
> all? [Apologies offered. I'm insatiably curious about these 
> things from an academic standpoint.]

The names of the functions try to make it clearer, especially given the
above context:

EnsureOutlookFieldsForFolder() tries to ensure the UserProperty (ie, the
'Outlook Field') is defined on the *folder*, not any particular item.  It
calls msgstore.DoesFolderHaveOutlookField() - again, the 'Outlook Field'
part of the name tries to imply other than a normal MAPI property.

If we determine the folder does not have the field, then we must create it -
and the only way to do that is via the Outlook object model, and by creating
the UserProperty on an item, with a special flag saying 'also add this to
the folder'.  To do this, we create a temp item, create the property, then
nuke it.  In previous versions, we simply used an existing item in the
folder, and this process nuked the spam score - leading to the bug.

Hope that makes some sense...

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2944 bytes
Desc: not available
Url : http://mail.python.org/pipermail/spambayes/attachments/20040216/19906df8/winmail-0001.bin