SGriffin's MAPI Internals : MFCMAPI

Strange Looking NDR

Stephen Griffin — Thu, 12 Nov 2009 22:54:38 GMT

Not many people are aware of the feature, but MFCMAPI implements a MAPI Form Viewer. This means MFCMAPI can use MAPI to ask Outlook to display messages. You might have run into this if you ever double-click on a message in MFCMAPI. If you’re on a machine with Outlook installed, the message will open up like it does when you double-click it in Outlook. And if Outlook isn’t installed and you’re using Exchange’s MAPI, you get a scary dialog saying we couldn’t open the MAPI form manager.

This is one of those dark corners of MAPI into which few people tread, and most of those who do end up cribbing or parroting the Form Viewer implementation in MFCMAPI itself, meaning nearly every issue they report related to form viewers can be reproduced in MFCMAPI. Sometimes, this turns out to be a bug in my implementation, like an errant warning while clicking up and down through messages (fix coming very soon!). Other times, the problem is a bug in Outlook.

My latest customer’s issue turned out to be the latter case. They had noticed that when they tried to view NDR messages with their Form Viewer, the body of the message would be full of alien looking RTF text:

“{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fmodern\fcharset0 Consolas;}}
{\*\generator Riched20 12.0.6413.1000;}\viewkind4\uc1
\pard\fi-1440\li1440\tx1440\f0\fs21 Your message did not reach some or all of the intended recipients.\par
etc…”

What was really odd was that if you looked at the message in MFCMAPI, this text was no where to be found! And to top it off – if you opened the message from Outlook, you got the NDR message you expected.

So what was going on? It’s not surprising that Outlook builds the NDR text on the fly. It’s much easier to localize it that way. And the RTF does appear to be the underlying RTF we would generate for the NDR message. But why did we display it wrong, and why did Outlook display it right?

The key here is the LoadForm function. This function takes the message class of the form we want to load. Under the covers, LoadForm looks up the message class using ResolveMessageClass and gets the GUID for the associated class factory. The form manager then passes this GUID over to Outlook and asks for the class factory. This is where we have a problem. Outlook uses the same GUID for multiple form class factories, some of which have different attributes associated with them. The class factory we get has an attribute on it stating it should render using HTML, while the class factory we should have gotten did not have this attribute. So when it comes time to render the text, we use the wrong rendering method and get the ugly RTF text.

When Outlook opens the message, being the implementer of the forms, it gets to skip many of the MAPI steps. Instead of using the message class to look up a GUID, it uses the message class to look up the class factory directly, getting the right one in the process.

Based on the fact that this behavior has been unchanged for as long as we can trace back, and we’re only just now hearing of an issue with it, we chose not to fix this problem, but instead document it. So – here’s the documentation. Enjoy!

Announcing EWSEditor 1.5!

Stephen Griffin — Mon, 09 Nov 2009 20:18:55 GMT

Matt’s very excited about the release of EWSEditor. This tool does for EWS what MFCMAPI does for MAPI. With this tool, Matt does what I did with MFCMAPI and what I recommend to anyone trying to learn a new API: the best way to learn an API is to write tools that use it.

As you work with EWSEditor, you may notice a few things which are similar to MFCMAPI. This is no coincidence. EWS and MAPI, both designed primarily to interact with an Exchange server, share much of the same object hierarchy, which in turn dictates that tools designed to explore these hierarchies will be similar. Also, since we sit near each other and act as each other’s ad-hoc PMs, we borrow each other’s features. For instance, EWSEditor implements much of the same Smart View parsing as MFCMAPI, using the same logic, recoded from C++ to CSharp.

Of course, there’s one similarity between EWSEditor and MFCMAPI that has nothing to do with the underlying APIs or fancy features and everything to do with the fact that Matt and I are programmers, not icon designers. Look familiar?

Enjoy!

OpenStreamOnFile vs Unicode Files

Stephen Griffin — Tue, 29 Sep 2009 18:26:00 GMT

Let’s take a look at the function OpenStreamOnFile, which is exported by MAPI. Suppose you want to use this function to open a stream on a file that has a Unicode file name. As has been noted before, this doesn’t work. Why is this? According to the documentation, and according to the header, maputil.h, this function takes two parameters, lpszFileName and lpszPrefix, which are of type LPCTSTR. However, it is impossible for an exported function to take a parameter of this type. Why? Because LPCTSTR is a macro that compiles to either LPCSTR or LPCWSTR depending on whether Unicode was defined in the project. But MAPI’s the same no matter how you compiled your project, so the export won’t change.

In truth, OpenStreamOnFile should have been declared as taking parameters of type LPCSTR. We’re working on an update to the MSDN and to the MAPI Headers to fix that. We’ll also be documenting a new function, which you can go ahead and use to open files with Unicode names: OpenStreamOnFileW. This is the Unicode version of OpenStreamOnFile which takes Unicode strings. Here’s the signature:

STDMETHODIMP OpenStreamOnFileW(

   LPALLOCATEBUFFER lpAllocateBuffer,

   LPFREEBUFFER lpFreeBuffer,

   ULONG ulFlags,

   __in LPCWSTR lpszFileName,

   __in_opt LPCWSTR lpszPrefix,

   LPSTREAM FAR * lppStream);


typedef HRESULT (STDMETHODCALLTYPE FAR * LPOPENSTREAMONFILEW) (

   LPALLOCATEBUFFER lpAllocateBuffer,

   LPFREEBUFFER lpFreeBuffer,

   ULONG ulFlags,

   __in LPCWSTR lpszFileName,

   __in_opt LPCWSTR lpszPrefix,

   LPSTREAM FAR * lppStream);

Other than the change to the strings, the function is identical to OpenStreamOnFile. Officially, we’re only documenting this function for Outlook 2010 and higher, but the function is also there in Outlook 2003 and 2007. The Exchange MAPI Download does not implement OpenStreamOnFileW at all.

The November build of MFCMAPI is being augmented to handle Unicode file names. Part of that rewrite is that MFCMAPI will use OpenStreamOnFileW if it’s available, and fall back to OpenStreamOnFile if it’s not.

Enjoy!

September 2009 Release of MFCMAPI

Stephen Griffin — Thu, 10 Sep 2009 23:48:12 GMT

The September 2009 Release (build 6.0.0.1015) is live: http://mfcmapi.codeplex.com.

The July 2009 release was downloaded over 13 thousand times, with nearly 1700 of them being the 64 bit build. This was the most popular release yet – retiring MAPI Editor drove a lot of traffic over to codeplex.

I did a lot of work on the property and hex editors this time around. The property editor should be much better at editing large and complex streams you’ll find in PR_BODY or PR_RTF_COMPRESSED. And the Hex Editor is no longer modal! Now maybe Rick will stop bugging me about it.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

Ctrl+H will now bring up a non-modal Hex Editor
That “Sample version” text is now gone. There is only one version of MFCMAPI, and it’s what you get on codeplex
Embedded NULLs in strings no longer break the property and stream editors
All the editors (hex, property, stream) should be able to handle MUCH larger strings now
Smart View: Added parsing for PR_ADDITIONAL_REN_ENTRYIDS, dispidPropDefStream
Smart View: Added framework for Smart View parsing of multivalued properties, and added a bunch of previously unparsed properties.

Enjoy.

Exchange 2010 and the MAPI Download

Stephen Griffin — Wed, 02 Sep 2009 21:06:17 GMT

Bunches of people have contacted me asking if the MAPI download works with Exchange 2010. My usual response has been that I know it works, but you have to tweak the profile. I didn’t know the specific tweaks ‘cause I hadn’t looked in to it.

Dave Vespa just blogged those tweaks. Note that they’re very similar to the modifications we use with Exchange 2007 to get referral working. Also note that the profile Dave builds is not referral enabled, but this doesn’t matter any more. With Exchange 2010, MAPI always talks to the Client Access Server for both mailbox and directory. The dreaded DSProxy that we were trying to avoid in 2007 and earlier has been replaced by the Address Book Service, which is pretty much what DSProxy should have been.

Enjoy!

Outlook 2010 MAPI Reference Updated

Stephen Griffin — Tue, 01 Sep 2009 00:01:16 GMT

The Outlook 2010 MAPI Reference has been updated. I don’t have a list of everything that changed, so I’ll highlight one addition that’s pretty cool: the property definition stream. Long time readers might remember I mentioned this property before – it’s one of the properties you want to delete to kill a one-off form. It’s also the property that Outlook uses to store information about named properties created via the Object model and the user interface.

Now that the format of PidLidPropertyDefinitionStream is documented, you can create new user defined properties using MAPI and have them show up in the UI! The September release of MFCMAPI (which I’m furiously hammering on) will be able to parse this property.

As usual, the documentation is also available for download.

Enjoy!

July 2009 Release of MFCMAPI

Stephen Griffin — Thu, 16 Jul 2009 21:15:26 GMT

The July 2009 Release (build 6.0.0.1014) is live: http://mfcmapi.codeplex.com.

Note that a 64 bit build is now included. Of course, to use it, you’ll need 64 bit Outlook 2010.

This time around I focused on performance. I've just discovered the built in profiler in Visual Studio and I’ve been using it to find bottlenecks in loading items and displaying their properties. It’s been enlightening to drill into the performance reports and find out just how much time some of the code paths took to execute. I was able to trim away a good bit of fat.

The biggest change I made in the name of performance was in the area of Named Properties. I found I was repeatedly calling GetNamesFromIDs to map property tags to their named prop names. Cutting down the number of calls meant implementing a cache. We still incur the initial hit to look up the mappings, but once we’ve looked up a tag, we won’t look it up again. Uncached profiles should load a bit faster now.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

Fixed the tooltips on column headers to stop going away
Added a “Count Named Properties” feature
Numerous perf improvements
Fixed compilation for VC6 and VS 2005 (see my workaround for the “old DIB” issue)
Found and fixed a few crashes

Enjoy.

Enter the 64 Bit MAPI Dragon

Stephen Griffin — Mon, 13 Jul 2009 22:19:41 GMT

Up until today, the first rule of 64 bit MAPI was we don’t talk about 64 bit MAPI. But now we can talk about it. 64 bit MAPI has arrived!

We just released the Outlook 2010 MAPI Reference today. If you develop MAPI based applications, you’ll want to get the updated MAPI Headers that come with it. You’ll need these if you want to rebuild your application for 64 bit. We’ve also prepared an article on building MAPI applications for both 32 bit and 64 bit platforms. This article is based in part on my experience building MFCMAPI as a 64 bit application. Since we don’t provide a 64 bit mapi32.lib, to build a 64 bit MAPI application you’re going to have to use explicit linking, building on the documentation we included in the Outlook 2007 MAPI reference.

Oh yeah – that reminds me – MFCMAPI builds as a 64 bit application! Actually, it’s been possible to build MFCMAPI as 64 bit for years. I slipped those project types in a long time ago and have been quietly maintaining them, even before I had an actual 64 bit build of MAPI I could test against. The next release of MFCMAPI will include a 64 bit build of the project, but if you want a 64 build now, just download the source and build it yourself.

Enjoy!

MFCMAPI and Old Versions of Visual Studio

Stephen Griffin — Fri, 10 Jul 2009 00:45:29 GMT

Ever since I went to the new Vista style icon for MFCMAPI, it’s not been possible to compile in Visual Studio 6. I’ve spent some time looking at this, and it appears the only clean way to get VS 6 working again is to remove compression from the icon, something I really don’t want to do. So I’m considering dropping support for Visual Studio 6 altogether. While I’m at it, it’s been a while since I tried to compile in VS 2003 or 2005, so I was thinking about dropping support for those two as well. The only compiler I’d test would be Visual Studio 2008 (and 2010 whenever it comes out). Note that other than the known break in VS 6 I’m not planning on actively breaking compilation for 2003 or 2005. I just wouldn’t test them, so over time, I probably would break them.

Before I do this – I wanted to get feedback. Would anybody care if MFCMAPI no longer compiled in Visual Studios 6, 2003, or 2005?

Exchange MAPI and the Form Manager

Stephen Griffin — Wed, 08 Jul 2009 18:27:13 GMT

Had a customer contact me recently asking why MAPIOpenFormMgr doesn’t work with the Exchange MAPI download. Actually, it wasn’t working in Exchange 2003 either. I’m not sure exactly when it last worked in Exchange’s implementation of MAPI. We might have to go all the way back to the Exchange Client to find a version of Exchange’s MAPI where it worked.

There was more to this story that I wanted to post. A few years ago, on a whim, I debugged why MAPIOpenFormMgr was broken. I found it was looking for a forms manager DLL that Exchange hadn’t shipped in a long long time. However, there was a mechanism for directing Exchange’s MAPI to use a different forms manager, and one of the DLLs Exchange shipped could act as a forms manager. Since this wasn’t likely supported, and no one was asking about it, I filed it away as an interesting tidbit.

Since I did get asked about it, my plan was to post the reg key that controls which forms manager is used with a warning that since it isn’t supported or tested, it’s quite possible it will break on you. However, when I went to try it out, I found that when you try it out with the Exchange MAPI download, you crash right away. This isn’t surprising considering no one’s run the code in 10+ years.

So there’s no point in posting the key, though someone who was really determined could figure it out pretty quickly, and with a little debugging even figure out which DLL to point at. I guess I’ll leave that as an exercise for the reader. The official answer here is that Exchange’s implementation of MAPI doesn’t include a functioning forms manager, so none of the forms management portions of MAPI, such as MAPIOpenFormMgr or MAPIOpenLocalFormContainer, are available.

So Long Mapi Editor…And Thanks For All The Fish

Stephen Griffin — Mon, 15 Jun 2009 16:44:36 GMT

I’ve touched on the history of MFCMAPI before. The rebranding of MFCMAPI as MAPI Editor and posting it on the Microsoft Download site back in 2006 served a purpose, one for which at the time there were few alternatives. However, since then, I have taken back control over publishing of the tool so I can get updates and fixes to my users faster (as opposed to “never”, which was the case with that download).

Since setting up the Codeplex site, one thing that’s been bugging me is that the “MAPI Editor” download was still fairly popular. No amount of evangelizing the new builds on the Codeplex site would prevent people from searching for MFCMAPI on Microsoft.com and coming up with what I view as an old and buggy build. So, last week, we “fixed the glitch”. If you visit the download page now, instead of MAPI Editor, you’ll find a link to Codeplex. And if you download the file that’s there (apparently – there has to be a file to have a page on the download site), it’s a PDF that also directs you to Codeplex.

The switch was flipped last Thursday, and my download stats already show a huge spike. So the redirection must be working! Hopefully now I’ll stop seeing problem reports on that old build.

(Less Than) Portable Search Folders

Stephen Griffin — Thu, 21 May 2009 23:47:13 GMT

Let’s have fun with the object model and search folders:

Outlook running a profile in online mode.
Create this macro:
Sub TestAdvancedSearchComplete()

    Dim sch As Outlook.Search

    set sch = Application.AdvancedSearch("Inbox", "urn:schemas-microsoft-com:office:office#Keywords like 'Test'", True, "MySearchFolder")

    sch.Save ("MySearchFolder")

End Sub
Run the macro, observe the folder.
On the same machine, create a new profile in cached mode and start Outlook
Run macro, get “Run-time error '-2147219964 (80040604)': Cannot create folder.”

If we want to have more fun, instead of running the macro the second time, we can locate the folder “MySearchFolder” under the Search Folder node in Outlook. If we click on it, Outlook creates a search folder, but it doesn’t populate with the items we expect to find.

What’s going on here? To answer that, we have to know a bit about how Outlook’s persisted search folder feature works. When you create a search folder, either using the Object Model, or directly in Outlook, the folder isn’t the first thing created. The first thing created is the search folder definition message. This is a message with the message class “IPM.Microsoft.WunderBar.SFInfo” which lives in the associated contents of the Common Views folder. We can use MFCMAPI to take a look at this message:

And we can use MFCMAPI’s Smart View feature to parse the search folder definition stored in PR_WB_SF_DEFINITION:

From this, we find that the search folder definition contains the restriction that will form the basis of the search folder:

Restriction:
lpRes->rt = RES_CONTENT
lpRes->res.resContent.ulFuzzyLevel = FL_IGNORECASE | FL_FULLSTRING = 0x00010000
lpRes->res.resContent.ulPropTag = 0x8010101F (PT_MV_UNICODE)
lpRes->res.resContent.lpProp->ulPropTag = 0x8010001F (PT_UNICODE)
lpRes->res.resContent.lpProp->Value = Test
  Alt: cb: 8 lpb: 5400650073007400

Note that this restriction includes a property in the 0x8000 range, meaning it’s a named property. In fact, it’s the named property “Keywords” in the PS_PUBLIC_STRINGS namespace. Note also that there’s nothing in the restriction which tells me this. I only know it because I created the search folder and I know what the search folder is supposed to be looking for.

Now – what happens when we go to a different profile looking at the same mailbox? The search folder itself doesn’t get synched back to the server. Only this search folder definition message gets synced. When Outlook encounters this message, it places a dummy node under Search Folders and waits for the user to click on it. If the user does click on it, it builds the search folder using the information from PR_WB_SF_DEFINITION.

And that’s where the problem comes in: Named property mappings are store specific. A named property mapping that’s valid for one store will most likely be invalid for another store. When we switched to cached mode, we’re now working with the OST, not Exchange. Even if there happens to be an 0x8010101F property in this store, it’s not going to be the “Keywords” property. So when we clicked on the folder in Outlook, it created a search folder that searched for a bogus property.

What happened when we ran the macro is even more interesting: Outlook looked at our search string and built a search folder definition message with the appropriate PR_WB_SF_DEFINITION. However, it couldn’t save the message because it already existed, with a different definition!

Why don’t we have a problem when we create search folders directly in Outlook? The Outlook user interface severely restricts the kinds of restrictions you can set up. Because of that, Outlook is able to store the PR_WB_SF_DEFINITION in a different format (using SFST_FILTERSTREAM instead of SFST_MRES). That format is more flexible with named properties, but isn’t capable of storing the wide variety of restrictions that could be specified through the Outlook Object Model.

Workaround

We did look at taking a fix for this, but the limitations of SFST_FILTERSTREAM eliminated it as a possibility for a fix. And the fact that this problem only happens if the restriction contains a named property (IE it won’t repro on a search for subject or recipients) limited the scope of the problem.

However, for the case where the search folder is being created by a macro and we’re getting the “Cannot create folder” error, we found a neat workaround. We can use Outlook’s PropertyAccessor to delete the search folder definition message so it can be recreated. Here’s a sketch of the code:

Sub DeleteSFItem()
    Dim CommonViewsEIDBin As String
    Dim CommonViewsEIDString As String
    Dim CommonViewsFolder As Folder
    Dim ACTable As Table
    Dim oRow As Row
    Dim SFDefinitionEID As String
    Dim SFDefinitionItem As StorageItem
        
    CommonViewsEID = Session.DefaultStore.PropertyAccessor.GetProperty( _
        "http://schemas.microsoft.com/mapi/proptag/0x35E60102")
    CommonViewsEIDString = Session.DefaultStore.PropertyAccessor.BinaryToString( _
        CommonViewsEID)
    Set CommonViewsFolder = Session.GetFolderFromID(CommonViewsEIDString)
    Set ACTable = CommonViewsFolder.GetTable( _
        "[Subject] = 'MySearchFolder'", olHiddenItems)
    
    Set oRow = ACTable.GetNextRow()
    If (Not (oRow Is Nothing)) Then
        SFDefinitionEID = oRow("EntryID")
        Set SFDefinitionItem = Session.GetItemFromID(SFDefinitionEID)
        SFDefinitionItem.Delete
    End If
End Sub

For further reading on the inner workings of search folder definition messages, check out the Exchange Protocol Doc [MS-OSOSRCH].

May 2009 Release of MFCMAPI

Stephen Griffin — Wed, 20 May 2009 17:26:08 GMT

The May 2009 Release (build 6.0.0.1013) is live: http://mfcmapi.codeplex.com.

The coolest new feature has to be the addition of Smart View parsing to the Hex Editor. I actually had the idea to do this the morning I published the March 2009 release, but didn’t want to delay that release any longer. One side effect of exposing the parsing in the Hex Editor is I was able to do much better testing of the existing parsing engine and fix a bunch of memory leaks and crashes.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

Added ability to copy attachments from one message to another
Added Outlook version feature - uses MSI to retrieve installed version of Outlook
Added Smart View to hex editor
Fixed issue converting MAPI to MIME from an MSG file
Fixed parsing of fuzzy level flags
Updated MAPI headers
Removed extraneous pointer address output from restriction parsing
Added smart view parsing for Entry Lists, Properties, Restrictions, and Search Folder Definitions
Cleaned up memory leaks and crashes in smart view parsing

Enjoy.

UST and Long File Names

Stephen Griffin — Fri, 20 Mar 2009 18:26:16 GMT

I think this will be the last article to come from James’ post on debugging MAPI (previous posts here, here, and here). This last one bit me when I was trying to gather a UST trace from a customer.

Here’s the deal: The image file name associated with an executable can be different depending on how the process is launched. And Image File Execution Options (IFEO) works on the image file name, not the executable name. To illustrate this, we can rename mfcmapi.exe (my favorite executable, natch) to ThisIsAReallyLongName.exe and run some tests. First, let’s determine the short file name for this file:

D:\MFCMAPI>dir /x ThisIsAReallyLongName.exe
03/16/2009  10:28 AM         1,982,976 THISIS~1.EXE ThisIsAReallyLongName.exe

Next, we launch Procmon and look for anyone opening an IFEO key for a process with “this” in the name. Let’s try launching the process from the command line, using both the long and the short name:

D:\MFCMAPI>ThisIsAReallyLongName.exe
64-bit cmd.exe RegOpenKey
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ThisIsAReallyLongName.exe
D:\MFCMAPI>THISIS~1.EXE
64-bit cmd.exe RegOpenKey
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ThisIsAReallyLongName.exe

I trimmed and formatted the Procmon output a bit for clarity. The columns are bitness, process name, operation, and key read. So far, no difference in the keys. Let’s see what happens if we ask the debugger to launch the process:

D:\MFCMAPI>windbg ThisIsAReallyLongName.exe
64-bit windbg.exe RegOpenKey
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ThisIsAReallyLongName.exe
32-bit ThisIsAReallyLongName.exe RegOpenKey
  HKLM\SOFTWARE\Microsoft\WINDOWS NT\CURRENTVERSION\Image File Execution Options\ThisIsAReallyLongName.exe
D:\MFCMAPI>windbg THISIS~1.EXE
64-bit windbg.exe RegOpenKey
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\THISIS~1.EXE
32-bit THISIS~1.EXE RegOpenKey
  HKLM\SOFTWARE\Microsoft\WINDOWS NT\CURRENTVERSION\Image File Execution Options\THISIS~1.EXE

The first thing we notice is now both the launching process and the launched process are reading IFEO keys. Next, we notice the 64/32 bit difference showing up in the paths. But the biggest difference is one is looking for a key named “ThisIsAReallyLongName.exe” while the other looks for “THISIS~1.EXE”.

So maybe this is a quirk of the debugger? Let’s try running the app from Start Run:

Start\Run: d:\mfcmapi\ThisIsAReallyLongName.exe
64-bit Explorer.EXE RegOpenKey
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ThisIsAReallyLongName.exe
Start\Run: d:\mfcmapi\thisis~1.exe
64-bit Explorer.EXE RegOpenKey
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\thisis~1.exe

We’re back to one process reading the keys, but we still see that the key name depends on whether we used the long or short name for the file.

So – the upshot here, combined with the 32/64 bit issue from before, is when setting IFEO options to enable UST (or anything else IFEO is used for), you potentially need to set the options in 4 places, depending on the bitness of the process, whether or not a long file name is involved, and who launched the process.

March 2009 Release of MFCMAPI

Stephen Griffin — Wed, 18 Mar 2009 19:48:41 GMT

The March 2009 Release (build 6.0.0.1012) is live: http://mfcmapi.codeplex.com. Note the new URL – the old one still works.

At the urging of Jason, I’ve added parsing of entry IDs per the protocol docs.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

Super ultra cool entry ID parsing
Fixed slow dialogs
Fixed overnight crashes
Added Fast Shutdown (note – MFCMAPI won’t call Fast Shutdown normally – only if you ask it to)
Added support for fiddling with PST paths and setting passwords

Enjoy.