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

1. Каталог преобразования проверяется на наличие новых файлов сообщений каждые 5 секунд. Этот интервал опроса изменить нельзя. Скорость обработки файлов сообщений можно изменить с помощью параметра PickupDirectoryMaxMessagesPerMinute командлета Set-TransportServer. Значением по умолчанию является 100 сообщений в минуту. Файлы, которые не удается открыть, оставляются в каталоге преобразования и повторно оцениваются в следующем цикле.
   
   
2. Файл переименовывается из <имя_файла>.eml в <имя_файла>.tmp. Если файл <имя_файла>.tmp уже существует, он переименовывается в <имя_файла><дата_время>.tmp. Если не удается переименовать файл, создается запись в журнале ошибок, и процесс преобразования переходит к следующему файлу.
   
   
3. После успешного преобразования TMP-файла в сообщение электронной почты к TMP-файлу применяется команда «стереть при закрытии». Это выглядит так, будто TMP-файл остается в каталоге преобразования, но никто другой не сможет его открыть.
   
   
4. После успешной постановки сообщения в очередь доставки выполняется команда «закрыть» и TMP-файл удаляется из каталога преобразования. Если не удается удалить файл, создается журнал ошибок. Если служба транспорта Microsoft Exchange запускается повторно, а в каталоге преобразования содержатся TMP-файлы, все TMP-файлы переименовываются в EML-файлы и повторно обрабатываются. Это может привести к передаче дублированных сообщений.
   
   

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

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

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

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

В сообщениях каталога преобразования очень часто используются поля X-заголовки. X-заголовки представляют собой пользовательские неофициальные поля заголовка, которые включаются в заголовок сообщения. X-заголовки не рассматриваются в RFC 2822, однако использование неопределенного поля заголовка сообщения, которое начинается с символа «X-» стало общепринятым способом добавления в сообщение неофициальных полей заголовка сообщения. X-заголовки в Exchange 2007, которые используются в файлах сообщений в каталоге преобразования, могут содержать сведения о доставки, обычно указываемые в заголовке сообщения. Эта возможность требуется для сохранения исходных сведений сообщения при использовании каталога преобразования для обработки экспортированных сообщений с другого сервера 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. Как правило, это поле имеет значение MSExchange12, однако оно также может содержать тип адресного пространства, не являющегося адресным пространством SMTP, заданный для соединителя отправления, например Notes. Это поле заголовка сообщения используется для обработки заголовка на брандмауэре.
  
  
• X-EndOfInjectedXHeaders:. Размер всех присутствующих X-заголовков в байтах. Данный X-заголовок можно использовать в качестве метки, обозначающей последний X-заголовок перед началом обычных полей заголовка сообщения.
  
  
• X-ExtendedMessageProps:. Расширенные свойства сообщения.
  
  
• X-HeloDomain:. Строка домена HELO/EHLO, представленная во время начального обмена данными по протоколу SMTP.
  
  
• X-LegacyExch50:. Используется для сохранения настраиваемых свойств, созданных в Exchange Server 2003, при наличии серверов Exchange 2003.
  
  
• X-Source:. Если значение данного X-заголовка не указано, используется значение Replay. Данный X-заголовок используется средством просмотра очереди в столбце MessageSourceName. Другими возможными значениями данного 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@contoso.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@contoso.com> BODY=7bit ENVID=12345ABCD auth=<someAuth> To: mary@contoso.com From: bob@contoso.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. Если недопустимая почта существует в каталоге преобразования, создается журнал ошибок. Однако те же самые недопустимые сообщения не создают повторные ошибки в журнале событий.

В сервере Exchange Server 2003 используется единый каталог раскладки для создания и отправки файлов текстовых сообщений. Сервер Exchange 2007 разделяет эти функции между каталогами раскладки и преобразования. Каталог раскладки предназначен для ручного создания новых файлов сообщений пользователями или приложениями. Каталог преобразования предназначен для повторной отправки экспортированных сообщений электронной почты Exchange и для получения сообщения от соединителей, не работающих по протоколу SMTP. Это разделение обязанностей позволяет применить соответствующий уровень безопасности к одному каталогу, не затрагивая возможности другого каталога.

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

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

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

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

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

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

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

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

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

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

• Настройка каталога воспроизведения
  
  
• Управление каталогом повтора
  
  
• Set-TransportServer