• Wiz/dumb

    What am I gonna do with 40 subscriptions to http://Vibe?

    • 1 Comments

    So this is a scenario you could easily find yourself in as one of my larger customers did recently. The answer is also one of the less-obvious, more obvious of answers. So imagine the scenario: you have load balanced Exchange FE (front end) boxes serving a myriad of back ends. Or, in a slightly less dramatic scenario, you have a stand-alone box with a few mailbox stores on it....In either case, or several in between, the problem may surface. You are writing an application that uses the WebDAV subscription/call-back notification capabilities of Exchange to monitor for updates to certain folders in certain mailboxes. Your application has a list of paths to subscribe to (http://email.domain.com/Exchange/mailbox1/Calendar, http://email.domain.com/Exchange/mailbox2/Calendar, etc). As it rolls through the subscription list, you notice that the subscription-id header you are returned appears to be a duplicate!

    Well this just won't do. How will your application be able to effectively know what folder issued the notification when the subscription-id now seems apparently ambiguous. The answer, my friend, is the OTHER header you are returned...subscribe-group. Subscribe-group is the base64-encoded GUID of your store. Subscriptions are managed per store which means if you have more than one store on a box, or more than one back end Exchange server, you have more than one subscription list being maintained. The only way to distinguish between them is to capture the subscribe-group header in addition to subscription-id. The NOTIFY on callback will provide you with both and so will the response to your SUBSCRIBE request, so you should be good to go. You will already implicitly know what store you are talking to when you POLL, so the subscribe-group does not need to be echoed to the server. Subscribe-group only helps the client application know which subscription it is receiving a call back for.

  • Wiz/dumb

    S/MIME Magic

    • 0 Comments

    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.

Page 1 of 1 (2 items)