|Email Plug-in (Reporting):||1.0.1-048|
|Email Plug-in (Encryption):||1.0.0-036|
can some tell me what this error messages means exactly? Some users reported that attachments were corrupted or missing ( seems that the attachments gets part of the mail body... ) Most of the mails affected are beeing genereated by an XYZ application and then sent over our ironports to the internet, where this wonder happens :roll: ...
thanks in advance,
Try increasing your mail_log to DEBUG mode and monitor the mail_logs for messages that originate from XYZ application.
Paste the results here if possible.
Please check your message header.
I expect your application is using some bogus multipart formatting or maybe a unusual encoding character set.
If you post your header info we (the Forum) might be able to help.
here the information from the maillog in debug mode:
Wed Apr 29 17:59:12 2009 Warning: MID 12345678, Message Scanning Problem: Trailing garbage
Wed Apr 29 17:59:12 2009 Debug: scanning: MID 12345678: ('qstore/body_scanner.py _scan_uuencoded|1525', "
", 'Trailing garbage', '[qstore/body_scanner.py scan_message|777] [_coro.pyx coro._coro.sched.with_timeout|1054] [qstore/body_scanner.py _scan_message|726] [qstore/body_scanner.py _scan_msg_from_file|748] [qstore/body_scanner.py _scan_part|1911] [qstore/body_scanner.py _scan_file|1189] [_coro.pyx coro._coro.sched.with_timeout|1054] [qstore/body_scanner.py _scan_uuencoded|1525]')
What version of AsyncoS are you running and what happens to this message after it encounters that message scanning error? Does the message get treated as unscannable? Does the recipient eventually get the mail? Is the attachment and message body still intact or was something being stripped out?
Can you paste the entire MID?
we are running 6.5-405. The message get's delivered, but the attached CSV Files get shredded and you will see the "contents" of the CSV in the Message Body. The Message Body looks like you open an .xls file in the editor ;-)
nothing get's stripped out.
We are seeing the same issue. Just went live with our system last weekend, and many users report gibberish from an attachment automatically sent out by an app. Thanks!
i got that answer:
...The is likely due to the way the XYZ application is compiling the MIME of the messages in the question. Message scanning problems like these can occur in a variety of ways due to corrupt attachments or broken MIME structure. When this happens the message should be treated as unscannable. If the cause of the problem was that 2 lines in the MIME were somehow merged, then the decoded attachment would be corrupt.
If you would like to see the MIME of messages exactly as it was sent to the IronPort, enable an Injection Debug Log with the XYZ applications IP address.
The following Knowledge Base article provides steps for enabling Injection Debug Logs.
Yes, that is exactly what you need. The injection debugs will show all chars received including linefeed chars. I have seen your exact symptoms before when the generating mail client or intermediate FW incorrectly formats the message to include extra linefeeds in between header lines. Something like:
Date: Fri, 17 Jul 2009 21:53:48 -0400
From: Foo Bar
User-Agent: Thunderbird 220.127.116.11 (Windows/20090605)
***** bogus CRLF *****
In this example, some mail clients will display everything after "MIME-Version: 1.0" as message body - including attachments, images, HTML formatting, etc. Interestingly, some MUA's like gmail and hotmail might have more robust code to strip out the extra lines and fix things for you!
So, please include the logs with your case and/or this topic for further analysis.
I have the same problem where a script that runs on an AIX server using sendmail creates an email with an attachment, is there a way to correct the email? I only get this error when the emails goes to Yahoo, Gmail, or AOL. Not when they go to Exchange or Domino.
everyone of those companies is likely using custom SMTP clients and servers just like IronPort. you will get varying degrees of reactionary programming to parse these poorly formatted messages differently to recover from poor coding on the generating side.
also look out for firewall inspection who might be altering packets out to the interweb but not to your internal mail servers!
The Exchange and Domino servers are external also.
I forgot to mention I have the same problem when the emails go to our IEA. Are there any settings on the IEA that I could tweak so it would be more forgiving of bad coding like Exchange and Domino ?
i believe that this case could be more involved than described here already. while we may not be able to fix an issue, we can definitely help you identify the root cause. you should open a formal support case with us if this is a business critical situation.
I have opened a ticket, it has been opened for over 30 days and support still does not have a solution. I thought someone on the forum might have had the same problem and had a fix. I see others have the same problem, but no one has the answer yet.
Your problem is most likely caused by the script that is generating the messages.
An injection debug log should give all information needed to determine the problem, giving you the information to correct your script. Although this is not really an Ironport issue the Nation might be able to help you solving your problem if you are able to post the complete contents of your injection debug log.
As you noticed there are mail systems "out there" that are not willing to accept bogus message configurations. I doubt if this is really an Ironport problem. Correcting this at the source will be the most optimal solution.
i am sorry that your experience with support was not the greatest. we all give 110% here for our customers.
if you PM me with your case number, I can follow up with you out-of-band and make sure your case is getting the attention you need. AS ALWAYS, we will automatically REOPEN your case if you need simply by replying to one of our 'customercare' emails or calling in to our support lines and mentioning the case number.
steven is right though, it may very well be a non-ironport issue and we have yet to see definitive evidence of what's happening.