Share via

2.2.3.5 External Body Attachments

  • Article

Attachment MIME parts with a Content-Type header set to "message/external-body" SHOULD be analyzed in the same way as ordinary file attachments, with the exceptions specified in this section.<193>

If the Content-Type header has no access-type parameter, or if the value of that parameter is not "anon-ftp", MIME readers SHOULD save the entire MIME part in the PidTagAttachDataBinary property ([MS-OXCMSG] section 2.2.2.7) on the Attachment object.

Otherwise, the following differences in MIME analysis apply:

  • Different file name extraction logic SHOULD be applied, as specified later in this section.

  • MIME readers SHOULD ignore the MIME part body. Instead, a specially formatted URL data string is saved in the PidTagAttachDataBinary property in ASCII format, as specified in this section.

  • In this case, MIME readers expect the name, site, directory, and mode parameters to be present in the Content-Type header. Clients SHOULD NOT create MIME that does not include these parameters.

The URL data string to save in the PidTagAttachDataBinary property is constructed as follows. The values xchar and lowalpha used in this definition are specified in [RFC1738].

 "[InternetShortcut]" CR LF "URL=ftp://" site "/" directory "/" name [mode]
 ;contains header "site" parameter value
 site=1*xchar 
  
 ;contains header "directory" parameter value
 directory=1*xchar
 ;contains header "name" parameter value
 name=1*xchar
 ;if header "mode" parameter is "ascii", contains ";type=a"
 ;if header "mode" parameter is "image, contains ";type=i"
 ;otherwise not present
 mode=";type=" 1*lowalpha CR LF

The file name extraction logic is similar to that for ordinary file attachments, with the following exceptions:

  1. MIME readers use the name parameter value from the Content-Type header as a value of the attachment file name. The file extension (a part of the file name after the last appearance of the "." character) SHOULD be replaced with "URL"; if the original file name has no extension, "URL" SHOULD be added at the end of the file name string.<194>

  2. The sanitizing logic specified in section 2.2.3.4.1.1 SHOULD NOT be applied in this case. MIME readers MAY<195> sanitize the external body attachment file name by replacing the following characters with the underscore "_" (U+005F): double quote """ (U+0022), forward slash "/" (U+002F), colon ":" (U+003A), left angle bracket "<" (U+003C), right angle bracket ">" (U+003E), pipe "|" (U+007C), and backslash "\" (U+005C).

  3. The file name value constructed in Step 1 SHOULD be used as an attachment display name as well.

  4. All additional filtering logic specified in section 2.2.3.4.1.1 still applies in this case.

  5. The procedure for calculating a value for the PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11) is the same as for embedded message attachments specified in section 2.2.3.4.3. If the base part of the external body attachment file name is empty, MIME readers MAY<196> set the value of the PidTagAttachFilename property ([MS-OXCMSG] section 2.2.2.11) to "NONAME.URL" and the value of the PidTagAttachLongFilename property ([MS-OXCMSG] section 2.2.2.10) to "URL".