BinHex MIME: MIME Content Type for BinHex Encoded Files
How to send Macintosh files as MIME email attachments using BinHex 4.0 encoding.
Faltstrom, P., Crocker, D., and E. Fair, "MIME Content Type for BinHex Encoded Files", RFC 1741, DOI 10.17487/RFC1741, December 1994, <https://www.rfc-editor.org/info/rfc1741>.
@misc{rfc1741,
series = {Request for Comments},
number = 1741,
howpublished = {RFC 1741},
publisher = {RFC Editor},
doi = {10.17487/RFC1741},
url = {https://www.rfc-editor.org/info/rfc1741},
author = {P. Faltstrom and D. Crocker and E. Fair},
title = {{MIME Content Type for BinHex Encoded Files}},
pagetotal = 6,
year = 1994,
month = dec,
} RFC text
Contents
Network Working Group P. Faltstrom
Request for Comments: 1741 Royal Institute of Technology
Category: Informational D. Crocker
Brandenburg Consulting
E. Fair
Apple Computer Inc.
December 1994
MIME Content Type for BinHex Encoded Files
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This memo describes the format to use when sending BinHex4.0 files
via MIME [BORE93]. The format is compatible with existing mechanisms
for distributing Macintosh files. Only when available software
and/or user practice dictates, should this method be employed. It is
recommended to use application/applefile [FALT94] for maximum
interoperability.
1. Introduction
Files on the Macintosh consists of two parts, called forks:
DATA FORK: The actual data included in the file. The Data
fork is typically the only meaningful part of a
Macintosh file on a non-Macintosh computer system.
For example, if a Macintosh user wants to send a
file of data to a user on an IBM-PC, she would only
send the Data fork.
RESOURCE FORK: Contains a collection of arbitrary attribute/value
pairs, including program segments, icon bitmaps,
and parametric values.
Additional information regarding Macintosh files is stored by the
Finder has in a hidden file, called the "Desktop Database".
Because of the complications in storing different parts of a
Macintosh file in a non-Macintosh filesystem that only handles
consecutive data in one part, it is common to convert the Macintosh
file into some other format before transferring it over the network.
AppleDouble file format [APPL90], encoded in MIME as
multipart/appledouble [FALT94] and application/applefile [FALT94] is
the preferred format for a Macintosh file that is to be included in
an Internet mail message, because it provides recipients with
Macintosh computers the entire document, including Icons and other
Macintosh specific information, while other users easily can extract
the Data fork (the actual data).
However, this specification provides for use of the currently popular
BinHex4.0 encoding schemes, as a convinience to the installed base of
users.
2. MIME format for BinHex4.0
MIME-base Apple information is specified by:
MIME type-name: APPLICATION
MIME subtype name: MAC-BINHEX40
Required parameters: none
Optional parameters: NAME, which must be a "value" as
defined in RFC-1521 [BORE93].
Encoding considerations: none
Security considerations: See separate section in the document
Published specification: Appendix A
Rationale: Permits MIME-based transmission of data
with Apple Macintosh file system specific
information using a currently popular,
though platform specific, format.
2a. Detail specific to MIME-based usage
Macintosh documents do not always need to be sent in a special
format. Those documents with well-known MIME types and non-
existent or trivial resource forks can be sent as regular MIME
body parts, without use of AppleSingle, AppleDouble or BinHex4.0.
Documents which lack a data fork must be sent as AppleSingle
according to RFC 1740 [FALT94].
Unless there are strong reasons not to, all other documents should
be sent as AppleDouble according to RFC 1740 [FALT94]. This
includes documents with non-trivial resource forks, and documents
without corresponding well-known MIME types.
It may be valuable in some cases to allow the user to choose one
format over another, either because he disagrees with the
implementor's definition of "trivial" resource forks, or for
reasons of his own.
Only when available software and/or user practice dictates, should
BinHex 4.0 be employed.
3. BinHex
BinHex 4.0 is a propular means of encoding Macintosh files for
archiving on non-Macintosh file systems and for transmission via
Internet mail. (See Appendix A for a brief description of the BinHex
4.0 format.)
The content-type application/mac-binhex40 indicates that the body of
the mail is a BinHex4.0 file. Even though the BinHex encoding
consists of characters which are not the same as those used in Base64
(those regarded as safe according to RFC-1521 [BORE93]) a
transportation encoding should not be done.
Even though a BinHex file includes the original Macintosh filename,
it is recommended that a name parameter be included on the Content-
Type header to give the recipient a hint as to what file is attached.
The value of the name parameter must be a "value" as defined by RFC-
1521 [BORE93]. Note that this restricts the value to seven-bit US-
ASCII characters.
3a. BinHex example
Content-Type: application/mac-binhex40; name="car.hqx"
[The BinHex4.0 file goes here]
4. References
APPL90 AppleSingle/AppleDouble Formats for Foreign Files
Developer's Note, Apple Computer, Inc., 1990.
FALT94 Faltstrom P., Crocker, D., and E. Fair, "MIME
Encapsulation of Macintosh Files - MacMIME", RFC 1740,
KTH, Brandenburg Consulting, Apple Computer Inc.,
December 1994.
BORE93 Borenstein N., and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, Bellcore,
Innosoft, September 1993.
5. Security Considerations
To the extent that application/mac-binhex40 facilitates the
transmission of operating-system sensitive data, it may open a door
for easier relaxation of security rules than is intended either by
the sender of the administrator of the sender's system.
6. Acknowledgements
Thanks to all of the people on the ietf-822 list who have provided
much meaningful input for this document. Some of them must though be
remembered by name, because they have almost crushed my mailbox the
last weeks with a very nice and interesting debate:
Johan Berglund, Steve Dorner, David Gelhar, David Herron, Raymond
Lau, Jamey Maze, John B. Melby, Jan Michael Rynning, Rens Troost,
and Peter Svanberg.
7. Authors' Addresses
Patrik Faltstrom
Department of Numerical Analysis and Computing Science
Royal Institute of Technology
S-100 44 Stockholm
Sweden
EMail: paf@nada.kth.se
Dave Crocker
Brandenburg Consulting
675 Spruce Dr.
Sunnyvale, CA 94086
EMail: dcrocker@mordor.stanford.edu
Erik E. Fair
Engineering Computer Operations
Apple Computer Inc.
EMail: fair@apple.com
Appendix A. The BinHex format
Here is a description of the Hqx7 (7 bit format as implemented in
BinHex 4.0) formats for Macintosh Application and File transfers.
The main features of the format are:
1) Error checking even using ASCII download
2) Compression of repetitive characters
3) 7 bit encoding for ASCII download
The format is processed at three different levels:
1) 8 bit encoding of the file:
Byte: Length of FileName (1->63)
Bytes: FileName ("Length" bytes)
Byte: Version
Long: Type
Long: Creator
Word: Flags (And $F800)
Long: Length of Data Fork
Long: Length of Resource Fork
Word: CRC
Bytes: Data Fork ("Data Length" bytes)
Word: CRC
Bytes: Resource Fork ("Rsrc Length" bytes)
Word: CRC
2) Compression of repetitive characters.
($90 is the marker, encoding is made for 3->255 characters)
00 11 22 33 44 55 66 77 -> 00 11 22 33 44 55 66 77
11 22 22 22 22 22 22 33 -> 11 22 90 06 33
11 22 90 33 44 -> 11 22 90 00 33 44
The whole file is considered as a stream of bits. This stream will
be divided in blocks of 6 bits and then converted to one of 64
characters contained in a table. The characters in this table have
been chosen for maximum noise protection. The format will start
with a ":" (first character on a line) and end with a ":".
There will be a maximum of 64 characters on a line. It must be
preceded, by this comment, starting in column 1 (it does not start
in column 1 in this document):
(This file must be converted with BinHex 4.0)
Any text before this comment is to be ignored.
The characters used is:
!"#$%&'()*+,- 012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
AI ELI5
On this page
§1The Macintosh File Problem
Macintosh files are more complex than files on other computers. They have two parts: the data fork, which contains the actual file data, and the resource fork, which contains program code, icons, fonts and other metadata about the file. Additionally, the Finder stores extra information about each file in a hidden Desktop Database.
When sending a Mac file to a non-Macintosh computer or through email, the file structure breaks down because most file systems only handle single-part files. Historically, the solution was to convert the Mac file into another format before sending. BinHex 4.0 is a popular encoding scheme that turns Macintosh files into text that can be safely transmitted through email, using 7-bit ASCII characters.
Mac files have extra parts that Windows computers do not understand. BinHex turns a Mac file into plain letters and numbers so you can email it. The RFC explains how to label it.
§2BinHex 4.0 Encoding
BinHex 4.0 works in three stages. First, it encodes the 8-bit Macintosh file structure (including filename, type, creator, flags, data fork and resource fork lengths, and checksums) as a binary stream. Second, it compresses repetitive characters by marking consecutive identical bytes with a special marker byte (0x90). Third, it converts the resulting bits into 6-bit blocks and encodes each block as one of 64 safe ASCII characters.
The BinHex format starts and ends with a colon (:) and includes a maximum of 64 characters per line. Files must include the comment '(This file must be converted with BinHex 4.0)' so that decoders recognize them as BinHex files.
BinHex takes a Mac file and turns it into letters and numbers, protecting it from getting damaged during email. It also compresses it if the same byte repeats many times.
§3MIME Type Definition
This RFC defines the MIME content type application/mac-binhex40 for BinHex 4.0 encoded files. The type is called APPLICATION and the subtype is MAC-BINHEX40. No encoding parameters are required, though the optional NAME parameter can provide a filename hint to the recipient. The NAME parameter value must use only seven-bit US-ASCII characters as defined in RFC 1521.
Even though BinHex files consist of characters that differ from those used in Base64 encoding, no transport encoding should be applied to BinHex files. The BinHex characters are already safe for email transmission. The email header should include the Content-Type field with the type and optional name parameter, for example: Content-Type: application/mac-binhex40; name="document.hqx"
The MIME type tells email software: 'This is a BinHex file.' You can optionally add a filename hint so the person knows what it is.
§4When to Use BinHex versus Alternatives
This RFC acknowledges that better alternatives exist. For Macintosh documents with well-known MIME types and trivial or nonexistent resource forks, it is better to send them as regular MIME body parts without any special encoding. For documents that lack a data fork entirely, AppleSingle should be used instead. For all other documents with non-trivial resource forks or no corresponding MIME type, AppleDouble is the preferred format, as it preserves both forks and lets non-Macintosh users easily extract the data fork.
BinHex 4.0 should only be employed when available software or user practice requires it. It is a convenience format for the installed base of BinHex users, not the recommended standard for new implementations.
BinHex works but is old-fashioned. Modern email should use AppleDouble instead, which works better for everyone. Only use BinHex if you have to.
§5Security Implications
The ability to transmit Macintosh-specific data through MIME-based email creates a potential security risk. BinHex preserves the operating system-specific information from Macintosh files, including executable code in the resource fork. This could allow an attacker to craft a malicious Macintosh application disguised as a simple data file, transmit it through email and trick a user on a Macintosh into executing it.
System administrators and email system operators should be aware that BinHex-encoded files may contain executable code, and appropriate warnings and security policies should be in place when receiving such files.
BinHex can hide programs inside attachments. Email systems need to be careful about BinHex files because they might contain harmful code that could damage a computer.