Преобразование содержимого

 

Применимо к:Exchange Server 2013

Последнее изменение раздела:2016-12-09

Преобразование содержимого — это процесс надлежащего форматирования сообщения для каждого получателя. Необходимость преобразования содержимого обрабатываемого сообщения зависит от его назначения и формата. В службе Microsoft Exchange Server 2013 существует два различных вида преобразования содержимого:

  • Преобразование сообщения для внешних получателей   этот тип преобразования содержимого включает параметры преобразования в формат Transport Neutral Encapsulation Format (TNEF) и параметры кодировки сообщений для внешних получателей. Для сообщений, отправленных получателям в пределах организации Exchange, этот тип преобразования содержимого не требуется. Он обрабатывается классификатором в службе передачи на сервере почтовых ящиков. Классификация каждого полученного сообщения производится после его помещения в очередь передачи. Кроме разрешения получателей и маршрутизации преобразование содержимого сообщения выполняется перед помещением сообщения в очередь доставки. Если одно сообщение адресовано нескольким получателям, классификатор определяет приемлемую кодировку для каждого получателя сообщения. Ошибки преобразования содержимого, обнаруженные классификатором в ходе преобразования сообщений, отправляемых внешним получателям, при трассировке преобразования содержимого не регистрируются.

  • Преобразование MAPI для внутренних получателей   этот тип преобразования содержимого обрабатывается службой передачи почтовых ящиков. Служба передачи почтовых ящиков используется на серверах почтовых ящиков для передачи сообщений между базами данных сообщений на локальном сервере и службой передачи на серверах почтовых ящиков. А именно, служба отправки и передачи почтовых ящиков передает сообщения из папки "Исходящие" отправителя службе передачи на сервере почтовых ящиков. Служба отправки и передачи почтовых ящиков передает сообщения от службы передачи на сервере почтовых ящиков в папку "Входящие" получателя. Служба отправки и передачи почтовых ящиков преобразует все исходящие сообщения с формата MAPI, а служба доставки и передачи почтовых ящиков преобразует все входящие сообщения в формат MAPI. Ошибки преобразования MAPI регистрируются при трассировке преобразования содержимого. Дополнительные сведения см. в разделе Трассировка преобразования контента.

В этом разделе объясняются параметры преобразования сообщений для внешних получателей.

Содержание

Форматы сообщений Exchange и Outlook

Параметры преобразования содержимого для внешних получателей

Понимание структуры сообщений электронной почты

Ниже описаны основные форматы сообщений, доступные в службе Exchange и приложении Microsoft Outlook:

  • Обычный текст   Обычное текстовое сообщение включает только текстовые знаки US-ASCII в соответствии со спецификацией RFC 2822. Разные шрифты или другие способы форматирования текста в сообщении использоваться не могут. Ниже описаны два возможных формата обычного текстового сообщения.

    • Заголовки и тело сообщения состоят из текстовых знаков US-ASCII. Вложения кодируются с использованием алгоритма Uuencode («Unix-to-Unix encoding»). Данный алгоритм представляет собой кодировку Unix-to-Unix и позволяет хранить двоичные вложения в тексте сообщения электронной почты с использованием текстовых символов US-ASCII.

    • Сообщение кодируется в кодировке MIME со значением text/plain в поле Content-Type и значением 7bit в поле Content-Transfer-Encoding в случае текстовых частей составного сообщения. Любые вложения кодируются с использованием алгоритма Quoted-printable или Base64. По умолчанию при создании и отправке обычного текстового сообщения в приложении Outlook сообщение кодируется в кодировке MIME со значением text/plain в качестве поля Content-Type.

  • HTML   В сообщениях с текстом в формате HTML поддерживается форматирование текста, фоновые изображения, таблицы, списки и другие графические элементы. Для сохранения этих элементов форматирования сообщения в формате HTML должны кодироваться в кодировке MIME.

  • Формат RTF   Формат RTF поддерживает форматирование текста и другие графические элементы. Формат RTF — синоним TNEF. (Transport Neutral Encoding Format). Формат RTF для сообщений не имеет ничего общего с форматом RTF для документов в приложении Microsoft Word.

    Сообщения в формате RTF поддерживаются только приложением Outlook и некоторыми другими почтовыми клиентами MAPI.

  • TNEF   это специфический формат Transport Neutral Encapsulation Format, используемый корпорацией Microsoft для инкапсуляции свойств сообщений MAPI. Сообщение в формате TNEF содержит сообщение в виде обычного текста и вложение, в которое упакована исходная отформатированная версия сообщения. Как правило, это вложение называется Winmail.dat. В его состав входят следующие элементы:

    • оригинальная отформатированная версия сообщения, включающая, например, текст разного размера и текст, выделенный разными шрифтами и цветами;

    • объекты OLE, например встроенные изображения или документы Microsoft Office;

    • специальные элементы Outlook, например настраиваемые формы, кнопки голосования и приглашения на собрания;

    • обычные вложения, которые имелись в исходном сообщении

    Получающееся обычное текстовое сообщение может быть представлено в следующих форматах:

    • сообщение, соответствующее спецификации RFC 2822 и включающее только текстовые знаки US-ASCII с вложением Winmail.dat в кодировке Uuencode;

    • составное сообщение в кодировке MIME с вложением Winmail.dat

    Почтовый клиент, соответствующий спецификации MAPI и полностью поддерживающий формат TNEF (такой как Outlook), обрабатывает вложение Winmail.dat и выводит содержимое исходного сообщения, не отображая вложение Winmail.dat. Почтовый клиент, не поддерживающий формат TNEF, может представить сообщение TNEF несколькими способами, которые описаны ниже.

    • Отображается обычная текстовая версия сообщения, при этом сообщение содержит вложение с именем Winmail.dat, Win.dat или каким-либо другим универсальным именем, таким как Attnnnnn.dat или Attnnnnn.eml, где nnnnn — случайное число.

    • Отображается обычная текстовая версия сообщения. Вложение TNEF пропускается или удаляется. В результате остается обычное текстовое сообщение.

    • Серверы обмена сообщениями, поддерживающие формат TNEF, можно настроить так, чтобы они удаляли вложения TNEF из входящих сообщений. В результате остается обычное текстовое сообщение. Некоторые почтовые клиенты, такие как Microsoft Outlook Express, не поддерживают формат TNEF, но могут распознавать и пропускать вложения TNEF. В результате остается обычное текстовое сообщение.

    Существуют программы сторонних разработчиков, помогающие выполнять преобразование вложений Winmail.dat.

    Все версии Exchange, начиная с Exchange Server версии 5.5, поддерживают формат TNEF.

  • Summary Transport Neutral Encapsulation Format (STNEF)   Форматы STNEF и TNEF эквивалентны. Однако сообщения STNEF и TNEF кодируются по-разному. Сообщения STNEF всегда представлены в кодировке MIME, а поле Content-Transfer-Encoding в них всегда имеет значение Binary. Таким образом, они не содержат обычной текстовой версии сообщения; отдельного вложения Winmail.dat в теле такого сообщения также нет. Все сообщение представляется с использованием только двоичных данных. Сообщения, в которых поле Content-Transfer-Encoding имеет значение Binary, могут передаваться только между SMTP-серверами обмена сообщениями, поддерживающими и объявляющими SMTP-расширения BINARYMIME и CHUNKING в соответствии со спецификацией RFC 3030. Эти сообщения всегда передаются между SMTP-серверами обмена сообщениями с помощью команды BDAT, а не стандартной команды DATA.

    Все версии Exchange, начиная с Exchange 2000, поддерживают формат STNEF. Формат STNEF автоматически используется для всех сообщений, передаваемых между серверами Exchange в организации, начиная с основного режима сервера Exchange Server 2003.

    Сервер Exchange никогда не отправляет сообщения STNEF внешним получателям. За пределы организации Exchange можно отправлять только сообщения в формате TNEF.

В начало

Параметры преобразования содержимого, которые можно задать в организации Exchange для внешних получателей, делятся на категории, описанные ниже.

  • Параметры преобразования TNEF   эти параметры преобразования определяют, необходимо ли удалять форматирование TNEF из сообщений, покидающих организацию Exchange.

  • Параметры кодирования сообщений   Эти параметры определяют характеристики кодирования сообщений, такие как наборы знаков MIME и наборы знаков, отличные от MIME, кодировка сообщения и форматы вложений.

Указанные параметры преобразования и кодирования не зависят друг от друга. Например, возможность отправки сообщений TNEF за пределы организации Exchange не относится к заданным для этих сообщений параметрам кодирования MIME или параметрам кодирования этих сообщений в обычный текст.

Настроить преобразование содержимого можно на разных уровнях организации Exchange. Они описаны ниже.

  • Параметры удаленных доменов   удаленные домены определяют параметры передачи исходящих сообщений между организацией Exchange и внешними доменами. Даже если для конкретных доменов не созданы записи удаленных доменов, ко всем удаленным адресным пространствам (*) применяются параметры предопределенного удаленного домена с именем Default.

  • Параметры пользователей почты и почтовых контактов   пользователи почты и почтовые контакты похожи: и те, и другие имеют внешние адреса электронной почты и содержат сведения о людях за пределами организации Exchange. Основное отличие состоит в том, что у пользователей почты есть учетные записи, используемые для входа в домен Active Directory и для доступа к ресурсам в организации.

  • Параметры Outlook   в приложении Outlook можно задать для сообщения параметры форматирования и кодирования, описанные ниже.

    • Формат сообщений   Этот параметр позволяет назначить формат по умолчанию для всех сообщений. Формат по умолчанию для всех сообщений можно переопределять при создании конкретного сообщения.

    • Формат сообщений Интернета   Этот параметр определяет, будут ли сообщения TNEF отправляться удаленным получателям как есть или сначала будет выполняться их преобразование в формат, обладающий лучшей совместимостью. Можно также задать различные параметры кодирования для сообщений, отправляемых удаленным получателям. Эти параметры не применяются к сообщениям, отправленным получателям в организации Exchange.

    • Формат сообщений Интернета для получателей   Этот параметр определяет, будут ли сообщения TNEF отправляться конкретным получателям как есть или сначала будет выполняться их преобразование в более формат, обладающий лучшей совместимостью. Можно задать параметры преобразования для конкретных контактов из папки «Контакты» и переопределять эти параметры для конкретных получателей в полях «Кому», «Копия» или «Скрытая копия» при создании сообщения. Для получателей в организации Exchange эти варианты преобразования недоступны.

    • Параметры кодирования сообщений Интернета для получателей   Эти параметры позволяют управлять кодированием содержимого в кодировку MIME или обычный текст для конкретных контактов из папки «Контакты» и переопределять параметры преобразования для конкретных получателей в полях «Кому», «Копия» или «Скрытая копия» при создании сообщения. Для получателей в организации Exchange эти варианты преобразования недоступны.

    • Международные параметры   Эти параметры позволяют контролировать использование наборов знаков в сообщениях.

Параметры преобразования TNEF можно задать на следующих уровнях:

  • параметры удаленных доменов;

  • параметры почтовых пользователей и контактов;

  • параметры Outlook, включая:

    • формат сообщений;

    • формат сообщений Интернета;

    • формат сообщений Интернета для получателей;

Параметры кодирования сообщений можно задать на следующих уровнях:

  • параметры удаленных доменов;

  • параметры почтовых пользователей и контактов;

  • параметры Outlook, включая:

    • формат сообщений;

    • формат сообщений Интернета;

    • формат сообщений для получателей в Интернете;

    • параметры кодирования наборов знаков сообщений

Подробные сведения см. в разделе Параметры кодирования сообщений.

В начало

Чтобы лучше понимать параметры преобразования содержимого для внешних получателей, необходимо понимать структуру сообщений электронной почты. Для написания и отправки сообщений электронной почты в основании сообщения SMTP обычное текстовое сообщение в 7-разрядной кодировке US-ASCII. Стандартное SMTP-сообщение состоит из описанных ниже элементов.

  • Конверт сообщения.   Конверт сообщения определен в документе RFC 2821. Он содержит сведения, необходимые для передачи и доставки сообщения. Получатели не видят конверт сообщения, так как он создается в процессе передачи сообщения и фактически не является частью самого сообщения.

  • Содержимое сообщения.   Содержимое сообщения определено в документе RFC 2822. Оно состоит из элементов, описанных ниже.

    • Заголовок сообщения.   Заголовок сообщения представляет собой набор полей заголовка. Поля заголовка состоят из имени поля, двоеточия (:), тела поля и сочетания знаков возврата каретки и перевода строки (CR/LF).

      Имя поля может включать все печатные текстовые знаки US-ASCII за исключением двоеточия (:). В частности, знаки ASCII с 33 по 57 и с 59 по 126 включительно.

      Тело поля может включать любые знаки US-ASCII за исключением знаков возврата каретки (CR) и перевода строки (LF). Однако, сочетание символов возврата каретки и перевода строки может присутствовать в тексте поля, если оно используется для развертывания заголовка. Развертывание заголовка — это разделение тела поля заголовка на несколько строк в соответствии с разделом 2.2.3 спецификации RFC 2822. Другие требования к синтаксису тела поля описаны в разделах 3 и 4 спецификации RFC 2822.

    • Тело сообщения.   Тело сообщения представляет собой набор строк текстовых знаков US-ASCII и следует за заголовком сообщения. Заголовок и тело сообщения разделяются пустой строкой, которая завершается сочетанием знаков возврата каретки и перевода строки. Тело сообщения может отсутствовать. Ни одна строка текста в теле сообщения не может содержать более 997 знаков. Знаки возврата каретки и перевода строки отмечают конец строки и могут использоваться только вместе.

Если сообщение SMTP содержит элементы, отличные от обычного текста US-ASCII, для сохранения этих элементов необходимо выполнить кодирование сообщения. Способ кодирования нетекстового содержимого сообщений определен в стандарте MIME. Стандарт MIME позволяет использовать текст, представленный знаками из других наборов знаков, нетекстовые вложения, составные тела сообщений и поля заголовка, представленные знаками из других наборов знаков. Стандарт MIME описан в документах RFC 2045, RFC 2046, RFC 2047, RFC 2048 и RFC 2077. В стандарте MIME определена совокупность полей заголовка, которые задают дополнительные атрибуты сообщения. Некоторые важные поля заголовка MIME описаны в приведенной ниже таблице.

Важные поля заголовка MIME

Название поля заголовка Значение по умолчанию Описание

MIME-Version

1.0

Это поле заголовка является первым в сообщении, преобразованном в формат MIME. Оно следует за другими стандартными полями заголовка RFC 2822, но предшествует всем остальным полям заголовка MIME. Почтовые клиенты с поддержкой MIME используют это поле заголовка для идентификации сообщений в кодировке MIME. Если это поле заголовка отсутствует, почтовые клиенты с поддержкой MIME идентифицируют формат сообщения как обычный текст.

Content-Type

text/plain

Это поле заголовка определяет тип мультимедиа содержимого сообщения в соответствии со спецификацией RFC 2046. Тип мультимедиа включает тип, подтип и один или несколько необязательных параметров, таких как параметр charset=, который определяет кодировку MIME. Типы, которые начинаются с «x-», являются нестандартными. Подтипы, которые начинаются на «vnd.», являются специфичными подтипами конкретных компаний. Служба Internet Assigned Numbers Authority (IANA) ведет список зарегистрированных типов мультимедиа. Дополнительные сведения см. в статье Типы мультимедиа MIME .

Тип мультимедиа multipart (составной) позволяет использовать в одном сообщении несколько разделов, имеющих разные типы мультимедиа. Например, в некоторых полях Content-Type содержатся значения «text/plain», «text/html», «multipart/mixed» и «multipart/alternative».

Content-Transfer-Encoding

7bit

Это поле заголовка может определять следующие характеристики сообщения:

  • алгоритм кодирования, используемый для преобразования текста, отличного от US-ASCII, или двоичных данных в теле сообщения;

  • индикатор, описывающий текущее состояние тела сообщения.

В сообщении MIME могут встречаться различные значения поля заголовка Content-Transfer-Encoding. Если поле заголовка Content-Transfer-Encoding содержится в заголовке сообщения, его действие распространяется на все тело сообщения. Если поле заголовка Content-Transfer-Encoding содержится в одной из частей составного сообщения, его действие распространяется только на эту часть сообщения.

Когда алгоритм кодирования применяется к телу сообщения, оно преобразуется в обычный текст в кодировке US-ASCII. Это обеспечивает возможность передачи сообщения через более старые серверы обмена сообщениями SMTP, которые поддерживают только текстовые сообщения в кодировке US-ASCII. Значения поля заголовка Content-Transfer-Encoding, указывающие алгоритм кодирования, который использовался для преобразования тела сообщения:

  • Quoted-printable   Этот алгоритм кодирует тело сообщения, используя печатные знаки US-ASCII. Если текст исходного сообщения содержит преимущественно знаки US-ASCII, кодирование по алгоритму Quoted-printable позволяет получить компактный текст, относительно пригодный для чтения. Все печатные текстовые знаки US-ASCII за исключением знака равенства (=) могут быть представлены без кодирования.

  • Base64.   Этот алгоритм кодирования во многом основан на стандарте PEM, определенном в документе RFC 1421. Для кодирования тела сообщения в этом случае используется 64-знаковый алфавит и знаки заполнения вывода, определенные в стандарте PEM. Сообщение, закодированное по алгоритму Base64, обычно примерно на треть больше исходного. Этот алгоритм позволяет предугадать итоговый размер сообщения и лучше всего подходит для кодирования двоичных данных и текста в кодировке, отличной от US-ASCII.

Как правило, сообщение кодируется с использованием только одного алгоритма.

Если тело сообщения не кодировалось ни по какому алгоритму, поле заголовка Content-Transfer-Encoding просто определяет текущее состояние данных в теле сообщения. Следующие значения поля заголовка Content-Transfer-Encoding указывают, что тело сообщения не кодировалось ни по какому алгоритму:

  • 7bit.   Это значение указывает, что данные в теле сообщения уже представлены в формате RFC 2822. Это означает, что должны быть выполнены указанные ниже условия.

    • каждая строка текста содержит не более 998 знаков;

    • все знаки являются текстовыми знаками из кодировки US-ASCII с номерами от 1 до 127 включительно;

    • знаки возврата каретки и перевода строки используются только вместе для обозначения конца строки текста.

    В кодировке 7bit может быть представлено все тело сообщения или часть тела составного сообщения. Если составное сообщение содержит части, включающие двоичные данные или текстовые знаки, отличные от US-ASCII, эти части должны быть закодированы с помощью алгоритма Quoted-printable или Base64.

    Сообщения с телами в кодировке 7bit можно передавать между SMTP-серверами обмена сообщениями с помощью стандартной команды DATA.

  • 8bit   Это значение указывает, что данные в теле сообщения содержат знаки, которых нет в кодировке US-ASCII. Это означает, что выполнены следующие условия:

    • каждая строка текста содержит не более 998 символов;

    • в теле сообщения есть хотя бы один знак, имеющий в кодировке номер больше 127;

    • символы возврата каретки и перевода строки могут использоваться вместе только для обозначения конца строки текста.

    В кодировке 8bit может быть представлено все тело сообщения или часть тела составного сообщения. Если составное сообщение содержит части, включающие двоичные данные, эти части должны быть закодированы с помощью алгоритма Quoted-printable или Base64.

    Сообщения с текстом в 8-битной кодировке могут передаваться только между SMTP-серверами обмена сообщениями, поддерживающими SMTP-расширение 8BITMIME в соответствии со спецификацией RFC 1652, например серверами под управлением Exchange 2000 Server или более поздних версий. Это означает, что должны быть выполнены указанные ниже условия.

    • в ответе EHLO сервера должно быть объявлено ключевое слово 8BITMIME;

    • сообщения по-прежнему передаются с использованием стандартной SMTP-команды DATA, однако в конце команды MAIL FROM должен быть указан параметр BODY=8BITMIME.

  • Binary   Это значение указывает, что тело сообщения содержит текстовые знаки, которых нет в кодировке US-ASCII, или двоичные данные. Это означает, что выполняются следующие условия:

    • разрешены любые последовательности знаков;

    • длина строк не ограничена;

    • двоичные элементы сообщения не нуждаются в кодировании.

    Сообщения с текстом в двоичной кодировке могут передаваться только между SMTP-серверами обмена сообщениями, поддерживающими SMTP-расширение BINARYMIME в соответствии со спецификацией RFC 3030, например серверами под управлением Exchange 2000 Server или более поздних версий. Это означает, что должны быть выполнены указанные ниже условия.

    • В ответе EHLO сервера должно быть объявлено ключевое слово BINARYMIME.

    • SMTP-расширение BINARYMIME может использоваться только с SMTP-расширением CHUNKING. Функция разделения позволяет отправлять крупные тела сообщений в виде нескольких меньших блоков. Она также определена в спецификации RFC 3030. В ответе EHLO сервера должно быть объявлено ключевое слово CHUNKING.

    • Сообщения должны передаваться с помощью команды BDAT, а не стандартной команды DATA.

    • Если сообщение имеет тело, в конце команды MAIL FROM должен быть указан параметр BODY=BINARYMIME.

Значения 7bit, 8bit и Binary не могут использоваться вместе в одном составном сообщении. Они являются взаимоисключающими. Значения Quoted-printable и Base64 могут встречаться в теле составного сообщения, представленном в кодировке 7bit или 8bit, но не в теле сообщения Binary. Если тело составного сообщения содержит разные части, включающие содержимое 7bit и 8bit, все сообщение классифицируется как сообщение в кодировке 8bit. Если тело составного сообщения содержит разные части, включающие содержимое 7bit и 8bit и Binary, все сообщение классифицируется как сообщение в кодировке Binary.

Content-Disposition

Attachment

Это поле заголовка, описанное в спецификации RFC 2183, указывает почтовому клиенту с поддержкой MIME, как ему следует отобразить вложенный файл. Данное поле может иметь значения Inline и Attachment. Если данное поле имеет значение Inline, вложение отображается в теле сообщения. Если данное поле имеет значение Attachment, вложенный файл отображается как обычное вложение, т. е. отдельно от тела сообщения. Если используется значение Attachment, доступны другие параметры, такие как Filename, Creation-date и Size.

В начало

 
Показ: