2.1.3.4.3 MacBinary Attached Files

  • Article

For interoperability with Macintosh-based mail clients, MIME message attachments can be encoded in MacBinary format, which is signified by using one of the following Content-Type header values:

  • application/applefile, as specified in [RFC1740].

  • application/mac-binhex40, as specified in [RFC1741].

  • multipart/appledouble, as specified in [RFC1740].

MIME writers SHOULD<92> generate a "multipart/appledouble" format, as this MIME content-type is recommended by [RFC1740] for use in most cases.

As specified in [RFC1740], the MIME part with a MIME content-type of "multipart/appledouble" contains two subparts: a header part, with a Content-Type header value of "application/applefile", and a data part that contains actual file data (with the Content-Type header set to the value that corresponds to the actual MIME content-type of the file that is encoded).

To trigger encoding of an Attachment object with a MIME content-type of  "multipart/appledouble", clients set property values on the Attachment object as follows:

  1. The value of the PidTagAttachMethod property ([MS-OXCMSG] section 2.2.2.9) is 0x00000001 (file attachment).

  2. The value of the PidTagAttachEncoding property ([MS-OXCMSG] section 2.2.2.20) is the following byte string (expressed in hexadecimal): "%x2A.86.48.86.F7.14.03.0B.01".

  3. The attachment content, which is the value of the PidTagAttachDataBinary property ([MS-OXCMSG] section 2.2.2.7), is encoded in MacBinary format.

MacBinary is a way of serializing all attributes of a Macintosh file, including both data and resource forks, into a single stream (2). The MacBinary format elements relied upon in this algorithm are summarized very briefly by the following two tables. What follows is intended to specify server behavior with respect to MacBinary data; it is not normative with respect to the MacBinary format itself. Additional details on the MacBinary format are specified in [MacBin].

The following table describes the MacBinary data fields.

MacBinary data field

Field length

Description

MacBinary header

128 bytes.

See more detail later in this section.

Secondary header data

Length is specified in bytes 120:121 of the MacBinary header.

SHOULD<93> be ignored by MIME writers. If bytes 120:121 have nonzero values, MIME writers MAY<94> write the attachment MIME content-type as "application/octet-stream" instead of "application/appledouble". The resource and data forks are not returned as separate attachments.

Data fork

Length is specified in bytes 83:86 of the MacBinary header; begins on an even multiple of 128 bytes.

Contents of the file.

Resource fork

Length is specified in bytes 87:90 of the MacBinary header; begins on an even multiple of 128 bytes.

Resources associated with the file.

Get Info comment

Length is specified in byte 99 of the MacBinary header.

SHOULD<95> be ignored by MIME writers. If byte 99 has a nonzero value, MIME writers MAY<96> write the attachment MIME content-type as "application/octet-stream" instead of "application/appledouble". The resource and data fork are not returned as separate attachments.

The following table describes the MacBinary header.

Byte offset and length

Value

Byte 0

Old version number; MUST be zero.

Byte 1

Length of file name; MUST be less than 64.

Bytes 2:64

File name, in us-ASCII character set; characters beyond the length specified in byte 1 MUST be ignored.<97>

Bytes 65:68

File type, signed integer.

Bytes 69:72

File creator, signed integer.

Byte 74

Pad; MUST be 0 (zero).

Byte 82

Pad; MUST be 0 (zero).

Bytes 83 : 86

Data fork length, signed 32-bit integer in big-endian format.

Bytes 87 : 90

Resource fork length, signed 32-bit integer in big-endian format.

MIME writers MUST create a MIME entity with a Content-Type header value of "multipart/appledouble", as specified in [RFC1740]. MIME writers SHOULD NOT write a name parameter for the Content-Type header in this MIME part. (This parameter is optional, as specified in [RFC1740].) All additional information (other than the file contents) for a file that is to be transmitted by using the " MIME content-type of "multipart/appledouble" SHOULD be put into a subpart with the Content-Type header value "application/applefile".

If the Attachment object's PidNameAttachmentMacInfo property ([MS-OXCMSG] section 2.2.2.29) has a value, MIME writers MUST use it as the body of the "application/applefile" body part. The value of this property SHOULD be "application/applefile" data, as specified in [RFC1740] and further detailed in section 2.2.3.4.2.2, but containing only the header and resource fork sections.

If the Attachment object's PidNameAttachmentMacInfo property has no value, MIME writers SHOULD generate the body of the "application/applefile" body part from the resource fork and header data present in the MacBinary structure from the PidTagAttachDataBinary property, by using the mappings specified in section 2.2.3.4.2.2. This MIME part is written out in the same way as in the case of an ordinary file attachment, with the following exceptions:

  1. MIME writers MUST generate this part's MIME body by extracting only the file's data fork from the MacBinary structure in the PidTagAttachDataBinary property on the Attachment object, instead of just using raw data from this property.

  2. MIME writers SHOULD copy the value of the PidNameAttachmentMacContentType property ([MS-OXCMSG] section 2.2.2.29) to the MIME data part's Content-Type header.

If the PidNameAttachmentMacContentType property has no value, MIME writers SHOULD write a Content-Type header value of "application/octet-stream". An "application/octet-stream" value SHOULD also be written if the PidNameAttachmentMacContentType property has one of the following values:

  • message/rfc822

  • application/applefile

  • application/mac-binhex40

  • any multipart MIME content-type