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

  • Статья

Область применения: Exchange Server 2013 г.

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

  • Преобразование сообщений для внешних получателей. Этот тип преобразования содержимого включает параметры преобразования 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, при этом параметр Content-Type имеет значение text/plain, а параметр Content-Transfer-Encoding — значение 7bit для текстовых частей составного сообщения. Для любых текстовых вложений используется кодирование Quoted Printable или Base64. По умолчанию при создании и отправке обычного текстового сообщения в Outlook сообщение закодировано MIME со значением Content-Type ( текст или обычный).

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

  • Формат форматированного текста (RTF): RTF поддерживает форматирование текста и другие графические элементы. RTF является синонимом TNEF. TNEF и RTF можно использовать взаимозаменяемо. Формат сообщений в формате форматов текста полностью отличается от формата документа с форматом форматов форматов, доступных в Microsoft Word.

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

  • TNEF. Формат нейтральной инкапсуляции транспорта — это формат, предназначенный для инкапсулирования свойств сообщения MAPI от Майкрософт. Сообщение в формате TNEF содержит сообщение в виде обычного текста и вложение, в которое упакована исходная отформатированная версия сообщения. Обычно такое вложение имеет название Winmail.dat. Вложение 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 или другое универсальное имя, например Att_nnnnn_.dat или Att_nnnnn_.eml, где заполнитель nnnnn представляет случайное число.

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

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

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

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

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

    Формат STNEF поддерживается во всех версиях Exchange, начиная с Exchange 2000. Формат 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

Параметры преобразования 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 7разрядных Это поле заголовка может определять следующие характеристики сообщения:
  • алгоритм кодирования, используемый для преобразования текста, отличного от US-ASCII, или двоичных данных в теле сообщения;
  • индикатор, описывающий текущее состояние тела сообщения.

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

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

  • Возможность печати в кавычках. Этот алгоритм кодирования использует печатные символы 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 включительно;
    • знаки возврата каретки и перевода строки используются только вместе для обозначения конца строки текста.

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

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

  • 8bit: это значение указывает, что данные текста сообщения содержат символы, отличные от US-ASCII. Это означает, что должны быть выполнены следующие условия:
    • каждая строка текста содержит не более 998 символов;
    • в теле сообщения есть хотя бы один знак, имеющий в кодировке номер больше 127;
    • символы возврата каретки и перевода строки могут использоваться вместе только для обозначения конца строки текста.

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

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

    • в отклике EHLO сервера должно быть объявлено ключевое слово 8BITMIME;
    • Сообщения по-прежнему передаются с помощью стандартной команды SMTP DATA. Однако параметр BODY=8BITMIME необходимо добавить в конец команды MAIL FROM.
  • Binary: это значение указывает, что текст сообщения содержит текстовые или двоичные данные, отличные от US-ASCII. Это означает, что выполняются следующие условия:
    • разрешены любые последовательности знаков;
    • длина строк не ограничена;
    • двоичные элементы сообщения не нуждаются в кодировании.

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

    • в отклике EHLO сервера должно быть объявлено ключевое слово BINARYMIME;
    • SMTP-расширение BINARYMIME можно использовать только с SMTP-расширением CHUNKING. Функция фрагментирования позволяет отправлять сообщения с большими телами в виде нескольких меньших блоков. Понятие функции фрагментирования определено в спецификации RFC 3030. В отклике EHLO сервера должно быть объявлено ключевое слово CHUNKING.
    • Для передачи сообщений используется команда BDAT вместо стандартной команды DATA.
    • Если у сообщения есть текст сообщения, необходимо добавить параметр BODY=BINARYMIME в конец команды MAIL FROM.

Значения 7bit, 8bit и Binary никогда не существуют вместе в одном многокомпонентном сообщении. Значения являются взаимоисключающими. Значения, печатаемые в кавычках или Base64, могут отображаться в 7- или 8-разрядном тексте многокомпонентного сообщения, но никогда не в тексте двоичного сообщения. Если многокомпонентный текст сообщения содержит различные части, состоящие из 7-разрядного и 8-разрядного содержимого, все сообщение классифицируется как 8разрядное. Если многокомпонентный текст сообщения содержит различные части, состоящие из содержимого 7, 8bit и Binary, все сообщение классифицируется как двоичное.
Content-Disposition Вложение Это поле заголовка указывает почтовому клиенту с поддержкой MIME, как он должен отображать вложенный файл, и описано в RFC 2183. Значения этого поля могут иметь значение Inline или Attachment. Если это поле имеет значение Inline, вложение отображается в тексте сообщения. Если для этого поля задано значение Вложение, вложенный файл отображается как обычное вложение отдельно от текста сообщения. Другие параметры доступны при значении Вложение, например Имя файла, Дата создания и Размер.