Difference between revisions of "Email and Supportworks"
| Line 51: | Line 51: | ||
A typical email consists of 3 parts (Plus part for each attachment) , the Header, A Plain text part and a HTML Part. The client (e.g Outlook 2010) decides which part to show (Plain\HTML) and then shows this according to its settings. The RFC states that the content-type should come from the associated part, however Outlook (amongst others) incorrectly uses the first one it comes across (Microsoft actual state that this is an optimisation rather than a defect) | A typical email consists of 3 parts (Plus part for each attachment) , the Header, A Plain text part and a HTML Part. The client (e.g Outlook 2010) decides which part to show (Plain\HTML) and then shows this according to its settings. The RFC states that the content-type should come from the associated part, however Outlook (amongst others) incorrectly uses the first one it comes across (Microsoft actual state that this is an optimisation rather than a defect) | ||
| − | [[File:mailformatdiagram. | + | [[File:mailformatdiagram.png]] |
Revision as of 12:42, 4 June 2015
| Status: | Published |
|---|---|
| Version: | 1.2 |
| Authors: | HTL QA |
| Applies to: | Supportworks ESP |
Introduction
In order to meet the requirements for Email (RFC8228 and its associated RFCs), any email sent must contain a Plain Text Part and then optionally any subsequent formats (i.e. HTML) that the sending client is capable of Supplying. Each of these parts is capable of being encoded in a given Character set (http://en.wikipedia.org/ wiki/Character_encoding) and each Character set has specific characters that can be displayed. For example US-ASCII has the $ symbol but not the € symbol and therefore any email sent as plain text in US-ASCII will not be able to use the € symbol directly and will need to encode this (=80). It is then up to the receiving client to decode this.
In Supportworks all Plain Text Parts of Emails will be sent as US-ASCII and therefore all non US-ASCII characters encoded. (Note that this does not include the Subject – which can only be plain text only). When the receiving client opens the email it will attempt to decode the email based on it's own character set configuration. If the character set contains a mapping for =80, it will display the character from it's set. If no value found it will generally display a ? or other character that may appear to be incorrect in the context of the message. If both the sender and receiver have the same character set then it's likely that they will see the expected character, however there is no absolute guarantee of this.
HTML is slightly different, whilst the part of the message is sent (within Supportworks) in US-ASCII, the charset of the HTML, with any given message, can be set within header information sections of each part of that particular message - that comprises a complete message. The character set used is most likely to come from the local machine (ie Charset-windows-1252) therefore any characters encoded within the HTML to the specified charsets requirements (For example the € symbol becomes &^ in Windows-1252). On receipt of the email it is the client's responsibility to decode the HTML and display it, which can only occur completely successfully if the specified charset is available to the client application.
For most clients, the character set in use comes from the local machine or browser settings or email header, rather than Content Type for the given Part. Testing a few of the more common email clients shows that only Gmail reliably takes the Content type from message parts - rather than somewhere else, and therefore other client software is most likely to have issues with displaying of non US-ASCII characters.
| Clients | Content Type |
|---|---|
|
Each take the Content-Type from the header of your email - See below |
|
Each convert the Content-Type to UTF-8 |
Format of a MIME Email
A typical email consists of 3 parts (Plus part for each attachment) , the Header, A Plain text part and a HTML Part. The client (e.g Outlook 2010) decides which part to show (Plain\HTML) and then shows this according to its settings. The RFC states that the content-type should come from the associated part, however Outlook (amongst others) incorrectly uses the first one it comes across (Microsoft actual state that this is an optimisation rather than a defect)
