08-09-2016 04:04 AM
Hello,
could I have please a feedback about the bug and it's resolution status of Defect CSCuy53537?
It is regarding the error message:
Cisco Ironport C370 Message Scanning Problem: local variable 'tmp_file_path'
Thank you.
Regards,
Sandor
08-09-2016 08:11 PM
Are you receiving similar error:
Tue Jul 1 12:34:56 2016 Warning: MID 12345678, Message Scanning Problem: local variable 'tmp_file_path' referenced before assignment
The bug you have referenced at this time is only tied to a Beta release version, and from what I can tell not currently addressed. Please let me know further if this is not the matching error, or if your scanconfig settings have been changed at all...
One workaround would be to adjust the scanconfig > setup to assure that it is set for "deliver" in the bolded section of the "setup" configuration as shown:
10.0.0-125.local> scanconfig
There are currently 5 attachment type mappings configured to be SKIPPED.
Choose the operation you want to perform:
- NEW - Add a new entry.
- DELETE - Remove an entry.
- SETUP - Configure scanning behavior.
- IMPORT - Load mappings from a file.
- EXPORT - Save mappings to a file.
- PRINT - Display the list.
- CLEAR - Remove all entries.
- SMIME - Configure S/MIME unpacking.
[]> setup
1. Scan only attachments with MIME types or fingerprints in the list.
2. Skip attachments with MIME types or fingerprints in the list.
Choose one:
[2]>
Enter the maximum depth of attachment recursion to scan:
[5]>
Enter the maximum size of attachment to scan:
[5242880]>
Do you want to scan attachment metadata? [Y]>
Enter the attachment scanning timeout (in seconds):
[30]>
If a message has attachments that were not scanned for any reason (e.g. because of size, depth limits, or scanning timeout), assume the attachment matches the search pattern? [N]>
In case of a content or message filter error, should all filters be bypassed? [Y]>
Assume zip file to be unscannable if files in the archive cannot be read?
[0]>
If a message could not be deconstructed into its component parts in order to remove specified attachments, the system should:
1. Deliver
2. Bounce
3. Drop
[1]>
Configure encoding to use when none is specified for plain body text or anything with MIME type plain/text or plain/html.
1. US-ASCII
2. Unicode (UTF-8)
3. Unicode (UTF-16)
4. Western European/Latin-1 (ISO 8859-1)
5. Western European/Latin-1 (Windows CP1252)
6. Traditional Chinese (Big 5)
7. Simplified Chinese (GB 2312)
8. Simplified Chinese (HZ GB 2312)
9. Korean (ISO 2022-KR)
10. Korean (KS-C-5601/EUC-KR)
11. Japanese (Shift-JIS (X0123))
12. Japanese (ISO-2022-JP)
13. Japanese (EUC)
[1]>
08-10-2016 03:49 AM
Dear Robert,
thanks for your response. Yes, it is exactly about that error message - which comes sporadically in our system. However, it affectes partly .7z type of attachments, which are normally blocked in our environment, but when the error happens, these attachments are let through and get delivered. (The reason for blocking is that they might contain viruses, compressed, just like zips.)
Your workaround hint is also already known for us, we are still discussing whether or not to implement it.
We simply just had better a final permanent solution for this error, that's all.
Regards,
Sandor
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide