220.127.116.11.3 Attached Messages
If an attachment MIME part has its Content-Type header set to "message/rfc822" (or no Content-Type header 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's PidTagAttachMethod property ([MS-OXCMSG] section 18.104.22.168) to "5".
MIME analysis for MIME headers 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 in the following order:
If a Content-Type header is available on the attachment MIME part, and a non-empty name parameter is available on this header, its value SHOULD be used.
Otherwise, if a Content-Disposition header is available on the attachment MIME part, and a non-empty filename parameter is available on this header, its value SHOULD be used.
Otherwise, if a Subject header is available on the attachments, and its value is non-empty, it SHOULD be used. A MIME reader MAY<185> use this header in preference to the Content-Description header value.
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.
All Unicode separator characters in the file name SHOULD be replaced with the "?" character (U+003F).
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 22.214.171.124), and the resulting extension value SHOULD<187> be saved in the PidTagAttachExtension property ([MS-OXCMSG] section 126.96.36.199). The file name SHOULD then be processed further to obtain a valid 8.3 name, as follows:
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).
"+", ",", "=", "[", "]", and ";" characters SHOULD be replaced with the "_" (underscore) character.
Space, ".", "\", "/", "*", "<", ">", "?", ":", and "|" characters, as well as characters with UTF8 code greater than 127, SHOULD be removed.
If the base becomes an empty string, a non-empty string, such as a random string or other auto-generated value, SHOULD be used.
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 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:
Unknown MIME headers, 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 188.8.131.52) SHOULD be modified; the mfUnsent flag ("0x8") SHOULD be removed, and the mfRead flag SHOULD be reset to 0x0.