We have CSV file(s) attached to emails which are sent to create incidents. Why are these files not being attached to the incident as expected or are opening up as jumbled text?

Environment:

Incoming Emails, File Attachments
Oracle RightNow Service

Resolution:

This behavior has been seen when automated emails are being generated by an outside source and is due to the attachment being received as straight text. The issue involves the formatting of the message by the script used to generate these messages and files.

There are two possible symptoms to this issue. Attachments will not be attached to the incident and will instead be pasted into the incident thread as jumbled text.

Or the file will be attached to the incident however upon opening it, it's contents contain jumbled text.

An incoming message needs details to identify the parts of that message (ie: text body part, attachment body part...). Without these boundary identifiers, techmail is taking the attachment and bringing it in as part of the email body.

From: email.address@adomain.com

To: email.address@anotherdomain.com

Subject: This is the subject for unique value (e.g., timestmap) so subject unique

Content-Type: multipart/mixed; boundary="label.boundry.1388181139"

Date: Fri, 27 Dec 2013 15:52:20 -0600 (CST)

--label.boundry.1388181139

Content-Type: text/plain; charset=US-ASCII

Content-Transfer-Encoding: 7bit

Hello

This is the email body mentioning that this email contains an attachment.

and the file is named: log20131227155219.log
Good day

--label.boundry.1388181139

Content-Type: text/plain\; name="log20131227155219.log"

Content-Disposition: attachment\; filename="log20131227155219.log"

Content-Transfer-Encoding: UTF-8

--label.boundry.1388181139--

To confirm whether or not the incoming messages creating these incidents are formatted correctly with the proper boundary identifiers:

1. Ensure that the EGW_SAVE_ORIG_MESSAGE configuration is enabled as per Answer ID 2762: Maintaining copies of incoming email for incident creation

2. Open the .mht file attached to the incident in a text editor and determine if the boundary identifiers are present in the original message.

3. Compare this to the .mht file used to create an incident where the CSV file was properly attached to determine if the boundary identifiers are being properly included in the message.

Between the beginning and ending attachment boundary identifer, there will be base64 encoded content which will be for the file itself. It there is any incorrect encoded content in there, such as normal text, this will throw off the formatting of the entire file and may cause the file attachment to not be saved correctly.

To resolve this issue, you will want to correct the script used to generate these messages and attachments and ensure that these boundary identifiers are being generated correctly.