MailItem pointers not returned for SMIME messages in OL2003

[Matt Fletcher]

I posted a message last week about NameSpace::GetItemFromID failing on a
specific machine. I have since reproduced the problem on other machines and
identified its cause: neither NameSpace::GetItemFromID nor
MAPIFolder::Items::Item will return a MailItem pointer for an SMIME message,
even after the appropriate password has been supplied.

Is this a known OL2003 bug, or is it an undocumented "security feature"?

(I have also discovered a work-around - MailItem pointers will be returned
if registry based custom form redirection is used to change the message
class of SMIME mail items to an arbitrary class - e.g. in
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Custom Forms\Read I
have created a binary value named IPM.Note.SMIME whose value is
IPM.Note.Junk.SMIME. This workaround looks like it is exploiting a second
quirk in Outlook's handling of SMIME messages).

Matt Fletcher

 

[Ken Slovak - [MVP - Outlook]]

You can use an Object instead of a MailItem and check for MessageClass
before you assign the item to a MailItem. Check for IPM.Note.SMIME as
MessageClass and handle those separately from standard non-SMIME messages.

 

[Matt Fletcher]

More information - the dispatch pointer that is returned is in fact a
pointer to the MailItem coclass (00061033-0000-0000-C000-000000000046), when
it should be a pointer to the _MailItem interface
(00063034-0000-0000-C000-000000000046). My COM understanding is not quite
good enough to get from the coclass to the interface, if indeed it is
possible.

Also, the problem affects ItemEvents::ItemAdd as well - it looks like a
general problem with any function/event that returns/passes a pointer to an
unopened SMIME message. (However, it does appear to be only unopened
messages, as Inspector::GetCurrentItem works OK).

Oh, and my workaround does fix the problem but at an unacceptable price
(one-offing programmatic custom form changes when forwarding a message).

Any clues most welcome.
Matt Fletcher

 

[Matt Fletcher]

Ken,

thanks for the reply - I posted my further comments before I had retrieved
your reply.

I'm working in C++ rather than VB so I can't treat the pointer as an Object.
I also suspect that this might not work given what I have discovered about
the pointer - but again my COM knowledge is not good enough to be certain of
this.

I want the _MailItem pointer in order to call the Display method to open the
incoming item. I can't see any other elegant way to do this - may need to
try sending keystrokes.

Matt Fletcher

 

[Ken Slovak - [MVP - Outlook]]

I can't answer C++ specific questions. In VB using an Object would work. How
you would do the equivalent (if you can) in C++ I have no idea. The thing is
to not use a specific object type, which in VB is referred to as early
binding, but to use a general object that can be anything (late binding).

 

[Matt Fletcher]

Ken,

have you got any suggestions as to where I can get further (C++ aware) help
with this problem? I'm pretty convinced it's a bug in OL2003 and I need to
find a way round it.

thanks
Matt Fletcher

 

[Ken Slovak - [MVP - Outlook]]

I asked another Outlook MVP who does C++ programming to look into this
thread and lend a hand. Let's see what he says.