Unable to read PR_NATIVE_BODY_INFO for message in PST

Aspose.Email Product Family
1

Using MFC MAPI, I can see that a certain message in my PST has a value for PR_NATIVE_BODY_INFO.
image.png (3.4 KB)

However, when I read the PST using the PersonalStorage class and try to get the read the property, I get a null return value.

I’ve tried extracting the message and reading the property from a MapiMessage instance and I’ve tried reading the property directly from the PersonalStorage instance.

image.png (30.4 KB)

3

Hello @weswes,

PR_NATIVE_BODY_INFO (PidTagNativeBody) is not guaranteed to be physically stored in a PST.
According to Microsoft’s MS-OXBBODY specification, this property indicates the “native” body format (plain text, RTF, or HTML), but if it’s not present in the message data, the client is expected to determine the best body format itself by checking other body properties (PR_BODY, PR_RTF_COMPRESSED, PR_HTML).

By the way, the icon shown next to the PR_NATIVE_BODY_INFO property in your MFCMAPI screenshot indicates that the property is computed.

When you open the PST with MFCMAPI, Outlook may display a value for PR_NATIVE_BODY_INFO because it computes it on the fly, even if it’s not stored in the PST.
Aspose.Email only returns this property if it exists physically in the message. If it’s not there, you’ll get null.

If you just need the body format, use the MapiMessage.BodyType property, which provides equivalent information without requiring PR_NATIVE_BODY_INFO to be present.

4

Thanks for the tip on the MFCMAPI icon. I assumed the property was stored.

I’m hesitant to use the properties on MapiMessage because I’ve observed that in some cases MapiMessage synthesizes bodies on the fly and I’m trying to save message information exactly as it is in the PST.

Specifically, if I set PR_HTML on a mapi message, save it to a PST, reopen the PST, and examine the message, I see that PR_RTF_COMPRESSED and PR_BODY have been added.

I found that if I use PersonalStorage.ExtractProperty to read the message body properties without loading the message, only the original message body is present. So that’s an option for me. Though I do wish there as a way to load a MapiMessage without having additional messages bodies synthesized.

5

Actually, I’m pretty sure that MFCMAPI icon represents the data type.

That seems to correspond wit PT_LONG.

6

@weswes,

When saving a message to MSG, Outlook or MAPI-compliant library will often add PR_RTF_COMPRESSED and PR_BODY automatically.
This is expected behavior, not a bug. It’s part of Outlook’s design to ensure the message can be opened even in environments that only support plain text or RTF.

According to Microsoft’s Opening Message Text documentation:

  • Message text is stored either in PR_BODY (plain text) or PR_RTF_COMPRESSED (formatted RTF).
  • If the store supports RTF, clients should read PR_RTF_COMPRESSED; otherwise, they should fall back to PR_BODY.
  • If the store isn’t RTF-aware, Outlook may run RTFSync to generate missing formats so both plain text and RTF are available.

This is why even if you only set one body property, Outlook (or a similar library) may add the others for compatibility.

Also, having PR_RTF_COMPRESSED doesn’t mean your HTML is lost.
As described in the MS-OXRTFEX specification, RTF can embed HTML.

7

You’re right, the MFCMAPI icons indicate the property’s data type.
I misinterpreted part of your screenshot earlier and mistakenly thought it showed a computed property.
Sorry for the confusion :slight_smile: