Emails sent from Internet or application generated emails are not delivered to users. They NDR with "#554 5.6.0 STOREDRV.Deliver; Corrupt message content ##"


Symptoms


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 ##

Cause


If you check the message headers for the  format of the message:

Content-Type: application/mac-binhex40
Content-Transfer-Encoding: base64

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.

Resolution


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-Type: application/mac-binhex40
Content-Disposition: attachment; filename="example.doc"

Indicating that the document is encoded using the RFC standard mac-binhex40 format.

More Information


As per RFC 1741

RFC 1741 - MIME Content Type for BinHex Encoded Files
http://www.packetizer.com/rfc/rfc1741/

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):


For more information you can also reference:

2.2.4.2.3 Application/Mac-binhex40

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 2.2.4.1, 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 2.2.4.2.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>

2.2.4.2.3 Application/Mac-binhex40
http://msdn.microsoft.com/en-us/library/ee158076(v=exchg.80).aspx