none
MS-OXBBODY again RRS feed

  • Question

  • I'm building a set of MSG's to test the MS-OXBBODY matrix, and am encountering some offspec behavior ... I'm testing using Outlook 2013 and constructing MSG files with specific sets of properties.  There are some distinct scenarios that are failing.

    For example:

    Case 3:
    PlainStatus = NotEnoughMemory, RtfStatus = NotEnoughMemory, HtmlStatus = NotFound, RtfInSync = Any
    Expected result: RTF
    Actual result:  If RtfSync is false or missing, result is Plain Text
    If RtfSync is true, result is RTF

    Case 3 seems to be behaving like Case 8 and Case 9.1

    Also, there's an entire case that's missing in the matrix.

    PlainStatus = NoError or NotEnoughMemory, RtfStatus = NotFound, HtmlStatus = NoError or NotEnoughMemory, RtfInSync=Any
    Expected result:  Not listed, HTML inferred

    The matrix would have that scenario render as Plain Text (falling through) but Outlook 2013 renders that in HTML.

    Thursday, June 25, 2015 11:45 PM

All replies

  • Hello Robert,

    Thank you for your post. I am the engineer who will be working with you on these issues. You mention entry 3 in the table used to determine the body format in §2.1.3.1 not behaving as expected. Is that the only entry you see unexpected results from, or are there others?

    Are you able to share the files you are using to test? If so, could you please email those to my attention at dochelp at microsoft dot com? Please make sure that they do not contain any confidential information.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Friday, June 26, 2015 12:26 AM
  • I'm still building the MSG's, so I haven't gotten all the way through the matrix yet.  I will send them to you when I've finished, along with any other anomalies I may find.

    Thanks!

    Friday, June 26, 2015 12:28 AM
  • Hello Robert,

    Thank you, that will be a great help.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Friday, June 26, 2015 12:29 AM
  • E-mail sent w/ attachments

    Matrices that failed in Outlook 2013 were Case 3 and 9.1

    Friday, June 26, 2015 1:10 AM
  • Hello Robert,

    I received the email and the .msg files. Thank you again. I will get back to you with more information as soon as I can.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Friday, June 26, 2015 1:17 AM
  • Also, for the purposes of an MSG file, it would appear that PidTagNativeBody is completely ignored.  Adding this value to an MSG makes no difference whatsoever to the way Outlook interprets the best body to use.  This makes sense I suppose, since the spec is specifically talking about Exchange ... but it also makes me wonder if there's more than one "best body algorithm" based on where the data is coming from.

    Friday, June 26, 2015 4:10 PM
  • Hello Robert,

    As I'm digging into this, I'm getting the impression that there are different rules for MSG files in general than those laid out in [MS-OXBBODY]. I'm still early in the process of investigating this, but I would not be surprised to find that something other than these rules determines the body type for a MSG file.

    When I open !FAIL!Case3_rtfsync=false.msg with Outlook, I see that it is displayed as plain text as you reported. When I then copy it into a folder under my Exchange mailbox (File->Move to Folder) and reopen the same, ostensibly unmodified message from there, it is rendered as rich text. That action appears to be changing the value of PidTagRtfInSync, among making other property changes, so I'm not certain it's a valid point of comparison.

    I'll continue digging into what should be happening with and what should be documented for MSG files.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Friday, June 26, 2015 9:17 PM
  • Hello Robert,

    How were the problematic files originally created? After further investigation, I have found that the rules in [MS-OXBBODY] only apply in the context of a message object retrieved from an Exchange mailbox. It seems that the act of copying these problematic messages to an Exchange mailbox results in their properties being altered. That makes me suspect that the message objects did not originate from Exchange, in which case the specification does not factor in to how the client chooses the body representation to render. This would be client behavior that is beyond the scope of what is documented in the Exchange protocol documentation.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Tuesday, July 7, 2015 11:41 PM
  • The MSG's in question were manufactured out of an Outlook PST and then specifically altered to test the rules in [ms-oxbbody].

    It sounds like we're on our own for discovering the behavior of Outlook, and that there is no documented specification or suggestion for how Outlook, or any e-mail client reading and displaying an MSG, should interpret the best body contained therein?

    Can you confirm that's the case?  If so, I'll consider the matter closed.

    Wednesday, July 8, 2015 12:43 AM
  • Hello Robert,

    The [MS-OXBBODY] specification is only applicable to message objects being retrieved from an Exchange mailbox. If the client saves that object to an .MSG file and redisplays it, it's no longer constrained by the specification. To my knowledge, there is no documentation of Outlook client behavior when reading and displaying an .MSG file.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Thursday, July 9, 2015 3:10 PM