Delivery Failure creates $RFC822.eml attachment.

[MikeKoehn]

Delivery Status Notification (Failure) bounces to our Lotus Notes/Domino server will often return with an attached $RFC822.eml file instead of the Domino formatted delivery failure (which provides ease of reading the failure reason as well as resending the message).

This occurs when a 'complex' attachment exists on the email. If there is no attachment or if the attachment is a small txt file or something similar, the standard Notes delivery failure report is presented to the sender.

I recall finding on IBM's discussion forum that this is due to Ironport generating a non-RFC compliant message header - something about there being an extra space somewhere in the header....

Does anyone have any experience troubleshooting this?

Is there a fix, either in an updated version of the ESA or Domino? We're currently running AsyncOS 6.3.0 (upgrading to 6.4 soon) and Domino 7.03.

[kluu_ironport]

Great post Michael.

Here is more info on the issue you're running into.


When receiving bounces for messages send out with attachments Lotus Notes throws out the following error:

"[MIME content for this item is stored in attachment $RFC822.eml. Parsing
MIME content failed: Incorrect format in MIME data..]"
Solution:

RFC3464 describes how bounce messages have to look like. They consist off three mime parts. In the third there may be contained the bounced message or parts of it. If the message that was bounced was a message containing of multiple mime parts as well this message might get truncated somewhere leaving open mime boundaries in the message. This is OK and allowed by the RFC. However Notes (and many other clients) try to be smart about displaying the message and do inline scans in the mime part containing the part of the bounced message. This leads to the error mentioned above in Notes.

This is tracked by IBM:

http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/a87c6d7e5a0bdd96852572880050c23a?OpenDocument

IBM has identified this as SPR #TMIZ5P3EY3, but there are no plans when this is fixed:

http://www-1.ibm.com/support/docview.wss?uid=swg21153770





Feature Request #1167 has been filed that suggest an option to leave the third part of the bounce message (the part that might contain parts of the original message) completely empty. This is still in line with RFC 3464 and would prevent the Error on Notes.

To work around the Notes problem you can not use the standard NDR. If you go to GUI -> Network -> bounce profile you can set to it not use the default NDR (Use DSN format for bounce messages: set this to NO). Notes will then no longer complain about the MIME. However you are not sending out NDR as the RFC asks you to.

Good luck,

Kevin

[aliebrahim]

I am also having this problem and have for now implemented the solution posted by kluu, though I am not particularly happy about sending out non-RFC compliant DSNs (though it beats relying on the user to open the $RFC822.eml attachment which I'm pretty sure none of my users do).

If this is a problem that a lot of Ironport/Domino users are having, and I am sure it must be as it is a pretty common combination, then can Ironport work with IBM to get this problem resolved so that it can parse DSN messages generated by Ironport properly?

According to this thread, Ironport blames Notes for not parsing RFC compliant DSNs which are allowed to have open MIME boundaries. IBM blames the DSNs which they say must have closed MIME boundaries.

So if Ironport is correct can they not work with IBM to solve this?

[klkel_ironport]

Hi,

here's the solution:

https://www.ironportnation.com/forums/viewtopic.php?t=1099&start=0&postdays=0&postorder=asc&highlight=bounce+profile

I've set the value to 262144000

Cheers,
Klaus

[dface1982]

would be great to see the content of this link which obviously contains a solution since ironportnation.com is not longer available.

Any way to recover this posting?