We have IronPort (AsyncOS v5.0) SMTP appliances in between Domino and the Internet. However recently we have noticed some delivery failures returning to the Lotus Notes senders which domino doesn’t seem able to MIME convert correctly.
$MIMETrack: Itemize by SMTP Server on HOSTNAME/OU/O (Release 7.0.1FP1|April 17, 2006) failed at 02/16/2007 11:38:02 AM: Incorrect format in MIME data.
$FILE:
$IntMailMsgFileName: $RFC822.eml
Body: [MIME content for this item is stored in attachment $RFC822.eml. Parsing MIME content failed: Incorrect format in MIME data…]
This does not appear to happen for all delivery failures and there doesn’t seem to be a specific server causing the issue.
Subject: $RFC822.eml received for delivery failures
Hi all,
here’s a solution for this problem from Ironport as IBM is not going to provide a solution for this. I’ve set the value to 26214400 which is the max. size.
Subject: RE: $RFC822.eml received for delivery failures
I know this is a very old thread, but since IBM still hasn’t offered a solution and the link supplied by Klaus has expired, I thought I’d help document the solution.
This problem is related to the way that Notes interprets bounce messages/NDRs under RFC3464. It states that they should consist of three MIME parts, and the third MIME part should contain the initial bounced message or parts therof. If the message that was bounced was a message containing multiple MIME parts itself, the bounce/NDR may be truncated somewhere, leaving open
MIME boundaries. This is OK and allowed by the RFC. However, Notes (and according to Cisco, some other mail clients) attempt to be smart about displaying the NDR and run inline scans in the MIME part containing the bounced message. This leads to the errors that you are receiving from your Notes server “MIME content for this item is stored in attachment $RFC822.eml. Parsing MIME content failed: Incorrect format in MIME data”. In other words, Notes considers the DSN message as a whole to be invalid because it contains a truncated MIME part.
The solution provided to me by Cisco (and Klaus too, I assume) is to configure the Ironport server to return the entire contents of the original message in the DSN. By default, IronPort only includes the first 10k, but you should change that limit to match the maximum message size that you allow in your environment. In Cisco AsyncOS 6 and 7, this is accomplished using the ‘bounceconfig’ command from the command-line interface of the IronPort. Just type bounceconfig and then press enter to accept all current configuration settings until you see "Please enter the maximum size of the original message (in bytes) to include in
the bounced notification message." Set that to match the maximum message size that you’ve configured in your Mail Flow Policy.
But when it comes right down to it, this isn’t something that you should have to do (and it’s a waste of bandwidth). If the RFC specifies that the DSN may be truncated, IBM should fix Notes so that it properly handles DSNs that are truncated.
As it is now, all of the useful non-delivery data gets shoved into an attachment, not to mention one that never arrives if your Person document specifies that you prefer Rich Text!!
Subject: $RFC822.eml received for delivery failures
Welcome to the club, we have IronPort AsyncOS v5.0 and have experienced the same symptoms. However, I’m learning towards Domino as the culprit due to the fact I also support and Exchange environment with about 18K users. The Exchange infrastructure leverages the IronPort infrastructure for inbound traffic only.
So far I’ve isolated the problem with .eml files being generated on delivery failures only. Do you have the same issue?
Also I’ve isolated the issue to versions so far of Domino 6.51 and 6.53.
Regarding Domino 6.51 at my company there is a customized client lotus script program that touches outbound email for a certain audience adding extra fields to the document and these are present within the .eml afflicted delivery failures.
6.53 produces these .eml files with no help from any other programs.
As you’ve mentioned it isn’t a consistent behavior I currently have a ticket open with Lotus. Keeping in mind the email is generated from the client I believe Domino places something in the email that isn’t mime standard.
Subject: RE: $RFC822.eml received for delivery failures
We recently updated to IronPort AsyncOS v5.1 (from 4.9) and since then we face the described problems.
We use Notes 7.0.1 (server and clients).
As far as I see the $RFC822.eml mails are deliver failures from certain mail systems. The same original mail produces sometimes a correct delivery message and in other cases a mail with the mentioned .eml attatchment.
Subject: RE: $RFC822.eml received for delivery failures
Seems to be the same problem in our system but there is a little difference: When people send out mails with attachements, they only get an error mail with Subject “Delivery Status Notification (Failure)” and in the body there comes the text “[MIME content for this item is stored in attachment $RFC822.eml. Parsing MIME content failed: Incorrect format in MIME data…]”. But there is no attachement “$RFC822.eml”. In some deeper tests we found out that this attachement comes in the failure message finally on users mail server (mail.box) and when pasted to users mailfile it is not delivered. Our last test showes that only password protected or encrypted attachements (like *.pdf or *.zip) produce this error, when sending unencrypted *.pdf the error message is correct, with primary sended attachement at the end. Might be someone can find out any solution, we use Domino 6.5.5 FP1 on Linux Mail Servers and the same Domino release on our windows 2000 gateway that is connected to the IronPort AntiSpam…
Subject: RE: $RFC822.eml received for delivery failures
You problems sounded similar to the one I am having.I have a user that is getting the “MINE content…” message. He is trying to send an e-mail with a PDF File attachment, created from SAP, via Lotus Notes, and he is getting a delivery failure message, with the MIME message, and the .eml file.
As a test, I sent an e-mail with a PDF file created from FreePDF, and it when through fine.