views:

35

answers:

1

Hi,

I'm building an application that analyzes Outlook email messages, stores the analyzed information, and later allows the user to open messages meeting certain criteria.

I expected that I would extract the Message-ID from each email, store this in my database, and then ask Outlook to open up a message by providing it with the Message-ID at a later point. However, it would seem that I'm missing something.

Via the Outlook interop APIs, I can get an EntryID, but as far as I can tell, an EntryID is only guaranteed to be stable within a given folder (or maybe a given store). If a message is moved to a different folder, the EntryID may change. Additionally, the APIs require that the StoreID is provided when looking up a message by EntryID. Again, if a message is moved between stores, that information will presumably be invalid.

I've seen plenty of Office-related products that seem to do something like what I've described above. How can I do an efficient look-up of a message that is accessible to Outlook, regardless of stores etc.?

Currently, my back-up plan is to store EntryID and StoreID information for each Message-ID that I scan, and then try all the various EntryID / StoreID combos that I've recorded for a given MessageID until one is successful. But this seems like work that Outlook should already know how to accomplish for me.

Thanks,

-Patrick

A: 

"But this seems like work that Outlook should already know how to accomplish for me"

It should. But it doesn't. At least, when I used the API, I didn't find any obvious one. Maybe the reason is quite simple: Message-ID is meaningless for Outlook itself, so saving it as a property was never implemented in the product.

Now, I think the most obvious way is to do the thing you are already doing, ie. storing associations between Message-ID and StoreID - EntryID pair. This will let you access the desired e-mail quickly without walking through the list of every stored mail. Now, you must obviously check if the Message-ID is still correct, and if it is not, looping through every mail.

By the way, I don't understand well why are you storing several StoreID - EntryID pairs for each Message-ID. I suppose that the mail would be stored only once in Outlook, so one pair per Message-ID is enough. When this pair is obsolete (mail moved to another folder/store), you just update it.

Note: wouldn't it be easier and faster to access CreationTime and MailItem.SenderEmailAddress properties? It would be strange to see two different mails sharing those properties, so it is somehow a way to uniquely identify a mail, without having to extract manually the Message-ID.

MainMa
I already have other needs for a separate database, so the particulars of where I store a Message-ID => List<EntryID> mapping is somewhat arbitrary.Also, mail messages already have a GUID -- the value of their Message-ID header. My dilemma is that I don't see any obvious way to look up an Outlook MailItem object given a GUID.
Patrick Linskey
Ok, I see I misunderstood your question, so my answer was completely wrong. I edited it; hope it helps now.
MainMa
I'm storing multiple StoreId/EntryID pairs right now in case I somehow miss an event that causes a message to be moved. For example, if a message is moved in an Exchange mailbox on the server side, I expect to pick it up in the new location in a new message event notification, but I haven't tested whether or not I'll get a notification of where it was moved from. Also, a message with a given ID might be copied to multiple mailboxes; they're still the same message (since mail items are immutable by nature).
Patrick Linskey
CreationTime and SenderEmailAddress definitely should be close enough to unique. Is there a good way to look up a message by CreationTime and SenderEmailAddress across all stores? Note that I'm an Outlook Interop newbie, so if there's something obvious that you think I should know of, odds are I don't.
Patrick Linskey
"Is there a good way to look up a message by CreationTime and SenderEmailAddress across all stores?" - other than loop through the messages and retrieve the properties for each? I don't think so. LINQ would be helpful, but I don't remember if you can LINQ Outlook messages. Also, parallel extensions can further optimize performance (or not). Or you can also read PST files directly: http://blogs.msdn.com/b/interoperability/archive/2010/05/24/two-open-source-projects-to-facilitate-interoperability-with-outlook-pst-data-files.aspx Sorry, it was a joke. ;)
MainMa