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

  • Статья

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

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

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

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

В списке ниже описаны основные форматы сообщений, доступные в Exchange и Outlook.

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

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

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

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

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

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

    • исходную форматированную версию сообщения (например, шрифты, размеры и цвета текста);
    • объекты OLE (например, внедренные изображения или документы Office);
    • специальные элементы Outlook (например, настраиваемые формы, кнопки голосования или приглашения на собрания);
    • обычные вложения, которые имелись в исходном сообщении

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

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

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

    • Отображается версия сообщения в виде обычного текста, а сообщение содержит вложение с именем Winmail.dat, Win.dat или другое универсальное имя, например Att nnnnn.dat или Att nnnnn.eml, где заполнитель nnnnnnn представляет случайное число.
    • Отображается обычная текстовая версия сообщения. Вложение TNEF пропускается или удаляется. В результате остается обычное текстовое сообщение.
    • Серверы обмена сообщениями, поддерживающие формат TNEF, можно настроить так, чтобы они удаляли вложения TNEF из входящих сообщений. В результате остается обычное текстовое сообщение. Более того, некоторые почтовые клиенты не поддерживают формат TNEF, но могут распознавать и пропускать вложения TNEF. В результате отображается обычное текстовое сообщение.

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

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

  • Сводный формат нейтрализации транспорта (STNEF): STNEF эквивалентен TNEF. Формат STNEF эквивалентен формату TNEF, но кодирование сообщений в формате STNEF отличается от кодирования сообщений в формате TNEF. В частности, сообщения STNEF всегда в кодировке MIME и всегда имеют значение BinaryContent-Transfer-Encoding . Таким образом, у этих сообщений нет представления в виде обычного текста, а в тексте сообщения нет отдельного вложения Winmail.dat. Все сообщение представлено с использованием только двоичных данных. Сообщения, у которых параметр Content-Transfer-Encoding имеет значение Binary, можно передавать только между серверами обмена сообщениями, поддерживающими и объявляющими расширения SMTP BINARYMIME и CHUNKING, как указано в спецификации RFC 3030. Сообщения всегда передаются между серверами обмена сообщениями с использованием команды 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 (Используемый по умолчанию), который применяется ко всем удаленным адресным пространствам (*). Дополнительные сведения об удаленных доменах см. в статье Remote Domains.

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

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

    • Формат сообщения. Вы можете задать формат сообщений по умолчанию для всех сообщений. Формат по умолчанию для всех сообщений можно переопределять при создании конкретного сообщения.
    • Формат сообщений в Интернете. Вы можете указать, отправляются ли сообщения TNEF удаленным получателям или они сначала преобразуются в более совместимый формат. Можно также задать различные параметры кодирования для сообщений, отправляемых удаленным получателям. Эти параметры не применяются к сообщениям, отправляемых получателям в организации Exchange.
    • Формат сообщения получателя из Интернета (Outlook 2010 или более ранних версий): вы можете управлять отправкой сообщений TNEF определенным контактам в папке "Контакты". Эти параметры преобразования недоступны для получателей в организации Exchange.
    • Параметры кодирования сообщений получателя в Интернете (Outlook 2010 или более ранние версии). Вы можете управлять параметрами кодирования MIME или обычного текста для определенных контактов в папке "Контакты". Эти параметры преобразования недоступны для получателей в организации Exchange.
    • Международные параметры. Вы можете управлять наборами символов, используемыми в сообщениях.

    Дополнительные сведения об этих параметрах см. в разделах Параметры преобразования TNEF и Параметры кодирования сообщений в Exchange Server.

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

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

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

  • Содержимое сообщения. Содержимое сообщения определяется в RFC 5322. Содержимое сообщения состоит из следующих элементов:

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

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

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

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

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

поле заголовка MIME-Version

Значение по умолчанию: 1.0

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

Поле заголовка Content-Type

Значение по умолчанию: text/plain

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

  • Тип :

    • Типы, начинающиеся с x- , не являются стандартными. Служба Internet Assigned Numbers Authority (IANA) ведет список зарегистрированных типов мультимедиа. Дополнительные сведения см. в разделе Типы носителей MIME.

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

  • Подтип: подтипы, которые начинаются с vnd. , зависят от поставщика.

  • Один или несколько необязательных параметров. Например, параметр, определяющий charset= кодировку символов MIME.

Поле заголовка Content-Transfer-Encoding

Значение по умолчанию: 7bit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Сообщения с двоичным телом можно передавать только между серверами обмена сообщениями, поддерживающими 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 никогда не существуют вместе в одном многокомпонентном сообщении (значения являются взаимоисключающими). Quoted-printable Значения или Base64 могут отображаться в 7-разрядном или 8-разрядном тексте многокомпонентного сообщения, но никогда не в тексте двоичного сообщения. Если многокомпонентный текст сообщения содержит различные части, состоящие из 7-разрядного и 8-разрядного содержимого, все сообщение классифицируется как 8-разрядное. Если многокомпонентное тело сообщения содержит различные части, состоящие из 7-битового, 8-битового и двоичного содержимого, все сообщение классифицируется как двоичное.

Поле заголовка Content-Disposition

Значение по умолчанию: Attachment

Это поле заголовка указывает почтовому клиенту с поддержкой MIME, как он должен отображать вложенный файл, и описано в RFC 2183. Допустимые значения:

  • Inline: вложение отображается в тексте сообщения.

  • Attachment: вложенный файл отображается как обычное вложение отдельно от текста сообщения. Другие параметры также имеют эти значения (например, Filename, Creation-dateи Size).