The January 2011 Release (build 22.214.171.1244) is live: http://mfcmapi.codeplex.com.
This round of work had two foci: Speed startup time of MFCMAPI and MrMAPI, and add features to MrMAPI.
I have been ignoring startup time of MFCMAPI for a while now, since it started up “fast enough”. But MrMAPI was designed to be run in batch scripts, and a slow startup time really adds up over multiple runs. They share the same code, so any work improving one improves the other. I found a number of opportunities to squeeze cycles out by sorting some arrays in the source and by improving the algorithms I use to shuffle them around when we’re starting. But the biggest improvement will happen if you happen to run MFCMAPI or MrMAPI from a directory with a lot of other files in it, such as a tools directory. We get a great speedup by remembering which files are and are not add-ins to MFCMAPI, so we don’t keep retrying them.
Other than the speed-up work, MrMAPI got most of the love. I added a host of new features: Error lookup, guid lookup, ACL and Rule table exports, and nickname cache parsing are the big ones. I’ve also uploaded a 64 bit version of MrMAPI since some of the features actually log in to a profile, and we need to support 64 bit Outlook.
When you download the new version of MFCMAPI, make sure to download MrMAPI for all of your property tag needs.
Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:
Many thanks again for all the goodies.
MrMapi -? has minor typo for -E options referring to -s and -n rather than -S and -N
Of more substantial interest, a partial value for the -E option does not seem to behave as I would expect. eg, mrmapi -E 0x8004
does not return all 0x8004* values, but instead returns 0x00008004
-s and -n are acceptable alternatives for -S and -N, but I'll fix that for consistancy.
For your lookup, try this:
mrmapi -e |findstr /i 8004
I was using the MFCMAPI command "Convert EML to MSG" under the session menu and noticed that attachments without file extensions are given either a .dat or .txt extension, depening on the MIME of the EML file. (Specifically, those without Content-Type: application/octet-stream get .txt)
I looked into this further, and I think it is in the MIMEtoMAPI call that does this. Is there something done in MIMEtoMAPI that might do this?
It definitely sounds like something in MIMEToMAPI is doing that, and it does make sense that it would. MFCMAPI definitely isn't touching the attachments.