Общие сведения о преобразовании содержимого

  • Статья

 

Применимо к: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Последнее изменение раздела: 2016-11-28

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

В организации Exchange Server 2010 преобразование содержимого выполняет классификатор на сервере с установленной ролью транспортного сервера-концентратора. Классификация каждого полученного сообщения производится после его помещения в очередь передачи. Кроме разрешения получателей и маршрутизации преобразование содержимого сообщения выполняется перед помещением сообщения в очередь доставки. Если одно сообщение адресовано нескольким получателям, при преобразовании содержимого определяется приемлемая кодировка для каждого получателя. На пограничном транспортном сервере выполняется сокращенная классификация, в ходе которой преобразование содержимого не выполняется.

Содержание

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

Форматы сообщений сервера Exchange 2010 и 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 2010, Exchange Server 2007, Exchange Server 2003 или Exchange 2000 Server. Это означает, что должны быть выполнены указанные ниже условия.

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

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

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

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

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

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

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

    • В ответе 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.

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

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

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

    • Заголовки и тело сообщения состоят из текстовых знаков US-ASCII. Вложения кодируются с использованием алгоритма Uuencode («Unix-to-Unix encoding»). Данный алгоритм позволяет хранить двоичные вложения в теле сообщения электронной почты с использованием текстовых знаков 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 поддерживаются только приложением Outlook и некоторыми другими почтовыми клиентами MAPI. MAPI — это разработанная в Microsoft архитектура обмена сообщениями, позволяющая приложениям взаимодействовать с различными системами обмена сообщениями на различных аппаратных платформах. Интерфейс MAPI основан на архитектуре COM. В Outlook MAPI используется для взаимодействия с почтовыми ящиками на компьютере под управлением Exchange 2010 с установленной ролью сервера почтовых ящиков.

    Формат RTF для сообщений не имеет ничего общего с форматом RTF для документов, существующим в Microsoft Word.

  • TNEF   TNEF — это специфический формат 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.

    Формат TNEF поддерживается серверами Exchange 2010, Exchange 2007, Exchange 2003, Exchange 2000 и Exchange Server версии 5.5. Сообщения TNEF передаются между SMTP-серверами обмена сообщениями с помощью стандартной команды DATA. Формат TNEF автоматически используется сервером Exchange в указанных ниже ситуациях.

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

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

  • 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.

    Формат STNEF поддерживается сервером Exchange 2010, Exchange 2007, Exchange 2003 и Exchange 2000. Он автоматически используется сервером Exchange в описанных ниже ситуациях.

    • Exchange 2010   Формат STNEF используется для представления всех сообщений, передаваемых между серверами Exchange в организации.

    • Exchange 2007   Формат STNEF используется для представления всех сообщений, передаваемых между серверами Exchange в организации.

    • Exchange 2003   Если организация Exchange работает в основном режиме, формат STNEF используется для представления всех сообщений, передаваемых между серверами Exchange в организации.

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

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

Элементы преобразования содержимого

Преобразование содержимого — это процесс надлежащего форматирования сообщения для каждого внешнего получателя. Преобразование содержимого выполняется классификатором на транспортном сервере-концентраторе.

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметры преобразования TNEF

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

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

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

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

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

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

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

Подробные сведения см. в разделе Параметры преобразования TNEF.

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

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

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

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

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

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

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

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

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

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

Преобразование содержимого, выполняемое драйвером хранилища

Драйвер хранилища также выполняет преобразование содержимого. Драйвер хранилища используется на транспортных серверах-концентраторах для транспорта сообщений между почтовыми ящиками на серверах почтовых ящиков и очередью передачи. Точнее говоря, он транспортирует сообщения из папки «Исходящие» отправителя в очередь передачи на транспортном сервере-концентраторе и из очереди передачи на транспортном сервере-концентраторе в папку «Входящие» получателя. Драйвер хранилища преобразует все входящие сообщения в формат MAPI и все исходящие сообщения из формата MAPI в необходимый формат. Ошибки драйвера хранилища при преобразовании содержимого регистрируются при трассировке преобразования содержимого.

Дополнительные сведения см. в разделе Трассировка преобразования контента.

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.