5 Appendix A: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Microsoft Exchange Server 2003

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2010

  • Microsoft Exchange Server 2013

  • Microsoft Exchange Server 2016

  • Microsoft Exchange Server 2019

  • Microsoft Office Outlook 2003

  • Microsoft Office Outlook 2007

  • Microsoft Outlook 2010

  • Microsoft Outlook 2013

  • Microsoft Outlook 2016

  • Microsoft Outlook 2019

  • Microsoft Outlook 2021

  • Microsoft Outlook 2024 Preview

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.1: Office Outlook 2003 and Office Outlook 2007 do not use the HTML only setting.

<2> Section 2.1.3.1: Microsoft Exchange Server 2010 Service Pack 2 (SP2), Exchange 2013, Exchange 2016, and Exchange 2019 support this method of display name generation.

<3> Section 2.1.3.1: Exchange 2003 supports this method of generating display names for recipients.

<4> Section 2.1.3.1: Office Outlook 2003 and Office Outlook 2007 do not encapsulate addresses.

<5> Section 2.1.3.1.1:  Exchange 2007 does not ignore recipient types other than To, Cc, or Bcc.

<6> Section 2.1.3.1.1:  Exchange 2007 performs a bitwise AND of the value of the PidTagRecipientType property ([MS-OXOMSG] section 2.2.3.1) and 0x00000003.

<7> Section 2.1.3.1.1: Office Outlook 2003 and Office Outlook 2007 do not generate MIME recipients (2) for Bcc recipients when generating a message to send via SMTP.

<8> Section 2.1.3.1.1: Office Outlook 2003 and Office Outlook 2007 use the listed steps in the following order: 4, 5, 1, 2, 3, 7. Office Outlook 2003 and Office Outlook 2007 do not use step 6.

<9> Section 2.1.3.1.1.1: Exchange 2003 generates the attRecipTable attribute according to this procedure.

<10> Section 2.1.3.1.1.2: Exchange 2003, Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not copy Bcc recipients to the MIME Bcc header when generating messages for POP3 or IMAP4.

<11> Section 2.1.3.1.1.2: Exchange 2003, Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not copy Bcc recipients to the TNEF recipient table for attached messages when generating messages for POP3 or IMAP4.

<12> Section 2.1.3.1.2: Office Outlook 2003 and Office Outlook 2007 do not copy the values of the PidTagReplyRecipientEntries property ([MS-OXOMSG] section 2.2.1.43) and the PidTagReplyRecipientNames property ([MS-OXOMSG] section 2.2.1.44) to the TNEF body part.

<13> Section 2.1.3.1.3: Office Outlook 2003 and Office Outlook 2007 do not copy the values of the PidTagSentRepresenting property group (section 2.6.5) to the TNEF body part.

<14> Section 2.1.3.1.4: Office Outlook 2003 and Office Outlook 2007 do not copy the values of the PidTagSender property group (section 2.6.4) to the TNEF body part.

<15> Section 2.1.3.1.5: Exchange 2007 copies the values in the PidTagSentRepresenting property group (section 2.6.5) as described in this procedure.

<16> Section 2.1.3.1.5: Office Outlook 2003 and Office Outlook 2007 do not copy the values of the PidTagOriginatorDeliveryReportRequested property ([MS-OXOMSG] section 2.2.1.20) or the specified e-mail properties to the TNEF body part.

<17> Section 2.1.3.1.6: Office Outlook 2003 and Office Outlook 2007 do not copy the values of the PidTagReadReceipt property group (section 2.6.1) and the PidTagSentRepresenting property group (section 2.6.5). Note that they do copy the PidTagReadReceiptRequested property ([MS-OXOMSG] section 2.2.1.29).

<18> Section 2.1.3.1.8: Office Outlook 2003 and Office Outlook 2007 do not encapsulate addresses.

<19> Section 2.1.3.1.8: Exchange 2007 uses this procedure for encoding and decoding encapsulated addresses. Exchange 2007 has no limitation on the length of the address-type part. Exchange 2007 does not properly de-encapsulate if the address-type part contains an ASCII hyphen ("-").

<20> Section 2.1.3.1.8: Exchange 2003 uses this procedure for encoding and decoding encapsulated addresses. Exchange 2003 does not properly de-encapsulate if the address-type part contains an ASCII hyphen ("-").

<21> Section 2.1.3.2: Office Outlook 2003 and Office Outlook 2007 do not copy properties to the TNEF body part if there is a corresponding MIME header.

<22> Section 2.1.3.2.1: Office Outlook 2003 and Office Outlook 2007 do not convert appointment items to MIME.

<23> Section 2.1.3.2.2: Exchange 2003 does not generate the Content-class header.

<24> Section 2.1.3.2.2:  Exchange 2007 writes the Content-class header value as "fax".

<25> Section 2.1.3.2.2:  Exchange 2007 writes the Content-class header value as "voice".

<26> Section 2.1.3.2.3: Office Outlook 2003 does not support Unified Messaging.

<27> Section 2.1.3.2.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-CallingTelephoneNumber header.

<28> Section 2.1.3.2.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-VoiceMessageDuration header.

<29> Section 2.1.3.2.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-VoiceMessageSenderName header.

<30> Section 2.1.3.2.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-FaxNumberOfPages header.

<31> Section 2.1.3.2.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-AttachmentOrder header.

<32> Section 2.1.3.2.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-CallID header.

<33> Section 2.1.3.2.4: Exchange 2003 only implements encoding for three specific headers: Subject, Thread-Topic, and X-Message-Flag, which is not fully compliant with [RFC2047].

<34> Section 2.1.3.2.4: Exchange 2003 does not check to prevent the use of the reserved name headers X-Microsoft-Exchange-Organization and X-Microsoft-Exchange-Forest.

<35> Section 2.1.3.2.7: Office Outlook 2003 and Office Outlook 2007 do not copy the value of the PidTagClientSubmitTime property ([MS-OXOMSG] section 2.2.3.11) to the TNEF body part.

<36> Section 2.1.3.2.8: Office Outlook 2003 and Office Outlook 2007 instead copy the value of the PidTagSubject property ([MS-OXCMSG] section 2.2.1.46) to the Subject header.

<37> Section 2.1.3.2.8: Office Outlook 2003 and Office Outlook 2007 do not copy the message subject to the TNEF body part.

<38> Section 2.1.3.2.11: Office Outlook 2003 and Office Outlook 2007 generate new Message-ID header values in this instance.

<39> Section 2.1.3.2.14: Exchange 2003 does not copy this value. Microsoft Exchange Server 2003 Service Pack 2 (SP2) with the hotfix for Exchange 2003 SP2 described in [MSKB908027] applied copies this value.

<40> Section 2.1.3.2.16: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the Accept-Language header.

<41> Section 2.1.3.2.16: Exchange 2007 generates a value for the Accept-Language header when the PidNameAcceptLanguage property ([MS-OXCMSG] section 2.2.1.42) is missing and the mfSubmitted flag is not set in the PidTagMessageFlags property ([MS-OXCMSG] section 2.2.1.6).

<42> Section 2.1.3.2.16: Exchange 2003 does not generate the Content-Language header.

<43> Section 2.1.3.2.17: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate any classification headers.

<44> Section 2.1.3.2.18:  Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not support retrieving the value of the PidTagAttachPayloadProviderGuidString property ([MS-OXCMSG] section 2.2.2.29).

<45> Section 2.1.3.2.18: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 only generate X-Payload-Provider-GUID and X-Payload-Class headers when they are properties on a message, which includes message attachments. These headers are not generated when they are properties of file attachments.

<46> Section 2.1.3.2.18: Office Outlook 2003, Office Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not generate the X-Payload-Provider-GUID header. Exchange 2003 does not copy the value of the PidTagAttachPayloadProviderGuidString property ([MS-OXCMSG] section 2.2.2.29) to the X-Payload-Provider-Guid header.

<47> Section 2.1.3.2.18: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 set the PidTagAttachPayloadProviderGuidString property ([MS-OXCMSG] section 2.2.2.29) as a property of the attachment.

<48> Section 2.1.3.2.18: Office Outlook 2003, Office Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not generate the X-Payload-Class header. Exchange 2003 does not copy the value of the PidTagAttachPayloadClass property to the X-Payload-Class header.

<49> Section 2.1.3.2.19: Office Outlook 2003 generates the X-MS-Has-Attach header with no output.

<50> Section 2.1.3.2.19: Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 will not generate an X-MS-Has-Attach header if one was not included in the original MIME message.

<51> Section 2.1.3.2.20: Exchange 2003, Exchange 2007, Office Outlook 2003, and Office Outlook 2007 do not generate the X-Auto-Response-Suppress header.

<52> Section 2.1.3.2.21: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-MS-Exchange-Organization-AutoForwarded header.

<53> Section 2.1.3.2.22: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-MS-Exchange-Organization-SenderIdResult header.

<54> Section 2.1.3.2.23: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-MS-Exchange-Organization-PRD header.

<55> Section 2.1.3.2.24: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the X-MS-Exchange-Organization-SCL header.

<56> Section 2.1.3.2.26: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not write a value to the X-MS-TNEF-Correlator header or the PidTagTnefCorrelationKey property ([MS-OXCMSG] section 2.2.1.29) in the attMsgProps attribute of the TNEF body part when generating a MIME message for download via IMAP4.

<57> Section 2.1.3.2.28: Exchange 2003 does not write the Reply-By header.

<58> Section 2.1.3.2.29:  Office Outlook 2003 and Office Outlook 2007 do not copy the value of the PidTagBodyContentId property ([MS-OXCMSG] section 2.2.1.58.7) to the Content-ID header.

<59> Section 2.1.3.2.30:  Exchange 2007 does not copy the value of the PidTagBodyContentLocation property ([MS-OXCMSG] section 2.2.1.58.8) to the Content-Location header.

<60> Section 2.1.3.2.31: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not generate an XRef header.

<61> Section 2.1.3.3.1: Exchange 2003 defaults to ISO-8859-1 when the PidTagInternetCodepage property ([MS-OXCMSG] section 2.2.1.58.6) is not set by the client for plain text message bodies.

<62> Section 2.1.3.3.1: Office Outlook 2003 and Office Outlook 2007 either convert the RTF text to HTML or generate a TNEF attachment that contains the RTF body.

<63> Section 2.1.3.3.1: Exchange 2007 re-encodes the message body using this procedure. Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 preserve the character set of the original MIME message body.

<64> Section 2.1.3.3.1: Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 preserve the character set as described.

<65> Section 2.1.3.3.1:  Exchange 2007 uses this procedure for body formats.

<66> Section 2.1.3.3.2: Exchange 2003 loses body text when reading TNEF if only a plain text body is encoded in TNEF.

<67> Section 2.1.3.3.4: Exchange 2003 uses this procedure to copy the body.

<68> Section 2.1.3.3.6: Exchange 2003 and Exchange 2007 do not check to determine whether an apparently inline attachment is, in fact, referenced from the message body.

<69> Section 2.1.3.3.8: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 support a configuration option to select a character set encoding other than UTF-8.

<70> Section 2.1.3.3.8.2: Exchange 2003 copies the value of the PidTagHtml property ([MS-OXCMSG] section 2.2.1.58.9).

<71> Section 2.1.3.3.8.2: Exchange 2003 uses a value of "8bit" for the Content-Transfer-Encoding header in this circumstance.

<72> Section 2.1.3.3.8.2: Exchange 2007 uses a value of "base64" for the Content-Transfer-Encoding header in this circumstance.

<73> Section 2.1.3.3.8.2: Exchange 2003 uses a value of "quoted-printable" for the Content-Transfer-Encoding header.

<74> Section 2.1.3.3.8.2: Exchange 2007 uses a value of "base64" for the Content-Transfer-Encoding header in this circumstance.

<75> Section 2.1.3.3.8.3: Exchange 2003 uses a value of "multipart/mixed" for the Content-Type header in this circumstance.

<76> Section 2.1.3.3.9: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 generate MIME entities with Content-Type header values of "text/enriched" if configured by an administrator to do so.

<77> Section 2.1.3.4.1: Exchange 2007 does not exclude attached Message objects or attachments to plain text messages from being considered inline.

<78> Section 2.1.3.4.1.1: Exchange 2007 does not exclude non-OLE attachments in an RTF message from being considered inline.

<79> Section 2.1.3.4.1.2: Exchange 2003 does not generate the cid URI.

<80> Section 2.1.3.4.1.2:  Exchange 2007 checks only condition 1, not conditions 2 or 3, when classifying attachments as inline.

<81> Section 2.1.3.4.2.1: Exchange 2003, Office Outlook 2003, Office Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 use an empty string if values for the PidTagAttachLongFilename ([MS-OXCMSG] section 2.2.2.10) and PidTagAttachFilename ([MS-OXCMSG] section 2.2.2.11) properties are unavailable.

<82> Section 2.1.3.4.2.2: Exchange 2003 generates the value of the PidTagAttachMimeTag property ([MS-OXCMSG] section 2.2.2.29) only in this circumstance.

<83> Section 2.1.3.4.2.2: Office Outlook 2003 and Office Outlook 2007 do not generate the Content-Description header.

<84> Section 2.1.3.4.2.2: Office Outlook 2003 uses this procedure for the Content-Description header.

<85> Section 2.1.3.4.2.2: Exchange 2003 and Office Outlook 2003 do not generate the Content-Disposition header for inline attachments.

<86> Section 2.1.3.4.2.2: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the size parameter for the Content-Disposition header.

<87> Section 2.1.3.4.2.2: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the creation-date parameter for the Content-Disposition header.

<88> Section 2.1.3.4.2.2: Exchange 2007 appends the string "GMT" to the creation-date parameter for the Content-Disposition header without adjusting the time from the server time zone to GMT.

<89> Section 2.1.3.4.2.2: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not generate the modification-date parameter for the Content-Disposition header. Exchange 2007 appends the string "GMT" to the modification-date parameter for the Content-Disposition header without adjusting the time from the server time zone to GMT.

<90> Section 2.1.3.4.2.2: Exchange 2007 appends the string "GMT" to the modification-date parameter for the Content-Disposition header without adjusting the time from the server time zone to GMT.

<91> Section 2.1.3.4.2.2: Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 copy the value as described.

<92> Section 2.1.3.4.3: Office Outlook 2003 and Office Outlook 2007 do not encode attachments in the MacBinary format.

<93> Section 2.1.3.4.3: Exchange 2007 does not ignore the presence of secondary header data in a MacBinary stream; the behavior of Exchange 2007 is undefined if secondary header data is present.

<94> Section 2.1.3.4.3:  Exchange 2003 uses this procedure for generating the attachment MIME content-type.

<95> Section 2.1.3.4.3: Exchange 2007 does not ignore the presence of additional data in a MacBinary stream; the behavior of Exchange 2007 is undefined if additional data is present.

<96> Section 2.1.3.4.3:  Exchange 2003 and Exchange 2007 use this procedure for generating the attachment MIME content-type.

<97> Section 2.1.3.4.3: Exchange 2003 uses a maximum field length of 62 bytes for the file name, rather than 63 bytes.

<98> Section 2.1.3.4.4:  Exchange 2003 sets the Content-Type header to "image/BMP".

<99> Section 2.1.3.4.4: Exchange 2003 uses "ole#.BMP" as the file name, where "#" is a digit representing the index number of the attached file.

<100> Section 2.1.3.4.4: Exchange 2003 does not produce a Content-Disposition header for OLE attachments.

<101> Section 2.1.3.4.4: Exchange 2003 keeps OLE renderings in their bitmap type. Office Outlook 2003 and Office Outlook 2007 do not convert OLE attachments. OLE attachments are omitted from the MIME version of the message.

<102> Section 2.1.3.4.6:  Exchange 2003 and Exchange 2007 do not support generating vCard attachments from MIME.

<103> Section 2.1.3.4.6: Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not support vCard version 2.1 on outbound MIME messages.

<104> Section 2.1.3.5: Exchange 2003, Exchange 2007, Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not support the functionality specified in this section.

<105> Section 2.1.3.5.1: Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 set the MIME-Version header to "1.0".

<106> Section 2.2: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 prefer TNEF body part data but will discard information from the TNEF message (such as recipients (2)) that it does not need.

<107> Section 2.2.3.1.1:  Office Outlook 2003 and Office Outlook 2007 do not check for IMCEA encapsulation and do not perform de-encapsulation.

<108> Section 2.2.3.1.2: Office Outlook 2003 and Office Outlook 2007 do not check for IMCEA encapsulation and do not perform de-encapsulation.

<109> Section 2.2.3.1.3: Office Outlook 2003 and Office Outlook 2007 will not use the attSentFor attribute, as described in [MS-OXTNEF] section 2.1.3.3.17, or the values from the PidTagSentRepresenting property group (section 2.6.5) if the From header is absent.

<110> Section 2.2.3.2: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 use the last instance of a header to set the value of the corresponding property.

<111> Section 2.2.3.2.5: Exchange 2003 only generates the Importance header, not the X-Priority header.

<112> Section 2.2.3.2.5: Exchange 2003 maps a Priority header value of "Urgent" to the PidTagImportance property ([MS-OXCMSG] section 2.2.1.11) with the value 0x00000001.

<113> Section 2.2.3.2.7:  Exchange 2007 uses this procedure to set the PidTagConversationTopic property ([MS-OXCMSG] section 2.2.1.10).

<114> Section 2.2.3.2.11: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not copy the value of the Accept-Language or X-Accept-Language header.

<115> Section 2.2.3.2.13:  Exchange 2007 selects between the two headers by using this procedure.

<116> Section 2.2.3.2.14: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not read the X-Auto-Response-Suppress header.

<117> Section 2.2.3.2.14: Exchange 2003 uses this value for the PidTagAutoResponseSuppress property ([MS-OXOMSG] section 2.2.1.77).

<118> Section 2.2.3.2.14: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 ignore the X-Auto-Response-Suppress and Precedence headers.

<119> Section 2.2.3.2.15: Exchange 2003 does not generate the Content-Class header.

<120> Section 2.2.3.2.15: Exchange 2003 sets the value of the PidTagMessageClass property ([MS-OXCMSG] section 2.2.1.3) for all Content-Class header values specified in this section to "IPM.Note".

<121> Section 2.2.3.2.15: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do no special processing for "urn:content-class:custom."

<122> Section 2.2.3.2.16: Exchange 2003 does not support the id-mapped properties used in this section: PidLidToDoTitle ([MS-OXOFLAG] section 2.2.1.12), PidLidTaskStatus ([MS-OXOTASK] section 2.2.2.2.2), PidLidTaskDueDate ([MS-OXOTASK] section 2.2.2.2.5), PidLidTaskStartDate ([MS-OXOTASK] section 2.2.2.2.4), PidLidTaskDateCompleted ([MS-OXOTASK] section 2.2.2.2.9), PidLidTaskComplete ([MS-OXOTASK] section 2.2.2.2.20), and PidLidPercentComplete ([MS-OXOFLAG] section 2.2.2.3).

<123> Section 2.2.3.2.17: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not read the X-List-Help, X-List-Subscribe, or X-List-Unsubscribe headers.

<124> Section 2.2.3.2.18: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not support retrieving the value of the PidTagAttachPayloadProviderGuidString property ([MS-OXCMSG] section 2.2.2.29).

<125> Section 2.2.3.2.18: Exchange 2003 does not write either an X-Payload-class or an X-Payload-Provider-GUID header.

<126> Section 2.2.3.2.18: Office Outlook 2003 does not generate the PidTagAttachPayloadClass property ([MS-OXCMSG] section 2.2.2.29) on incoming messages. Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not read or write the X-Payload-Class and X-Payload-Provider-GUID headers.

<127> Section 2.2.3.2.18: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 set the PidTagAttachPayloadClass property ([MS-OXCMSG] section 2.2.2.29) and the PidTagAttachPayloadProviderGuidString property ([MS-OXCMSG] section 2.2.2.29), but sets them on the attachment instead of the message.

<128> Section 2.2.3.2.18: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not read the X-Payload-Class and X-Payload-Provider-GUID headers when they appear on a MIME entity that is analyzed as a message or message body, rather than as an attachment.

<129> Section 2.2.3.2.19: Office Outlook 2003 and Office Outlook 2007 neither read nor write the PidTagPurportedSenderDomain property ([MS-OXCMSG] section 2.2.1.43).

<130> Section 2.2.3.2.20: Office Outlook 2003 and Office Outlook 2007 neither read nor write the PidTagSenderIdStatus property ([MS-OXPROPS] section 2.1004).

<131> Section 2.2.3.2.21:  Office Outlook 2003 and Office Outlook 2007 neither read nor write the PidTagContentFilterSpamConfidenceLevel property ([MS-OXCSPAM] section 2.2.1.3).

<132> Section 2.2.3.2.22: Office Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 neither read nor write the X-Microsoft-Classified header.

<133> Section 2.2.3.2.22: Exchange 2003, Office Outlook 2003 and Office Outlook 2007 do not read or set any of the classification headers.

<134> Section 2.2.3.2.23: Exchange 2003, Office Outlook 2003 and Office Outlook 2007 do not read or set any of the Unified Messaging headers.

<135> Section 2.2.3.2.24: Office Outlook 2003 and Office Outlook 2007 do not copy the value of the Content-ID header to the PidTagBodyContentId property ([MS-OXCMSG] section 2.2.1.58.7).

<136> Section 2.2.3.2.25: Office Outlook 2003 and Office Outlook 2007 do not copy the value of a Content-Base header to the PidNameContentBase property.

<137> Section 2.2.3.2.26: Exchange 2003, Office Outlook 2003 and Office Outlook 2007 do not copy the value of a Content-Location header to the PidTagBodyContentLocation property ([MS-OXCMSG] section 2.2.1.58.8).

<138> Section 2.2.3.2.27: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not read the XRef header.

<139> Section 2.2.3.2.27: Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not support copying the value of the PidNameCrossReference property (section 2.5.3).

<140> Section 2.2.3.2.28:  Office Outlook 2003 and Office Outlook 2007 set the PidTagTransportMessageHeaders property ([MS-OXOMSG] section 2.2.1.61) under this circumstance.

<141> Section 2.2.3.2.29: Exchange 2003, Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not create the named property corresponding to a generic header if (1) the mailbox database named property quota has been exceeded or (2) measures adopted to prevent exhausting the named property quota interfere with creating the named property. Office Outlook 2003 and Office Outlook 2007 do not create named properties for headers.

<142> Section 2.2.3.3.2: Exchange 2010 SP2, Exchange 2013, Exchange 2016, and Exchange 2019 create aggregate bodies for "multipart/mixed" MIME entities

<143> Section 2.2.3.3.2.2:  Exchange 2003, Exchange 2007, Exchange 2010, Office Outlook 2003, Office Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not create aggregate bodies. Exchange 2010 SP2 creates aggregate bodies if the specified values are found in the MIME-Version or X-User-Agent headers only. Update Rollup 1 for Exchange Server 2010 Service Pack 2 (SP2), Exchange 2013, Exchange 2016, and Exchange 2019 create aggregate bodies as specified.

<144> Section 2.2.3.4.1.1: Exchange 2003 replaces all of the illegal characters with the underscore "_" (U+005F), except for the backslash "\" (U+005C), which is removed.

<145> Section 2.2.3.4.1.1: Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not sanitize the display name of attachments.

<146> Section 2.2.3.4.1.1: Exchange 2007 does not strip control characters U+0001 through U+0004 from the attachment file name.

<147> Section 2.2.3.4.1.1: Exchange 2003 does not perform the steps when it creates the value of the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.11) and the value of the PidTagDisplayName property ([MS-OXCFOLD] section 2.2.2.2.2.5).

<148> Section 2.2.3.4.1.1: Exchange 2007 removes leading spaces from the start of the base. It removes trailing spaces from the end of the extension. It does not remove "." (U+002E) characters from the base.

<149> Section 2.2.3.4.1.1: Exchange 2003 copies a sanitized version of the file name to the PidTagAttachLongFilename property; it generates a base and extension only when there is no MIME file name. Exchange 2007 does not generate an extension for the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.11) when only the name portion is in a MIME message. Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 do not generate an extension when only the name portion is in a MIME message.

<150> Section 2.2.3.4.1.1: Exchange 2003 does not replace an empty display name with the base part of the file name. The display name contains only the file extension.

<151> Section 2.2.3.4.1.1: Exchange 2003 copies the value of the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.11) from the MIME header value after removing invalid file-name characters. Only step 1 of the included list of seven steps is completed before the MIME header value is copied.

<152> Section 2.2.3.4.1.1: Exchange 2003 removes plus "+" (U+002B), equal "=" (U+003D), left square bracket "[" (U+005B), right square bracket "]" (U+005D), and semicolon ";" (U+003B).

<153> Section 2.2.3.4.1.1: Exchange 2003 replaces the question mark "?" (U+003F) and the asterisk "*" (U+002A) with the underscore "_" (U+005F).

<154> Section 2.2.3.4.1.1:  Exchange 2003 does not remove the apostrophe "'" (U+0027).

<155> Section 2.2.3.4.1.1:  Exchange 2003 sets the PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11) to "NONAME" when the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.10) is empty.

<156> Section 2.2.3.4.1.1:  Exchange 2003 deletes the extension portion of the file name copied to the PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11) when the original extension is greater than three characters in length.

<157> Section 2.2.3.4.1.1:  Exchange 2003 truncates the name part of the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.10) to eight characters and does not add "~1".

<158> Section 2.2.3.4.1.1: Exchange 2003 does not generate the extension part of the PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11).

<159> Section 2.2.3.4.1.2: Exchange 2003 only replaces the "application/ms-tnef " value with "application/octet-stream" when it is the Content-Type header for the root body part.

<160> Section 2.2.3.4.1.3: Office Outlook 2003 and Office Outlook 2007 do not use the parameters of the Content-Disposition header to set creation or modification dates.

<161> Section 2.2.3.4.1.3:  Exchange 2007, Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 set the PidTagCreationTime property ([MS-OXCMSG] section 2.2.2.3) and the PidTagLastModificationTime property ([MS-OXCMSG] section 2.2.2.2) by using this procedure.

<162> Section 2.2.3.4.1.3: Exchange 2003 uses current system time to set the PidTagLastModificationTime property ([MS-OXCMSG] section 2.2.2.2).

<163> Section 2.2.3.4.1.4: Exchange 2003 does not map the Content-Base header to the PidTagAttachContentBase property ([MS-OXCMSG] section 2.2.2.29) on attachments.

<164> Section 2.2.3.4.1.4.1:  Exchange 2007 does not verify that inline attachment candidates are referenced from an <img> HTML element in the HTML message body before marking them as inline.

<165> Section 2.2.3.4.1.4.1:  The initial release version of Exchange 2010 and Microsoft Exchange Server 2010 Service Pack 1 (SP1) do not check the Content-Type header of inline attachment candidates. Exchange 2010 SP2, Exchange 2013, Exchange 2016, and Exchange 2019 check the Content-Type header.

<166> Section 2.2.3.4.1.4.1:  Microsoft Office Outlook 2007 QFE 2276479, as described in [MSKB2276479], sets both the attInvisibleInHtml and the attRenderedInBody flag in the PidTagAttachFlags property ([MS-OXCMSG] section 2.2.2.18).

<167> Section 2.2.3.4.2.1: Exchange 2003 does not write the PidNameAttachmentMacContentType property ([MS-OXCMSG] section 2.2.2.29).

<168> Section 2.2.3.4.2.1: Exchange 2003 does not write the PidNameAttachmentMacInfo property ([MS-OXCMSG] section 2.2.2.29).

<169> Section 2.2.3.4.2.1: Exchange 2003 does not reject the message as not MIME-compliant when parsing of the header part fails.

<170> Section 2.2.3.4.2.1: Exchange 2007 gets the attachment file name from AppleSingle data, instead of preferring a file name found in MIME headers.

<171> Section 2.2.3.4.2.2: Exchange 2003 does not reject the message when the MIME reader fails to parse the MIME body.

<172> Section 2.2.3.4.2.2: Exchange 2007 gets the attachment file name from AppleSingle or MacBinary data, instead of preferring a file name found in MIME headers.

<173> Section 2.2.3.4.2.2: Exchange 2003 does not map the MacBinary version number (MacBinary header offset 122) or the minimum MacBinary version number (MacBinary header offset 123) into the PidTagAttachDataBinary property ([MS-OXCMSG] section 2.2.2.7).

<174> Section 2.2.3.4.2.2: Exchange 2007 does not support a MacBinary structure with additional header data or comment part present.

<175> Section 2.2.3.4.2.2: Exchange 2003 uses a maximum field length of 62 bytes for file name, not 63 bytes.

<176> Section 2.2.3.4.2.2: Exchange 2003 does not set the signature.

<177> Section 2.2.3.4.2.2: Exchange 2003 uses bytes 75:76 to map the horizontal location of the icon.

<178> Section 2.2.3.4.2.2: Exchange 2003 uses bytes 77:78 to map the vertical location of the icon.

<179> Section 2.2.3.4.2.2: Exchange 2003 and Exchange 2007 conversion handle only EntryID values of 1, 2, 3, 8, and 9. Other EntryID values are ignored.

<180> Section 2.2.3.4.2.3: Exchange 2007 does not ignore the Content-Transfer-Encoding header when dealing with BinHex60 attachments. If the Content-Transfer-Encoding header is present, then Exchange 2007 uses the encoding method specified in the header to process the data.

<181> Section 2.2.3.4.2.3:  Exchange 2003 does not set the value of the PidNameAttachmentMacInfo property ([MS-OXCMSG] section 2.2.2.29).

<182> Section 2.2.3.4.2.3:  Exchange 2003 does not decode the attachment data and sets the PidTagAttachDataBinary property ([MS-OXCMSG] section 2.2.2.7) to the encoded binhex40 attachment data.

<183> Section 2.2.3.4.2.3: Exchange 2007 gets the attachment file name from BinHex data instead of preferring a file name found in MIME headers.

<184> Section 2.2.3.4.2.3: Exchange 2003 generates the values of the PidTagDisplayName property ([MS-OXCFOLD] section 2.2.2.2.2.5) and the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.10) from BinHex data, instead of preferring a file name found in MIME headers. The PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11) is generated from the MIME headers.

<185> Section 2.2.3.4.3:  Exchange 2003 uses this procedure when generating the PidTagDisplayName property ([MS-OXCFOLD] section 2.2.2.2.2.5).

<186> Section 2.2.3.4.3: Exchange 2003 does not write the file name value of an embedded attachment to the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.10).

<187> Section 2.2.3.4.3: Exchange 2003 does not save the resulting extension value in the PidTagAttachExtension property ([MS-OXCMSG] section 2.2.2.12).

<188> Section 2.2.3.4.3: Exchange 2003 does not generate the value of the PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11) for embedded message attachments.

<189> Section 2.2.3.4.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 do not save the X-MS-Exchange-Organization-Original-Sender header value.

<190> Section 2.2.3.4.3: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 exclude unknown MIME headers that start with "X-MS-Exchange-Organization-" or "X-MS-Exchange-Forest-" from analysis.

<191> Section 2.2.3.4.4:  Exchange 2003 and Exchange 2007 do not support converting vCard attachments to Contact objects.

<192> Section 2.2.3.4.4.1:  Exchange 2003 and Exchange 2007 do not support vCard Version 2.1.

<193> Section 2.2.3.5: Office Outlook 2003 and Office Outlook 2007 analyze attachment MIME parts with the Content-Type header set to "message/external-body" the same as they do ordinary file attachments. No special analysis is performed.

<194> Section 2.2.3.5: Exchange 2007 does not append the "URL" extension when the name is empty.

<195> Section 2.2.3.5: Exchange 2003 sanitizes the external body attachment file name using this procedure.

<196> Section 2.2.3.5: Exchange 2003 uses this procedure when the base part of the external body attachment file name is empty.

<197> Section 2.2.3.6: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not copy data into the PidTagMimeSkeleton property ([MS-OXCMSG] section 2.2.1.28).

<198> Section 2.2.3.7.1:  Exchange 2010, Exchange 2010 SP1, and Exchange 2010 SP2 do not skip processing of sets of per-recipient delivery status notification fields that contain an Action header value that does not match the highest severity value. Update Rollup 5 for Exchange Server 2010 Service Pack 2 (SP2) does skip processing of these sets of per-recipient delivery status notification fields.

<199> Section 2.2.3.9.2: Exchange 2003, Exchange 2007, Microsoft Exchange Server 2007 Service Pack 1 (SP1), and Microsoft Exchange Server 2007 Service Pack 2 (SP2) do not reject a message containing the Content-Type header of "message/partial".

<200> Section 2.4: Exchange 2007 does not have this functionality. Exchange 2003 does not have this functionality but does save the entire original MIME message.

<201> Section 2.4: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not create the PidTagMimeSkeleton property ([MS-OXCMSG] section 2.2.1.28).