Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
2.2.3.4.3 Attached Messages

2.2.3.4.3 Attached Messages

If an attachment MIME part has its Content-Typeheader (2) set to "message/rfc822" (or no Content-Type header (2) is present, and this MIME part is a sub-part of the "multipart/digest" MIME part), MIME readers SHOULD treat this attachment as an embedded message attachment, and set the value of the Attachment object'sPidTagAttachMethod property ([MS-OXCMSG] section 2.2.2.9) to "5".

MIME analysis for MIME headers (2) SHOULD be performed by the server in the same way as for ordinary file attachments, with the exception that the procedure for extracting the display name and file name for the attachment is different.

The display name for embedded message attachments is extracted from MIME part headers (2) in the following order:

  1. If a Content-Type header (2) is available on the attachment MIME part, and a non-empty name parameter is available on this header (2), its value SHOULD be used.

  2. Otherwise, if a Content-Disposition header (2) is available on the attachment MIME part, and a non-empty filename parameter is available on this header (2), its value SHOULD be used.

  3. Otherwise, if a Content-Description header (2) is available on the attachment, and its value is non-empty, it SHOULD be used.

  4. Otherwise, if a Subject header (2) is available on the attachments, and its value is non-empty, it SHOULD be used. A MIME reader MAY<185> use this header (2) in preference to the Content-Description header value.

  5. If none of these conditions apply, the MIME reader SHOULD generate a name at random, or use a name derived from some other text value related to the Attachment object.

The resulting value SHOULD be written to the PidTagDisplayName property ([MS-OXCFOLD] section 2.2.2.2.2.5) on the attachment, and then processed further to obtain a valid file name, as follows:

  1. All Unicode separator characters in the file name SHOULD be replaced with the "?" character (U+003F).

  2. All trailing and starting space and "." characters SHOULD be removed.

The file name is then separated into base and extension parts. To do this, the server SHOULD look for the last occurrence of any of the following characters:

  • backslash, "\", U+005C

  • forward slash, "/", U+002F

  • colon, ":", U+003A

  • period, ".", U+002E

If a "." (U+002E) character is the last one found, the part of the file name that precedes this character is considered to be base, and the rest is considered to be extension. In all other cases, extension is considered to be an empty string, and base part is considered to be the same as whole file name.

The resulting file name value SHOULD<186> be written to the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.10), and the resulting extension value SHOULD<187> be saved in the PidTagAttachExtension property ([MS-OXCMSG] section 2.2.2.12). The file name SHOULD then be processed further to obtain a valid 8.3 name, as follows:

  1. The value SHOULD be first separated into base and extension parts, by using the last "." character as a separator (if no such character is present, the extension is considered to be empty; the separator character itself is not included in the name or extension).

  2. "+", ",", "=", "[", "]", and ";" characters SHOULD be replaced with the "_" (underscore) character.

  3. Space, ".", "\", "/", "*", "<", ">", "?", ":", and "|" characters, as well as characters with UTF8 code greater than 127, SHOULD be removed.

  4. If the base becomes an empty string, a non-empty string, such as a random string or other auto-generated value, SHOULD be used.

  5. The base part of the file name SHOULD be trimmed to 8 characters; the extension part to 3 characters.

If either the name or the extension changed, the base part SHOULD additionally be trimmed to 6 characters, and "~1" SHOULD be added to its end.

The file name is saved in the <base>.<extension> format.

The resulting file name SHOULD<188> be written to the PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11).

The MIME part body for this attachment SHOULD be used for further MIME analysis that SHOULD result in assigning values to the properties of the embedded message from this attachment. This MIME analysis is performed in a way that is similar to that for ordinary MIME messages, with the following exceptions:

  1. The X-MS-Exchange-Organization-Original-Sender header value SHOULD<189> be saved in the PidNameQuarantineOriginalSender property ([MS-OXPROPS] section 2.463), if the header value is present.

  2. Unknown MIME headers (2), starting with "X-MS-Exchange-Organization-" or "X-MS-Exchange-Forest-", SHOULD NOT<190> be excluded from analysis.

After MIME analysis is done for the embedded message, the PidTagMessageFlags property ([MS-OXCMSG] section 2.2.1.6) SHOULD be modified; the mfUnsent flag ("0x8") SHOULD be removed, and the mfRead flag SHOULD be reset to 0x0.

Show:
© 2015 Microsoft