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

  • Статья

 

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

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

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

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

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

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

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

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

    • Заголовок сообщения   Заголовок сообщения представляет собой набор полей заголовка, которые включают (в указанном порядке) имя поля, двоеточие ( : ), тело поля и сочетание знаков возврата каретки и перевода строки (CRLF).

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

      Тело поля может включать любые знаки US-ASCII за исключением знаков возврата каретки (CR) и перевода строки (LF). Сочетание CRLF может присутствовать в теле поля, только если оно используется для развертывания заголовка. Развертывание заголовка — это разделение тела поля заголовка на несколько строк в соответствии с разделом 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-Version:

1.0

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

Content-Type:

text/plain

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

noteПримечание.
UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

Тип мультимедиа 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 (Privacy-Enhanced Mail), определенном в документе RFC 1421. Для кодирования тела сообщения в этом случае используется 64-знаковый алфавит и знаки заполнения вывода, определенные в стандарте PEM. Сообщение, закодированное по алгоритму Base64, обычно примерно на треть больше исходного. Этот алгоритм позволяет предугадать итоговый размер сообщения и лучше всего подходит для кодирования двоичных данных и текста в кодировке, отличной от US-ASCII.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Сообщения с текстом в кодировке Binary могут передаваться только между SMTP-серверами обмена сообщениями, поддерживающими SMTP-расширение BINARYMIME в соответствии со спецификацией RFC 3030, например серверами Exchange 2000 или более поздними версиями Exchange 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.

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

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

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

    • Заголовки и тело сообщения состоят из текстовых знаков 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 он используется для взаимодействия с почтовыми ящиками на компьютере с сервером Exchange 2007 с установленной ролью сервера почтовых ящиков.

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

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

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

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

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

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

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

    • сообщение, соответствующее спецификации RFC 2822 и включающее только текст в кодировке US-ASCII;

    • составное сообщение в кодировке 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 Server 5.0 и более поздними версиями Exchange Server. Сообщения TNEF передаются между SMTP-серверами обмена сообщениями с помощью стандартной команды DATA. Формат TNEF автоматически используется сервером Exchange в указанных ниже ситуациях.

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

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

  • Summary Transport Neutral Encoding 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 2000 и более поздними версиями Exchange Server. Он автоматически используется сервером Exchange, если выполняются указанные ниже условия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • параметры Outlook

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

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

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

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

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

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

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

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

  • параметры Outlook

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

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

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

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

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

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

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

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