Поделиться через


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

Область применения: 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>. <Если файл filename.tmp> уже существует, он будет переименован в <имя файла><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 поле используется в качестве инициатора сообщения в конверте сообщения.

  • В полях , Ccили Bcc должен существовать по крайней Toмере один адрес электронной почты.

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

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

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. Если Message-Id поле отсутствует или пусто, каталог Pickup добавляет поле Message-Id с помощьюдомена> по умолчанию GUID<@>формата<.

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

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

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

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

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

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

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

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

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

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

  • X-Sender: этот X-Header заменяет требование поля заголовка 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-Header заменяет требование поля заголовка 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. Как правило, это поле имеет значение 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: если это поле заголовка сообщения отсутствует или пусто, каталог воспроизведения добавляет поле заголовка сообщения Message-ID с помощью идентификатора доменапо умолчанию> в формате<<GUID>@.

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

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

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

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

    Примечание.

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

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

    Файлы сообщений, определенные как badmail, остаются в каталогах Pickup или Replay и переименовываются с <filename.eml> на <filename.bad>. <Если файл filename.bad> уже существует, он будет переименован в <имя файла><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.

    Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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