Site icon MxCloudPro

Exchange Message Content conversion

Microsoft Exchange Mail routing Message Content Conversion Process.

 

Content conversion

 

Content conversion is the process of correctly formatting a message for each recipient. The decision to perform content conversion on a message depends on the destination and format of the message. They types of content conversion that occur in Exchange 2016 and Exchange 2019 are unchanged from Exchange 2013:

Exchange and Outlook message formats

The following list describes the basic message formats available in Exchange and Outlook:

The resulting plain text message can be represented in the following formats:

Outlook and other email clients that fully understand TNEF process the Winmail.dat attachment and display the original message content without ever displaying the Winmail.dat attachment. Email clients that don’t understand TNEF may present TNEF messages in any of the following ways:

There are third-party utilities that can help convert Winmail.dat attachments.

TNEF is understood by all versions of Exchange since Exchange Server version 5.5.

STNEF is understood by all versions of Exchange since Exchange 2000. STNEF is automatically used for all messages transferred between Exchange servers in the organization since native mode Exchange Server 2003.

Exchange never sends STNEF messages to external recipients. Only TNEF messages can be sent to recipients outside the Exchange organization.

Content conversion options for external recipients

The content conversion options that you can set in an Exchange organization for external recipients can be described in the following categories:

These conversion and encoding options are independent of one another. For example, whether TNEF messages can leave the Exchange organization isn’t related to the MIME encoding settings or plain text encoding settings of those messages.

You can specify the content conversion at various levels of the Exchange organization as described in the following list:

For more information about these settings, see TNEF conversion options and Message encoding options in Exchange Server.

Understanding the structure of email messages

To better understand the content conversion options for external recipients, you need to understand the structure of email messages. An SMTP message is based on plain 7-bit US-ASCII text to compose and send email messages. A standard SMTP message consists of the following elements:

A field name must be composed of printable US-ASCII text characters except the colon (:) character. Specifically, ASCII characters that have values from 33 through 57 and 59 through 126 are permitted.

A field body may be composed of any US-ASCII characters, except for the carriage return (CR) character and the line feed (LF) character. However, a field body may contain the CR/LF character combination when used in header folding. Header folding is the separation of a single header field body into multiple lines as described in section 2.2.3 of RFC 5322. Other field body syntax requirements are described in sections 3 and 4 of RFC 5322.

When SMTP messages contain elements that aren’t plain US-ASCII text, the message must be encoded to preserve those elements. The MIME standard defines a method of encoding content in messages that isn’t text. MIME allows for text in other character sets, attachments without text, multipart message bodies, and header fields in other character sets. MIME is defined in RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, and RFC 2049. MIME defines a collection of header fields that specifies additional message attributes. The following sections describe some important MIME header fields.

MIME-Version header field

Default value1.0

This header field is the first MIME header field that appears in a MIME-formatted message. This header field appears after the other standard RFC 5322 header fields, but before any other MIME header fields. MIME-aware email clients use this header field to identify a MIME-encoded message. When this header field is absent, MIME-aware email clients identify the message as plain text.

Content-Type header field

Default valuetext/plain

This header field identifies the media type of the message content as described in RFC 2046. A media type consists of:

Content-Transfer-Encoding header field

Default value7bit

This header field can describe the following information about a message:

There can be multiple values of the Content-Transfer-Encoding header field in a MIME message. When the Content-Transfer-Encoding header field appears in the message header, it applies to the whole body of the message. When the Content-Transfer-Encoding header field appears in one of the parts of a multipart message, it applies only to that part of the message.

When an encoding algorithm is applied to the message body data, the message body data is transformed into plain US-ASCII text. This transformation allows the message to travel through older messaging servers that only support messages in US-ASCII text. The Content-Transfer-Encoding header field values that indicate an encoding algorithm was used on the message body are:

Typically, you won’t see multiple encoding algorithms used in the same message.

When no encoding algorithm has been used on the message body, the Content-Transfer-Encoding header field merely identifies the current condition of the message body data. The Content-Transfer-Encoding header field values that indicate that no encoding algorithms were used on the message body are:

The whole message body may be 7-bit, or part of the message body in a multipart message may be 7-bit. If the multipart message contains other parts that have any binary data or non-US-ASCII text, that part of the message must be encoded using the Quoted-printable or Base64 encoding algorithms.

Messages that have 7-bit bodies can travel between messaging servers by using the standard DATA command.

The whole message body may be 8-bit, or part of the message body in a multipart message may be 8-bit. If the multipart message contains other parts that have binary data, that part of the message must be encoded using the Quoted-printable or Base64 encoding algorithms.

Messages that have 8-bit bodies can only travel between messaging servers that support the 8BITMIME SMTP extension as defined in RFC 6152, such as Exchange 2000 Server or later. Specifically, this means that the following conditions must be true:

Messages that have binary bodies can only travel between messaging servers that support the BINARYMIME SMTP extension as defined in RFC 3030, such as Exchange 2000 Server or later. Specifically, this means that the following conditions must be true:

The values 7bit8bit, and Binary never exist together in the same multipart message (the values are mutually exclusive). The Quoted-printable or Base64 values may appear in a 7-bit or 8-bit multipart message body, but never in a binary message body. If a multipart message body contains different parts composed of 7-bit and 8-bit content, the whole message is classified as 8-bit. If a multipart message body contains different parts composed of 7-bit, 8-bit, and binary content, the whole message is classified as binary.

Content-Disposition header field

Default valueAttachment

This header field instructs a MIME-enabled email client on how it should display an attached file, and is described in RFC 2183. Valid values are:

Ref: https://docs.microsoft.com/en-us/exchange/mail-flow/content-conversion/content-conversion?view=exchserver-2019

 

Exit mobile version