Применимо к: Exchange Server 2010 SP1

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

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

Другие задачи, связанные с управлением каталогами раскладки и преобразования, см. в разделе Управление соединителями.

Содержание

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

Обработка сообщений в каталоге раскладки

Обработка сообщений в каталоге преобразования

Вопросы безопасности, связанные с каталогами раскладки и преобразования

Разрешения для каталогов раскладки и преобразования

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

Стандартное SMTP-сообщение электронной почты состоит из конверта сообщения и содержимого сообщения. Конверт сообщения содержит сведения, которые требуются для передачи и доставки сообщения. Содержимое сообщения разделяется на поля заголовка сообщения, которые в совокупности называются заголовком сообщения, и текста сообщения. Конверт сообщения описан в документе RFC 2821, а заголовок сообщения — в документе RFC 2822.

При написании сообщения электронной почты и его отправке сообщение содержит основные сведения, требуемые для соответствия стандартам SMTP, например: отправитель, получатель, время и дата написания сообщения, необязательная строка темы и необязательный текст сообщения. Данные содержатся в самом сообщении, а также, по определению, в заголовке сообщения.

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

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

В начало

Обработка сообщений в каталоге раскладки

Правильно отформатированный EML-файл сообщения, скопированный в каталог раскладки, обрабатывается для передачи следующим образом:

  1. Каталог раскладки проверяется на появление новых файлов сообщений каждые пять секунд. Этот интервал опроса изменить нельзя. Скорость обработки файлов сообщений можно изменить с помощью параметра PickupDirectoryMaxMessagesPerMinute командлета Set-TransportServer . Значением по умолчанию является 100 сообщений в минуту. Файлы, которые не удается открыть, остаются в каталоге раскладки и повторно обрабатываются при следующем опросе.

  2. Проверяются ограничения, установленные для файлов сообщений в каталоге раскладки, такие как максимальный размер заголовка и максимальное количество получателей. По умолчанию максимальный размер заголовка равен 64 килобайтам (КБ), а максимальное количество получателей — 100. Эти ограничения можно изменить с помощью командлета Set-TransportServer.

  3. Файл переименовывается из <имя_файла>.eml в <имя_файла>.tmp. Если файл <имя_файла>.tmp уже существует, новому файлу будет присвоено имя <имя_файла><дата_и_время>.tmp. Если не удалось переименовать файл, создается ошибка журнала событий и в процессе раскладки начинается обработка следующего файла.

  4. После успешного преобразования файла с расширением TMP в сообщение электронной почты к файлу с расширением TMP применяется команда удалить при закрытии. Этот TMP-файл остается в каталоге раскладки, однако не может быть открыт.

  5. После того, как сообщение помещено в очередь доставки, выполняется команда close и TMP-файл удаляется из каталога раскладки. Если не удается удалить файл, создается журнал ошибок. Если служба транспорта Microsoft Exchange перезапущена при наличии файлов с расширением TMP в каталоге раскладки; расширение всех этих файлов меняется на EML, и они обрабатываются повторно. Это может привести к передаче дублированных сообщений.

Требования к файлам сообщений в каталоге раскладки

Чтобы доставка файла сообщения, скопированного в каталог раскладки, была успешно выполнена, этот файл должен отвечать следующим требованиям:

  • Файл сообщения должен быть текстовым файлом, соответствующим стандартному формату SMTP-сообщения. Поддерживаются поля и содержимое заголовка сообщения MIME.

  • Файл сообщения должен иметь расширение EML.

  • В заголовке сообщения в полях Sender или From должен быть указан по меньшей мере один адрес электронной почты. Если в полях Sender и From указан один адрес электронной почты, то в качестве источника сообщения в конверте сообщения будет использоваться поле From.

  • В поле Sender может существовать только один адрес электронной почты. Наличие нескольких адресов не допускается. Поле Sender является необязательным, если в поле From указан единственный адрес электронной почты.

  • В поле From может быть указано несколько адресов, однако при этом в поле Sender должен быть указан один адрес электронной почты. Адрес в поле Sender затем используется в качестве источника сообщения в конверте сообщения.

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

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

В следующем примере показано простое текстовое сообщение, в котором используется допустимый формат для каталога раскладки.

Скопировать код
To: mary@contoso.com
From: bob@fabrikam.com
Subject: Message subject

This is the body of the message.

В файлах сообщений каталога раскладки также поддерживается содержимое MIME. В расширениях MIME определен широкий спектр содержимого сообщений, включающий языки, которые могут быть представлены как 7-битовый текст ASCII, HTML или другое мультимедийное содержимое. Полное описание расширений MIME и требований к ним выходит за рамки этого раздела. В следующем примере показано простое сообщение MIME, в котором используется допустимый формат для каталога раскладки.

Скопировать код
To: mary@contoso.com
From: bob@fabrikam.com
Subject: Message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>
</BODY></HTML>

Изменения заголовка сообщения в файлах сообщений из каталога раскладки

В каталоге раскладки из заголовка сообщения удаляются все следующие поля заголовка сообщения:

  • Received

  • Resent-*

  • Bcc

    Примечание.
    Все адреса электронной почты, указанные в дополнительных полях заголовка сообщения BCC, обрабатываются должным образом. После того, как получатели, указанные в поле BCC, преобразуются в невидимых получателей конверта сообщения, они удаляются из заголовка сообщения в целях сохранения их конфиденциальности. Если сообщение содержит только получателей в поле BCC, в поле заголовка сообщения To добавляется значение Undisclosed Recipients (скрытые получатели).

В каталоге раскладки в отправляемое сообщение добавляется новое поле заголовка Received. Поле заголовка Received имеет следующий формат.

Скопировать код
Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

В каталоге раскладки изменяются следующие поля заголовка сообщения, если они отсутствуют или имеют неправильный формат:

  • Message-Id. Если данное поле заголовка сообщения отсутствует или не содержит значения, каталог раскладки добавляет поле Message-Id в формате <GUID>@<домен_по_умолчанию>.

  • Date. Если поле Date отсутствует или имеет неправильный формат, в сообщение добавляется дата и время обработки сообщения в каталоге раскладки.

Сбои при обработке сообщений в каталоге раскладки

Постановка в очередь доставки файла сообщения, скопированного в каталог раскладки, может завершиться неудачно. Могут возникнуть следующие категории сбоев при передаче сообщения:

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

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

    Файл сообщения, которое определено как недопустимое, остается в каталоге раскладки, его имя меняется с <имя_файла>.eml на <имя_файла>.bad. Если файл <имя_файла> в формате BAD уже существует, он переименовывается в <имя_файла><дата_и_время> в формате BAD. Если в каталоге раскладки присутствуют недопустимые сообщения, создается ошибка журнала событий, однако это происходит только один раз в отношении одного сообщения.

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

В начало

Обработка сообщений в каталоге преобразования

Правильно отформатированный EML-файл сообщения, скопированный в каталог раскладки, обрабатывается для передачи следующим образом:

  1. Каталог преобразования проверяется на появление новых файлов сообщений каждые пять секунд. Этот интервал опроса изменить нельзя. Скорость обработки файлов сообщений можно изменить с помощью параметра PickupDirectoryMaxMessagesPerMinute командлета Set-TransportServer . Значением по умолчанию является 100 сообщений в минуту. Файлы, которые не удается открыть, остаются в каталоге преобразования и повторно обрабатываются при следующем опросе.

  2. Файл переименовывается из <имя_файла>.eml в <имя_файла>.tmp. Если файл <имя_файла>.tmp уже существует, он переименовывается в <имя_файла><дата_время>.tmp. Если не удается переименовать файл, создается запись в журнале ошибок, и процесс преобразования переходит к следующему файлу.

  3. После успешного преобразования файла с расширением TMP в сообщение электронной почты к файлу с расширением TMP применяется команда удалить при закрытии. Этот TMP-файл остается в каталоге преобразования, однако не может быть открыт.

  4. После того, как сообщение помещено в очередь доставки, выполняется команда close и TMP-файл удаляется из каталога преобразования. Если не удается удалить файл, создается журнал ошибок. Если служба транспорта Microsoft Exchange запускается повторно, а в каталоге преобразования содержатся TMP-файлы, все TMP-файлы переименовываются в EML-файлы и повторно обрабатываются. Это может привести к передаче дублированных сообщений.

Требования к файлам сообщений в каталоге преобразования

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

В сообщениях каталога преобразования очень часто используются поля X-заголовков. X-заголовки представляют собой пользовательские неофициальные поля заголовка, которые включаются в заголовок сообщения. X-заголовки не рассматриваются в RFC 2822, однако использование неопределенного поля заголовка сообщения, которое начинается с символа «X-» стало общепринятым способом добавления в сообщение неофициальных полей заголовка сообщения. X-заголовки в Exchange 2010, которые используются в файлах сообщений в каталоге преобразования, могут содержать сведения о доставке, обычно указываемые в заголовке сообщения. Эта возможность требуется для сохранения исходных сведений сообщения при использовании каталога преобразования для обработки экспортированных сообщений с другого сервера Exchange.

Чтобы доставка файла сообщения, скопированного в каталог преобразования, была успешно выполнена, этот файл должен отвечать следующим требованиям:

  • Файл сообщения должен быть текстовым файлом, соответствующим стандартному формату SMTP-сообщения. Поддерживаются поля и содержимое заголовка сообщения MIME.

  • Файл сообщения должен иметь расширение EML.

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

  • Поля заголовка и текст сообщения должна разделять пустая строка.

X-заголовки, описанные в следующем списке, требуются сообщениями в каталоге преобразования.

  • X-Sender. Данный X-заголовок заменяет обязательное поле заголовка сообщения From в типичном SMTP-сообщении. Должно существовать одно поле X-Sender, содержащее один адрес электронной почты. Каталог преобразования игнорирует поле заголовка From, если оно существует, несмотря на то, что почтовый клиент получателя отображает значение поля заголовка сообщения From в качестве отправителя сообщения. В поле X-Sender обычно присутствуют и другие параметры, как показано в следующем примере:

    Скопировать код
    X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
    
    Примечание.
    Эти параметры являются значениями конверта сообщения, которые обычно создаются отправляющим сервером. Похожие параметры можно увидеть в экспортированных файлах сообщений.

    Параметр RET служит для указания, следует ли возвращать отправителю целое сообщение или только заголовки, если сообщение не может быть доставлено. Параметр RET может иметь значение HDRS или FULL. ENVID — это идентификатор конверта сообщения. BODY служит для указания кодировки текста сообщения. auth служит для указания серверу обмена сообщениями механизма проверки подлинности, как описано в документе RFC 2554.
  • X-Receiver. Данный X-заголовок заменяет обязательное поле заголовка сообщения To в типичном SMTP-сообщении. Должно существовать хотя бы одно поле X-Receiver, содержащее один адрес электронной почты. Допускается использование нескольких заголовков X-Receiver для нескольких получателей. Каталог преобразования игнорирует поля заголовка To, если они есть, несмотря на то, что почтовый клиент получателя отображает значения полей заголовка сообщения To в качестве получателей сообщения. В полях X-Receiver обычно присутствуют и другие параметры, как показано в следующем примере:

    Скопировать код
    X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
    
    Примечание.
    Эти параметры являются значениями конверта сообщения, которые обычно создаются отправляющим сервером. Похожие параметры можно увидеть в экспортированных файлах сообщений. Эти параметры относятся к сообщениям уведомления о состоянии доставки, как описывается в RFC 1891.

    Параметр NOTIFY может принимать значение NEVER, DELAY или FAILURE. ORcpt сохраняет исходного получателя сообщения.

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

  • X-CreatedBy.   Используется для обработки заголовка в брандмауэре. Если этот X-заголовок существует, он не может быть пустым. Если поле X CreatedBy не существует, оно добавляется со значением Unspecified. Как правило, это поле имеет значение MSExchange14, однако оно также может содержать тип адресного пространства, не являющегося адресным пространством SMTP, заданный для соединителя отправки, например Notes.

  • X-EndOfInjectedXHeaders.   Размер (в байтах) всех имеющихся X-заголовков. Данный X-заголовок можно использовать в качестве метки, обозначающей последний X-заголовок перед началом обычных полей заголовка сообщения.

  • X-ExtendedMessageProps.   Расширенные свойства сообщения.

  • X-HeloDomain. Строка домена HELO/EHLO, представленная во время начального обмена данными по протоколу SMTP.

  • X-LegacyExch50.   Используется для сохранения пользовательских свойств, созданных в Exchange Server 2003, если используются серверы Exchange 2003.

  • X-Source.   Используется средством просмотра очереди в столбце MessageSourceName. Если значение данного X-заголовка не указано, используется значение Replay. Другими возможными значениями данного X-заголовка являются Smtp Receive Connector и Smtp Send Connector.

  • X-SourceIPAddress.   IP-адрес отправляющего сервера. Значение этого поля равно 0.0.0.0, если не указаны IP-адрес.

В следующем примере показано простое текстовое сообщение, в котором используется допустимый формат для каталога преобразования.

Скопировать код
X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345AB auth=<someAuth>
Subject: Optional message subject

This is the body of the message.

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

Скопировать код
X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@fabrikam.com
Subject: Optional message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>
</BODY></HTML>

Изменения заголовка сообщения в файлах сообщений каталога преобразования

В каталоге преобразования из файла сообщения удаляется поле заголовка сообщения Bcc.

В процессе доставки сообщения каталог преобразования добавляет в сообщение собственное поле заголовка Received. Поле заголовка сообщения Received имеет следующий формат.

Скопировать код
Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

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

  • Message-ID. Если данное поле заголовка сообщения отсутствует или не содержит значения, каталог преобразования добавляет в сообщение поле Message-ID в формате <GUID>@<домен_по_умолчанию>.

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

Сбои в обработке сообщений каталогом преобразования

Любые неполадки в преобразовании файла сообщения в сообщение электронной почты приводят к тому, что каталог преобразования рассматривает это сообщение как недоставляемое. В файле сообщений с ошибками содержатся серьезные проблемы, например: отсутствует отправитель, отсутствуют получатели, проблемы с форматированием. Файл сообщения, которое определено как недопустимое, остается в каталоге преобразования, его имя меняется с <имя_файла>.eml на <имя_файла>.bad. Если файл <имя_файла> в формате BAD уже существует, он переименовывается в <имя_файла><дата_и_время> в формате BAD. Если в каталоге преобразования присутствуют недопустимые сообщения, создается ошибка журнала событий, однако это происходит только один раз в отношении одного сообщения.

В начало

Вопросы безопасности, связанные с каталогами раскладки и преобразования

В следующем списке описаны вопросы, связанные с безопасностью, которые являются общими как для каталога раскладки, так и для каталога преобразования:

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

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

В следующем списке описаны дополнительные вопросы безопасности, относящиеся к каталогу преобразования:

  • X-заголовки, используемые каталогом преобразования, позволяют создать конверт сообщения вручную. Сведения в полях X-Sender и X-Receiver могут полностью отличаться от полей заголовка сообщения «Кому» или «От», отображаемых клиентами электронной почты. Подобная фальсификация отправителя или домена часто называется подделкой. Поддельная почта — это почтовое сообщение, адрес отправителя которого был изменен таким образом, чтобы он выглядел как если бы сообщение исходило от отправителя, отличного от фактического отправителя.

  • Если поле X-CreatedBy содержит значение MSExchange14, получатель считается заслуживающим доверия и обработка заголовка в брандмауэре не производится. Брандмауэр заголовков позволяет серверу Exchange сохранять X-заголовки в сообщениях, передаваемых между доверенными серверами Exchange 2010, либо удалять потенциально опасные для конфиденциальности X-заголовки из сообщений, передаваемых ненадежным получателям за пределами организации Exchange. Эти X-заголовки могут быть использованы для предоставления доступа к данным Exchange 2010, таким как вероятность нежелательной почты, подписи сообщений или шифрование между авторизованными серверами Exchange 2010. Раскрытие этих сведений неавторизованным источникам может представлять угрозу безопасности.

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

Каталог раскладки и каталог преобразования включены по умолчанию на всех транспортных серверах-концентраторах и пограничных транспортных серверах. Если на каком-либо транспортном сервере-концентраторе или пограничном транспортном сервере в организации не требуется использовать каталог раскладки или каталог преобразования, их можно отключить. Дополнительные сведения приведены в следующих разделах:

В начало

Разрешения для каталогов раскладки и преобразования

Для каталогов раскладки и преобразования необходимы следующие разрешения.

  • Администратор: полный доступ

  • Система: полный доступ

  • Сетевая служба: чтение, запись и удаление вложенных папок и файлов

По умолчанию служба транспорта Microsoft Exchange использует учетные данные безопасности учетной записи сетевой службы для управления расположением и разрешениями каталогов раскладки и преобразования. Учетной записи сетевой службы требуются эти разрешения в отношении каталога раскладки для открытия EML-файлов, переименования их в TMP-файлы и удаления либо переименования в BAD-файлы, если сообщение признано недопустимым.

Расположение этих каталогов можно переместить с помощью параметра PickupDirectoryPath и ReplayDirectoryPath командлета Set-TransportServer. Успех попытки изменить расположение каталога раскладки зависит от прав, предоставленных учетной записи сетевой службы, в новом расположении каталога раскладки, а также от того, существуют ли уже новые каталоги. Если новый каталог не существует, а учетная запись сетевой службы обладает всеми правами для создания папок и применения разрешений к новому местоположению, то создается новый каталог со всеми необходимыми разрешениями. Если новый каталог уже существует, разрешения существующего каталога не проверяются. При перемещении каталогов с помощью параметра PickupDirectoryPath или ReplayDirectoryPath командлета Set-TransportServer всегда следует проверять наличие нового каталога с допустимыми разрешениями.

В начало