S/MIME Magic

I know it's been a while since I posted (for all my loyal fans!) but my wife and I had a baby last month, so we've been busy with him. Jacob Matthew is a great kid though, so I'm not apologizing, just giving you an explanation! On to business...

So recently I had a case where the customer was using the Outlook Object Model to parse messages in his Inbox. That's a pretty normal thing do I thought. His problem that was on certain S/MIME (Secure MIME) messages, the Outlook Object Model bombed. Upon investigation it turned out that it was when he was accessing the Body property that the exception was thrown. So like any other Developer Support Engineer in the Messaging and Collaboration team, I cracked that message open with our favorite tool, MFCMapi, written by my colleague, the renowned Stephen Griffin. Not only is the guy a MAPI genious, he also seems to remember every TV show or movie he has ever seen and who was in it.

Back to the story...

So there I was knee-deep in MFCMAPI and I'm looking at this message. I have some other S/MIME messages in my mailbox so I can compare them. So as I'm looking at the PR_ props of my problem message and I notice that I don't see the PR_HTML property...in a flutter of panic, I look for the PR_BODY property...nothing. Well, that's ok, often times messages get stuffed into the PR_RTF_COMPRESSED property. And that would be fine and good, except that that property was missing also. DUN DUN DUUUUNNNN...

So where is the message? I can see it in Outlook, but it doesn't appear to be in any properties in the MAPI message.

Then it hit me...this message carries a copy of itself in a hidden attachment called smime.p7m. This helps ensure that the message content does not change since whoever signed the message originally originally signed the message. I opened up the attachment and sure enough, the content of the message was in a property called PR_ATTACHMENT_DATA_OBJ. Well that clears up one mystery. This doesn't necessarily explain why the Outlook Object Model throws an exception.

Well, this story doesn't have a really happy ending. I'm not sure why the Body property fails...I know that it happens in source when the HTML stream is being copied into the Text stream, but that's all I know. What I do know is that the HTMLBody works. So if you find an exception gets thrown when you are trying to access the Body property on a message object, try hitting the HTMLBody property as a backup and strip out the HTML tags yourself using regular expressions or something like that.