Export (0) Print
Expand All

5 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Microsoft Exchange Server 2003

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2010

  • Microsoft Exchange Server 2013

  • Microsoft Office Outlook 2003

  • Microsoft Office Outlook 2007

  • Microsoft Outlook 2010

  • Microsoft Outlook 2013

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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.3.1: Exchange 2003, Office Outlook 2003, Office Outlook 2007, Outlook 2010, and Outlook 2013 identify any message that has a message class suffix of "SMIME.MultipartSigned" as a clear-signed message; however, this is not recommended for other clients or servers.

<2> Section 2.1.3.1: Exchange 2007, Exchange 2010, Exchange 2013, Office Outlook 2007, Outlook 2010, and Outlook 2013 recognize messages that were signed and encrypted by Office InfoPath 2007, InfoPath 2010, or InfoPath 2013, and for such messages, they use a dynamically determined message class that starts with the prefix "IPM.InfoPathForm" and ends with the suffix "SMIME" or "SMIME.MultipartSigned", as specified in [MS-OXCMAIL] section 2.1.3.2.1. Exchange 2007, Exchange 2010, and Exchange 2013 recognize such message classes as identifying opaque-signed, encrypted, or clear-signed messages, despite the fact that, in general, they do not recognize other message classes ending with the suffix "SMIME" or "SMIME.MultipartSigned".

<3> Section 2.1.3.1: A value of "IPM.Note.SMIME" in Exchange 2003 is ambiguous in respect to defining message format. It is recommended that a client or server that is required to interoperate with Exchange 2003 disambiguate the "IPM.Note.SMIME" Message object either by analyzing the content of an attachment (for example, the value of the Attachment objectPidTagAttachDataBinary property ([MS-OXPROPS] section 2.580)) or by inspecting the value of the Attachment objectPidTagAttachMimeTag property ([MS-OXPROPS] section 2.593). If the value represents a valid multipart/signed MIME entity, it is recommended that the client or server identify the message as a clear-signed message and interpret the message according to section 2.1.3.1.

<4> Section 2.1.3.1: Exchange 2003 sets the PidTagAttachFilename property ([MS-OXPROPS] section 2.584) to a value of "SMIME.txt". Exchange 2007, Exchange 2010, and Exchange 2013 set the PidTagAttachFilename property to a value of "SMIME.p7m". Office Outlook 2003, Office Outlook 2007, Outlook 2010, and Outlook 2013 do not set the PidTagAttachFilename property when converting a message from the Internet e-mail message format to the Message object format. Office Outlook 2003, Office Outlook 2007, Outlook 2010, and Outlook 2013 set the PidTagAttachFilename property to a value of "SMIME.p7m" when creating a new Message object.

<5> Section 2.1.3.1: Exchange 2003 sets the PidTagAttachLongFilename property ([MS-OXPROPS] section 2.586) to a value of "SMIME.txt". Office Outlook 2003, Office Outlook 2007, and Outlook 2010, and Outlook 2013 do not set the PidTagAttachLongFilename property.

<6> Section 2.1.3.1: Exchange 2003 sets the PidTagDisplayName property ([MS-OXPROPS] section 2.667) to a value of "SMIME.txt". Office Outlook 2003, Office Outlook 2007, Outlook 2010, and Outlook 2013 do not set the PidTagDisplayName property.

<7> Section 2.1.3.1.2.2: Office Outlook 2003, Exchange 2003, Office Outlook 2007, Outlook 2010, and Outlook 2013 identify any message that has a message class suffix of "SMIME.MultipartSigned" as a clear-signed message. In general, however, this is not recommended for other clients or servers.

<8> Section 2.1.3.1.2.2: Exchange 2007, Exchange 2010, Exchange 2013, Office Outlook 2007, Outlook 2010, and Outlook 2013 recognize messages that were signed and encrypted by Office InfoPath 2007, InfoPath 2010, or InfoPath 2013, and for such messages, they use a dynamically determined message class that starts with the prefix "IPM.InfoPathForm" and ends with the suffix "SMIME" or "SMIME.MultipartSigned", as specified in [MS-OXCMAIL] section 2.1.3.2.1. Exchange 2007, Exchange 2010, and Exchange 2013 recognize such message classes as identifying opaque-signed, encrypted, or clear-signed messages, despite the fact that, in general, they do not recognize other message classes ending with the suffix "SMIME" or "SMIME.MultipartSigned".

<9> Section 2.1.3.2: Exchange 2003, Office Outlook 2003, Office Outlook 2007, Outlook 2010, and Outlook 2013 set the message class to "IPM.Note.Receipt.SMIME" when they identify an S/MIME message that contains a secure receipt, as indicated by the smime-type parameter with a value of "signed-receipt" on the Content-Typeheader field, as specified in [RFC2045] section 5. Exchange 2003, Office Outlook 2003, Office Outlook 2007, Outlook 2010, and Outlook 2013 identify any message that has the message class suffix "SMIME" as an opaque-signed or encrypted message; however, this is not recommended for other clients or servers.

<10> Section 2.1.3.2: Exchange 2007, Exchange 2010, Exchange 2013, Office Outlook 2007, Outlook 2010, and Outlook 2013 recognize messages that were signed and encrypted by Office InfoPath 2007, InfoPath 2010, or InfoPath 2013, and for such messages, they use a dynamically determined message class that starts with the prefix "IPM.InfoPathForm" and ends with the suffix "SMIME" or "SMIME.MultipartSigned", as specified in [MS-OXCMAIL] section 2.1.3.2.1. Exchange 2007, Exchange 2010, and Exchange 2013 recognize such message classes as identifying opaque-signed, encrypted, or clear-signed messages, despite the fact that, in general, they do not recognize other message classes having suffixes "SMIME" or "SMIME.MultipartSigned".

<11> Section 2.1.3.2.2.2: Exchange 2007, Exchange 2010, Exchange 2013, Office Outlook 2007, Outlook 2010, and Outlook 2013 recognize messages that were signed and encrypted by Office InfoPath 2007, InfoPath 2010, or InfoPath 2013, and for such messages, they use a dynamically determined message class that starts with the prefix "IPM.InfoPathForm" and ends with the suffix "SMIME" or "SMIME.MultipartSigned", as specified in [MS-OXCMAIL] section 2.1.3.2.1. Exchange 2007, Exchange 2010, and Exchange 2013 recognize such message classes as identifying opaque-signed, encrypted, or clear-signed messages, despite the fact that, in general, they do not recognize other message classes ending in the suffix "SMIME" or "SMIME.MultipartSigned".

<12> Section 2.1.3.2.2.2: In Exchange 2003, if a Message object has a message class value of "IPM.Note.SMIME", it is possible that the message represents a mislabeled clear-signed message with inner opaque-signed or encrypted content. This means that, in Exchange 2003, the message class "IPM.Note.SMIME" is ambiguous with respect to defining message format. It is recommended that a client or server that is required to interoperate with Exchange 2003 disambiguate the "IPM.Note.SMIME" Message object either by analyzing the content of an attachment (for example, the value of the Attachment objectPidTagAttachDataBinary property ([MS-OXPROPS] section 2.580)) or by inspecting the value of the Attachment objectPidTagAttachMimeTag property ([MS-OXPROPS] section 2.593). If the value represents a valid multipart/signed MIME entity, it is recommended that the client or server identify the message as a clear-signed message and interpret the message according to section 2.1.3.1.

Show:
© 2014 Microsoft