One of our customers reported that if they used IConverterSession::MIMEToMAPI to generate an MSG file, then opened the MSG file and hit Forward, the body would be gone. Further investigation revealed more funkiness. Reply worked, but if you tried Forward, closed the forwarded message, then tried Reply again, the body would be missing there as well. I could also repro the problem with some messages I saved to MSG from MFCMAPI.
If you’ve read my other article on MSG files you know this behavior doesn’t surprise me. I did file a bug on this, but it got rejected since it turns out there’s an easy workaround for the case my customer was hitting.
The problem basically comes down to the best body logic as it applies to an MSG file. All of the MSG files we were dealing with here had PR_BODY_HTML set, not PR_RTF_COMPRESSED. This is fine when we initially render the message, as well as when we re-render for the reply. But when we render for the forward, we go through a different code path that hinges on getting PR_STORE_SUPPORT_MASK from the store in which the message lives. But MSG files don’t live in a message store. So we don’t get the prop, and the code path fails to render the body. Along the way, it also clears some bits that were allowing the reply case to work, so it now fails.
MSG files saved from Outlook didn’t exhibit the problem – they had PR_RTF_COMPRESSED set in them instead of PR_BODY_HTML. That sends us through yet another code path gets much more testing and doesn’t have these problems. And this is the key to the workaround: When using MIMEToMAPI to generate MSG files, always include the CCSF_USE_RTF flag. This will write the body into the PR_RTF_COMPRESSED property (even if it’s HTML), avoiding the problem.