Outlook NewMail event unleashed: the challenge (NewMail, NewMailEx, ItemAdd)

A while ago Eugene asked me whether I would be interested at taking an in-depth look at how to effectively handle a new mail in Microsoft Outlook. I mean how hard could it be? We have the NewMail and NewMailEx events and if all else fails we can use the Folder Item Add event, right?

Well, unfortunately things are just not that simple. Let’s have a look at the events that might provide us with what we need.

NewMail event

This event fires when one or more new mail messages arrive in the users’ Inbox. It does not give us any access to the mail or mails that arrived, which is a little bit silly to be honest. Another thing that Microsoft fails to mention is that when you receive 16 or more items at once, the event does not even fire.

To Microsoft’s credit when receiving e-mail via a POP3 account, you can generally get away with using this event, because with a POP3 account it looks like Outlook processes the e-mails one at a time. This is, however, not the case with an Exchange based account where e-mails arrive in bulk.

You can read more about this event in Outlook 2007 on MSDN. The MSDN article for Outlook 2010 can be found here: Application.NewMail Event (Outlook).

Items ItemAdd event

One cannot be blamed for thinking that using the ItemsAdd event in order to track e-mails that are added to the Inbox, would work flawlessly. Unfortunately similar to the NewMail event, this event does not work well with large number of items. I’ve tested this event and like clockwork it only processes 16 items at a time. Anything above the 16 items and the event will not be raised.

This can be a serious blow to any add-in that was built to process new e-mails, because as soon as volume of your user’s e-mails increases, your add-in won’t work!

This problem has been around for a long time. In fact at least 8 years, as you can see from this Microsoft article.

NewMailEx event

NewMailEx is similar to the NewMail event, but occurs not just when an e-mail arrives in the Inbox but any MailItems, MeetingItems and SharingItems. NewMailEx also beats NewMail due to the fact that it allows us access to the items that were received by passing an array of the items’ EntryIDs as a parameter.

From the surface it looks as if the NewMailEx event is the answer to all out NewMail woes, but unfortunately all is not as it seems. When I tested the NewMailEx event with a POP3 account, I’ve sent myself e-mails starting with about 10 at a time and managed to get all 10 entry ids. When I increased to number of mails to 1,000+ things got a bit more erratic. I did get most of the entry ids of the new e-mails, however a few went missing.

When testing the NewMailEx event on MS Exchange server, in cached mode, things really start to get unpredictable. The event does fire, but I only see one entry id in the EntryIDCollection parameter, this despite the fact that I received about 100 new e-mail messages. If you are running Exchange in non-Cached mode the event will only fire as long as Outlook is running when a new e-mail arrives. If you close and re-open Outlook, all the e-mails that were in the queue waiting to be delivered will appear in Outlook but the event will not fire.

Read more about the Outlook 2007 and 2010 events on MSDN.

After doing some extensive research on the NewMailEx and ItemAdd events and methods of effectively handling new e-mails in Outlook, it became clear to me that this is a common problem faced by many Outlook developers, so at least I was not alone.

Luckily I have some good news, in the coming weeks, with the help of the Add-in Express dream team; we’ll take a look at possible solutions to the problem and reveal them in a series of blog posts.

So hold on to your hats, it’s going to be a wild ride!

Outlook NewMail unleashed:

• Part 1. The challenge
• Part 2. Outlook NewMail solution options
• Part 3. NewMail event and Extended MAPI
• Part 4. Writing your custom solution to the NewMail problem (C# example)