RFC 1740 (December 1994) defines how Macintosh files are carried in MIME email, using these two formats. It reprints the version 2 structures in its appendices.
The media types
| Type | Carries |
|---|---|
application/applefile | An AppleSingle file, or the header part of an AppleDouble message |
multipart/appledouble | An AppleDouble file, as two parts |
A multipart/appledouble message has exactly two parts. The first is the
header file, as application/applefile. The second is the data fork alone, as
whatever media type suits its content, or application/octet-stream when none
does. The parts appear in that order.
Binary content is best sent in Base64, which the RFC considers the safest encoding.
The name parameter
Both types take an optional name parameter holding the file’s name. It is
an RFC 1521 value, so seven-bit US-ASCII only. The RFC recommends giving it on the
Content-Type of an application/applefile part, and on both parts
of a multipart/appledouble.
Which format to use
- A file with a well-known media type and an empty or trivial resource fork can be sent as an ordinary body part.
- A file with no data fork must be AppleSingle.
- Everything else should normally be AppleDouble, including files with a substantial resource fork and files with no registered media type.
A mail program may let its user override the choice.
A security note
The RFC warns that carrying operating-system data in mail, such as a file’s type and creator and the resource fork, may weaken security rules that the sender or an administrator intended to enforce.