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

Область действия: Exchange Server 2013

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

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

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

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

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

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

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

В Exchange 2013 каталога Pickup по умолчанию находится .%ExchangeInstallPath%TransportRoles\Pickup По умолчанию каталог воспроизведения находится в расположении %ExchangeInstallPath%TransportRoles\Replay. Правильно отформатированный EML-файл сообщения, скопированный в каталог раскладки или преобразования, обрабатывается для передачи следующим образом:

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

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

  3. Файл переименован с <filename> EML на <filename> TMP. Если TMP-файл <filename> уже существует, он будет переименован в <filename><datetime> TMP. If the file renaming fails, an event log error is generated, and the pickup process proceeds to the next file.

  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 значение "Нераскрытые получатели" добавляется в поле заголовка сообщения.

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

Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

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

  • Идентификатор сообщения: если Message-Id поле отсутствует или пусто, каталог pickup добавляет поле Message-Id с использованием формата <GUID>@<defaultdomain>.

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

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

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

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

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

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

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

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

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

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

  • Отправитель X: этот 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 задает механизм проверки подлинности на сервере обмена сообщениями, как описано в RFC2554 .

  • X-Receiver: этот X-Заголовок To заменяет требование поля заголовка сообщения в типичном smTP-сообщении. Должно существовать по X-Receiver крайней мере одно поле, содержащее один адрес электронной почты. Нескольким X-Receiver получателям разрешено использовать несколько полей. Каталог воспроизведения To игнорирует поля заголовка сообщения, если они присутствуют, To хотя почтовый клиент получателя отображает значения полей заголовка сообщения в качестве получателей сообщения. В полях могут существовать X-Receiver другие необязательные параметры, как показано в следующем примере.

    X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
    

    Примечание

    Эти параметры являются значениями конверта сообщения, которые обычно создаются отправляющим сервером. Похожие параметры можно увидеть в экспортированных файлах сообщений. Эти параметры связаны с сообщениями уведомления о состоянии доставки (DSN), как описано в RFC1891 .
    NOTIFYможет иметь значение NEVER, или DELAYFAILURE. ORcpt сохраняет исходного получателя сообщения.

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

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

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

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

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

  • X-Source: используется средством просмотра очередей в столбце MessageSourceName . Если значение этого X-заголовка не указано, используется значение Воспроизведение. Другие возможные значения для этого X-заголовка — это Соединитель получения Smtp и Соединитель отправки Smtp.

  • 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 в формате <GUID>@<defaultdomain>.

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

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

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

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

    Примечание

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

  • Badmail: сообщение, классифицированное как badmail , имеет серьезные проблемы, которые препятствуют отправке сообщения в каталоги pickup или Replay для доставки. Такие сбои также возникают в том случае, если сообщение имеет правильный формат, однако указаны недопустимые получатели сообщения, а также недопустимый отправитель, что не позволяет отправить отчет о недоставке.

    Файлы сообщений, которые определены как недопустимые, хранятся в каталогах pickup или Replay <filename> и переименовывается из EML в <filename>.bad. Если файл <filename>.bad уже существует, он будет переименован <filename><datetime> в .bad. If badmail exists in the Pickup or Replay directories, an event log error is generated, but the same badmail messages don't generate repeated event log errors.

    Примечание

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

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

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

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

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

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

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

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

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

Каталог раскладки и каталог преобразования включены по умолчанию на всех серверах почтовых ящиков и пограничных транспортных серверах. Если каталог pickup или replay не требуется на определенном сервере почтовых ящиков или пограничном транспортном сервере в организации, вы можете отключить каталог pickup или replay на этом сервере, указав для пути к каталогу pickup или replay $nullпуть к каталогу. Дополнительные сведения см. в разделе "Настройка каталога pickup" и каталога воспроизведения.

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

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

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

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

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

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

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