Some email received from External Organizations or Application Generated Email is not delivered to users.
You will receive the following NDR:
#554 5.6.0 STOREDRV.Deliver; Corrupt message content ##
If you check the message headers for the format of the message:
You will notice the qualifying line: Content-Transfer-Encoding: base64 for mac-binhex type of document.
This indicates that the actual data is base64 encoded.
Since Exchange Server only accepts the RFC standard mac-binhex encoding, these messages are rejected.
The sender should be sending the attachment in correctly formatted mac-binhex40 format.
The correctly formatted mac-binhex40 message header should have the following Content lines:
Content-Disposition: attachment; filename="example.doc"
Indicating that the document is encoded using the RFC standard mac-binhex40 format.
As per RFC 1741
RFC 1741 - MIME Content Type for BinHex Encoded Files
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)
Word: Flags (And $F800)
Long: Length of Data Fork
Long: Length of Resource Fork
Bytes: Data Fork ("Data Length" bytes)
Bytes: Resource Fork ("Rsrc Length" bytes)
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):
For more information you can also reference:
This section specifies MIME analysis for MIME parts with Content-Type application/mac-binhex40, as specified in [RFC1741].
The procedure of MIMEheader analysis for application/mac-binhex40 attachments is the same as for the procedure for ordinary file attachments that is specified in section 188.8.131.52, with the following exceptions:
1.MIME readers set the value of the PidTagAttachMimeTagproperty to "application/mac-binhex40".
2.The value of the Content-Transfer-Encoding header MUST be ignored.<188> MIME readers use BinHex decoding, as specified in [RFC1741], instead.
Processing of the MIME body SHOULD include parsing a binary structure of the decoded content, as specified in [RFC1741]. MIME readers SHOULD use the header and resource fork data from this structure to fill the PidNameAttachmentMacInfo property with appropriate data, as specified in section 184.108.40.206.1. MIME readers SHOULD also use this data to fill the MacBinary structure, which SHOULD be written to the value of the PidTagAttachDataBinary property.<189>
If parsing of the BinHex data fails, the entire message SHOULD be rejected by the MIME reader as not MIME compliant.<190>
MIME readers SHOULD copy the attachment file name that is extracted from the BinHex structure to the value of PidTagAttachFilename, but only if no file name was found during analysis of the MIME headers.<191><192>