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.
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.
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.
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?
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :