The primary subtype of application, "octet-stream", may be used to indicate that a body contains binary data. The set of possible parameters includes, but is not limited to:
TYPE -- the general type or category of binary data. This is intended as information for the human recipient rather than for any automatic processing. PADDING -- the number of bits of padding that were appended to the bit-stream comprising the actual contents to produce the enclosed byte-oriented data. This is useful for enclosing a bit-stream in a body when the total number of bits is not a multiple of the byte size.
An additional parameter, "conversions", was defined in [RFC-1341] but has been removed.
RFC 1341 also defined the use of a "NAME" parameter which gave a suggested file name to be used if the data were to be written to a file. This has been deprecated in anticipation of a separate Content-Disposition header field, to be defined in a subsequent RFC.
The recommended action for an implementation that receives application/octet-stream mail is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process.
To reduce the danger of transmitting rogue programs through the mail, it is strongly recommended that implementations NOT implement a path-search mechanism whereby an arbitrary program named in the Content-Type parameter (e.g., an "interpreter=" parameter) is found and executed using the mail body as input.