Content Issues when Logging or Updating a Call from E-Mail
| Status: | Published |
|---|---|
| Version: | 1.3 |
| Authors: | HTL QA |
| Applies to: | Supportworks ESP |
When you log or update a call from an e-mail message, the text of that message should automatically be copied into the call's description field (subject to an appropriate setting in Analyst Properties), ultimately showing up in a call-diary entry. This content has to be plain text, as the call diary does not support formatted text.
Now, according to the RFC 1521 standard, e-mail messages received over the Internet should contain both plain-text and HTML-text parts. Normally, Supportworks uses the plain-text part when copying text from a message to a call, regardless of the actual message format. However, the absence of the plain part (due, for example, to non-conformity by the sender's e-mail system) can cause problems for Supportworks.
If the plain part is absent, Supportworks will attempt to extract the text from the HTML part, and you may see unwanted HTML characters and codes in the call's description field. If Supportworks is unable to extract this text, you will end up with no text at all in the call's description field.
Either way, the issue is with the sender's e-mail system or with how your POP3/IMAP4 mail server has been configured, rather than with Supportworks. The following simple examples illustrate the above more clearly.
Example 1: When there is no plain-text part in a message
It is possible to receive an e-mail message that contains only HTML and no plain text. As in the following screenshot, the content appears OK when you simply view the message:
However, when you update the call from the message, you will notice in the call's description field that there is additional VML\HTML mark-up that was not visually present in the original message.
The reason for this is that, on updating the call, the client tries to find the plain-text part of the message but, failing to do so, performs a "best attempt" extraction to obtain the text from the HTML part. This may result in some HTML/VML/XML mark-up being left. (The mark-up will have been added by the original e-mail compose program to format the message and include various options. In recent years, the amount of formatting and options has been increasing, especially where MS Outlook or MS Word is used as the message editor.)
In MS Exchange 2007 SP3 and MS Exchange 2010, Microsoft changed the way in which e-mail messages are presented to the client (which would include the Supportworks server). Now, when messages are downloaded via POP3/IMAP4, instead of providing both the plain-text and HTML parts, Microsoft only provides the HTML part. This does not conform to the RFC for Internet e-mail. Microsoft have produced the following knowledgebase articles detailing how to resolve this issue:
For Exchange 2007...
For Exchange 2010...
Note that in Supportworks 7.6.0 we have implemented a method to strip out Text from a HTML only message in an attempt to workaround Microsoft's changes.
We can also state that MS Office 365 is running MS Exchange 2012 in the background with default settings which means that NO Plain text part is provided when downloading the email (Against the RFC), this can result in unwanted HTML markup being visible in calls logged\updated from email. The resolve is to ensure that you are running 7.6.0 or above in which we have added code to deal with Micforsoft lack of compliance and attempt to strip out any text from the HTML body and use this as the plain text.
The process of stripping text from HTML is not 100% "accurate" due to the nature of HTML and you may still see some HTML markup (Usually for non US-Ascii Characters e.g ’ for smart apostrophe quotes)
Unfortunatly, as there may be actual HTML markup within the body of the email that is required (For example developer attempting to update a call stating that they want to add ’ to list of allowed characters) we can not perform a replace of these when obtaining the text from HTML and these will be shown.
The only full resolve would be to contact your Microsoft agent and request that they enable Plain Text and HTML on the given connector (either POP3 or IMAP)
Example 2: When the text in the plain-text part differs from the text in the HTML part
It is possible for an e-mail message (especially if it is marketing\spam mail) to be received with an HTML-text part that states one thing and a plain-text part that states another. In the example of a received message below, the HTML part is displayed as expected, showing formatted text:
However, when we attempt to log a call from this message, we find that the call's description field and the relevant call-diary entry has changed to some other content in plain text, as shown here:
Although the original message complies with RFC 1521 in that it has both of the required parts (HTML and plain), it is not within the spirit of the RFC, as the parts should be the same. Unfortunately, little can be done to correct the above, as the Supportworks client would see a valid plain-text part.