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

Применимо к: Exchange Server 2013Applies to: Exchange Server 2013

По умолчанию каталоги раскладки и преобразования существуют на каждом сервере почтовых ящиков Microsoft Exchange Server 2013 или пограничном транспортном сервере. Правильно отформатированные файлы сообщений электронной почты, скопированные в каталоги раскладки или преобразования, отправляются на доставку. Каталог раскладки используется администраторами для проверки потока сообщений или приложениями, которые создают и отправляют собственные сообщения. Каталог преобразования получает сообщения с серверов внешних шлюзов и может использоваться для передачи сообщений, экспортированных администраторами из очередей серверов Exchange.By default, the Pickup and Replay directories exist on every Microsoft Exchange Server 2013 Mailbox server or Edge Transport server. Correctly formatted email message files that you copy to the Pickup or Replay directories are submitted for delivery. The Pickup directory is used by administrators for mail flow testing, or by applications that must create and submit their own messages. The Replay directory receives messages from foreign gateway servers and can also be used to resubmit messages that administrators export from the queues of Exchange servers.

Строение файла сообщения электронной почтыAnatomy of an email message file

Стандартное SMTP-сообщение электронной почты состоит из конверта сообщения и его содержимого. Конверт сообщения содержит сведения, которые требуются для передачи и доставки сообщения. Содержимое сообщения разделяется на поля заголовка сообщения, которые в совокупности называются заголовком сообщения, и текста сообщения. Конверт сообщения описан в документе RFC 2821, а заголовок сообщения — в документе RFC 2822.A standard SMTP email message consists of a message envelope and message content. The message envelope contains information required for transmitting and delivering the message. The message content contains message header fields (collectively called the message header) and the message body. The message envelope is described in RFC 2821, and the message header is described in RFC 2822.

При написании сообщения электронной почты и его отправке сообщение содержит основные сведения, требуемые для соответствия стандартам SMTP, например: отправитель, получатель, время и дата написания сообщения, необязательная строка темы и необязательный текст сообщения. Данные содержатся в самом сообщении, а также, по определению, в заголовке сообщения.When a sender composes an email message and submits it for delivery, the message contains the basic information required to comply with SMTP standards, such as a sender, a recipient, the date and time that the message was composed, an optional subject line, and an optional message body. This information is contained in the message itself and, by definition, is contained in the message header.

Сервер обмена сообщениями отправителя создает для сообщения конверт сообщения на основе данных отправителя и получателя, содержащихся в заголовке сообщения, после чего передает сообщение в Интернет для доставки на сервер обмена сообщениями получателя. Получатели не видят конверт сообщения, так как он создается в процессе передачи сообщения и фактически не является частью самого сообщения.The sender's messaging server generates a message envelope for the message by using the sender and recipient information found in the message header and transmits the message to the Internet for delivery to the recipient's messaging server. Recipients never see the message envelope, because it's generated by the message transmission process and isn't actually part of the message.

Каждый сервер, участвующий в передаче сообщения, может вставлять в заголовок сообщения поля заголовка сообщения с указанием роли этого сервера в доставке сообщения или другие поля заголовка сообщения в зависимости от приложения. Когда получатель открывает сообщение с помощью клиента электронной почты, в этом приложении отображаются некоторые наиболее важные сведения заголовка сообщения, в том числе отправитель, получатели, тема сообщения и его текст.Each server involved in the transmission of the message may insert message header fields related to the server's role in delivering the message or other application-specific message header fields into the message header. When the recipient opens the message by using an email client, the email client displays some of the more relevant information from the message header, such as the sender, the recipients, and the subject together with the message body.

Обработка сообщений в каталогах раскладки и преобразованияHow the Pickup and Replay directories process messages

В Exchange 2013 расположение каталога раскладки по умолчанию: %ExchangeInstallPath%TransportRoles\Pickup.In Exchange 2013, the default location of the Pickup directory is %ExchangeInstallPath%TransportRoles\Pickup. Расположение каталога преобразования по умолчанию %ExchangeInstallPath%TransportRoles\Replay.The default location of the Replay directory is %ExchangeInstallPath%TransportRoles\Replay. Правильно отформатированный EML-файл сообщения, скопированный в каталог раскладки или преобразования, обрабатывается для передачи следующим образом:A correctly formatted .eml message file copied to the Pickup or Replay directory is processed for submission in the following steps:

  1. Каталоги раскладки и преобразования проверяются на появление новых файлов сообщений каждые пять секунд.The Pickup and Replay directories are checked for new message files every five seconds. Этот интервал опроса изменить нельзя.You can't modify this polling interval. Вы можете настроить частоту обработки файлов сообщений с помощью параметра PickupDirectoryMaxMessagesPerMinute командлета Set – TransportService .You can adjust the rate of message file processing by using the PickupDirectoryMaxMessagesPerMinute parameter on the Set-TransportService cmdlet. Этот параметр влияет на каталог раскладки и каталог преобразования.This parameter affects the Pickup directory and the Replay directory. Значением по умолчанию является 100 сообщений в минуту.The default value is 100 messages per minute. Файлы, которые не удается открыть, остаются в каталоге раскладки и повторно обрабатываются при следующем опросе.Files that can't be opened are left in the Pickup directory and are reevaluated at the next poll.

  2. Проверяются ограничения, установленные для файлов сообщений в каталоге раскладки, такие как максимальный размер заголовка и максимальное количество получателей.Limits put on message files in the Pickup directory, such as the maximum header size and the maximum number of recipients, are checked. По умолчанию максимальный размер заголовка равен 64 килобайтам (КБ), а максимальное количество получателей — 100.By default, the maximum header size is 64 kilobytes (KB), and the maximum number of recipients is 100. Эти ограничения можно изменить с помощью командлета Set-TransportService.You change these limits by using the Set-TransportService cmdlet. Эти параметры влияют только на каталог раскладки.These settings affect the Pickup directory only.

  3. Файл переименовывается из * <файла filename>. EML в * <filename>. tmp.The file is renamed from <filename>.eml to <filename>.tmp. Если файл * <filename>. tmp уже существует, он переименовывается как * <filename><DateTime>. tmp.If the <filename>.tmp file already exists, the file is renamed as <filename><datetime>.tmp. If the file renaming fails, an event log error is generated, and the pickup process proceeds to the next file.If the file renaming fails, an event log error is generated, and the pickup process proceeds to the next file.

  4. После успешного преобразования файла с расширением TMP в сообщение электронной почты к файлу с расширением TMP применяется команда удалить при закрытии. Этот TMP-файл остается в каталоге раскладки, однако не может быть открыт.After the .tmp file is successfully converted into an email message, a delete on close command is issued to the .tmp file. The .tmp file appears to remain in the Pickup directory, but the file can't be opened.

  5. После того, как сообщение помещено в очередь доставки, выполняется команда close и TMP-файл удаляется из каталога раскладки. Если не удается удалить файл, создается журнал ошибок. Если служба транспорта Microsoft Exchange перезапущена при наличии файлов с расширением TMP в каталоге раскладки, расширение всех этих файлов меняется на EML, и они обрабатываются повторно. Это может привести к передаче дублированных сообщений.After the message is successfully queued for delivery, a close command is issued, and the .tmp file is deleted from the Pickup directory. If the deletion fails, an event log error is generated. If the Microsoft Exchange Transport service is restarted when there are .tmp files in the Pickup directory, all .tmp files are renamed as .eml files and are reprocessed. This could lead to duplicate message transmission.

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

Чтобы доставка файла сообщения, скопированного в каталог раскладки, была успешно выполнена, этот файл должен отвечать следующим требованиям:A message file copied to the Pickup directory must meet the following requirements for successful delivery:

  • Файл сообщения должен быть текстовым файлом, соответствующим стандартному формату SMTP-сообщения. Поддерживаются поля и содержимое заголовка сообщения MIME.The message file must be a text file that complies with the basic SMTP message format. MIME message header fields and content are supported.

  • Файл сообщения должен иметь расширение EML.The message file must have an .eml file name extension.

  • По крайней мере один адрес электронной почты должен Sender существовать From в полях заголовков сообщений или сообщений в заголовке сообщения.At least one email address must exist in the Sender or From message header fields in the message header. Если в полях "и Sender From " существует один адрес электронной почты, адрес электронной почты в From поле используется в качестве инициатора сообщения в конверте сообщения.If a single email address exists in both the Sender and From fields, the email address in the From field is used as the originator of the message in the message envelope.

  • В этом Sender поле может присутствовать только один адрес электронной почты.Only one email address can exist in the Sender field. Наличие нескольких адресов не допускается.Multiple email addresses aren't allowed. Sender Поле является необязательным, если в From поле есть только один адрес электронной почты.The Sender field is optional if only one email address exists in the From field.

  • В From поле можно указать несколько адресов электронной почты, но в Sender поле также должен быть один адрес электронной почты.Multiple email addresses are allowed in the From field, but a single email address must also exist in the Sender field. После этого адрес в Sender поле будет использоваться как инициатор сообщения в конверте сообщения.The address in the Sender field is then used as the originator of the message in the message envelope.

  • По крайней мере один адрес электронной почты должен Toсуществовать Ccв полях Bcc , или.At least one email address must exist in the To, Cc, or Bcc fields.

  • Между заголовком и текстом сообщения должна стоять пустая строка.A blank line must exist between the message header and the message body.

В следующем примере показано простое текстовое сообщение, в котором используется допустимый формат для каталога раскладки.This example shows a plain text message that uses acceptable formatting for the Pickup directory.

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, в котором используется допустимый формат для каталога раскладки.MIME content is also supported in Pickup directory message files. MIME defines a broad range of message content that includes languages that can't be represented in 7-bit ASCII text, HTML, and other multimedia content. A complete description of MIME and its requirements is beyond the scope of this topic. This example shows a simple MIME message that uses acceptable formatting for the Pickup directory.

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>

Изменения заголовка сообщения в каталоге раскладкиPickup directory message header modifications

В каталоге раскладки из заголовка сообщения удаляются все следующие поля заголовка сообщения:The Pickup directory removes any of the following message header fields from the message header:

  • Received

  • Resent-*

  • Bcc

    Примечание

    Все адреса электронной почты, обнаруженные Bcc в необязательных полях заголовка сообщения, обрабатываются правильно.Any email addresses found in the optional Bcc message header fields in the message header are correctly processed. После того Bcc как получатели переходят на невидимые получатели конвертов сообщений, они удаляются из заголовка сообщения для защиты их удостоверения.After the Bcc recipients are promoted to invisible message envelope recipients, they are removed from the message header to protect their identity. Если сообщение содержит только Bcc получателей, значение получателей скрытые добавляется в To поле в заголовке сообщения.If a message contains only Bcc recipients, the value of Undisclosed Recipients is added to the To field in the message header.

Каталог раскладки добавляет собственное Received поле заголовка к сообщению в рамках процесса отправки сообщения.The Pickup directory adds its own Received header field to a message as part of the message submission process. Поле Received заголовка применяется в следующем формате.The Received header field is applied in the following format.

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

В каталоге раскладки изменяются следующие поля заголовка сообщения, если они отсутствуют или имеют неправильный формат:The Pickup directory modifies the following message header fields if they're missing or malformed:

  • Message-ID: Если Message-Id поле отсутствует или пусто, каталог раскладки добавляет поле Message-ID с помощью формата * <>GUID*<>@DefaultDomain.Message-Id: If the Message-Id field is missing or empty, the Pickup directory adds a Message-Id field by using the format <GUID>@<defaultdomain>.

  • Дата: Если Date поле отсутствует или имеет неправильный формат, каталог раскладки добавляет дату и время обработки сообщения в каталоге раскладки.Date: If the Date field is missing or malformed, the Pickup directory adds the date and time of message processing by the Pickup directory.

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

Каталог преобразования используется для передачи экспортированных сообщений Exchange и получения сообщений с внешних серверов шлюзов. Эти сообщения уже отформатированы для каталога преобразования. Практически нет необходимости в том, чтобы администраторы или приложения создавали и доставляли новые файлы сообщений с помощью каталога преобразования. Для создания и отправки файлов новых сообщений должен использоваться каталог раскладки.The Replay directory is used to resubmit exported Exchange messages and to receive messages from foreign gateway servers. These messages are already formatted for the Replay directory. There is little or no need for administrators or applications to compose and submit new message files by using the Replay directory. The Pickup directory should be used to create and submit new message files.

В сообщениях каталога преобразования очень часто используются поля X-заголовков. X-заголовки представляют собой пользовательские неофициальные поля заголовка, которые включаются в заголовок сообщения. X-заголовки не рассматриваются в RFC 2822, однако использование неопределенного поля заголовка сообщения, которое начинается с символа «X-» стало общепринятым способом добавления в сообщение неофициальных полей заголовка сообщения. X-заголовки в Exchange, которые используются в файлах сообщений в каталоге преобразования, могут содержать сведения о доставке, обычно указываемые в конверте сообщения. Эта функция необходима для сохранения исходных сведений сообщения при использовании каталога преобразования для обработки экспортированных сообщений с другого сервера Exchange.The Replay directory messages make extensive use of X-Headers. X-Headers are user-defined, unofficial message header fields that exist in the message header. X-Headers aren't specifically mentioned in RFC 2822, but the use of an undefined message header field starting with "X-" has become an accepted way to add unofficial message header fields to a message. The Exchange-specific X-Headers used in the message files in the Replay directory can actually set delivery information that normally exists in the message envelope. This feature is required to preserve original message information when you use the Replay directory to process exported messages from another Exchange server.

Чтобы доставка файла сообщения, скопированного в каталог преобразования, была успешно выполнена, этот файл должен отвечать следующим требованиям:A message file copied to the Replay directory must meet the following requirements for successful delivery:

  • Файл сообщения должен быть текстовым файлом, соответствующим стандартному формату SMTP-сообщения. Поддерживаются поля и содержимое заголовка сообщения MIME.The message file must be a text file that complies with the basic SMTP message format. MIME message header fields and content are supported.

  • Файл сообщения должен иметь расширение EML.The message file must have an .eml file name extension.

  • X-заголовки должны стоять перед всеми обычными полями заголовка.X-Headers must occur before all regular header fields.

  • Поля заголовка и текст сообщения должна разделять пустая строка.A blank line must exist between the header fields and the message body.

X-заголовки, описанные в следующем списке, требуются сообщениями в каталоге преобразования.The X-Headers described in the following list are required by messages in the Replay directory:

  • X-отправитель: этот x-заголовок заменяет From требование к полю заголовка сообщения в типичном SMTP-сообщении.X-Sender: This X-Header replaces the From message header field requirement in a typical SMTP message. Должно X-Sender существовать одно поле, содержащее один адрес электронной почты.One X-Sender field that contains one email address must exist. Каталог преобразования игнорирует поле заголовка From сообщения, несмотря на то, что почтовый клиент получателя отображает значение поля заголовка From сообщения в качестве отправителя сообщения.The Replay directory ignores the From message header field if it's present, although the recipient's email client displays the value of the From message header field as the sender of the message. В этом X-Sender поле обычно существуют другие параметры, как показано в следующем примере.Other parameters usually exist in the X-Sender field, as shown in the following example.

    X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
    

    Примечание

    Эти параметры являются значениями конверта сообщения, которые обычно создаются отправляющим сервером. Похожие параметры можно увидеть в экспортированных файлах сообщений.These parameters are message envelope values that are ordinarily generated by the sending server. You may see parameters similar to this in exported message files.
    RETУказывает, следует ли вернуть в отправителю сообщение целиком или только заголовки, если сообщение не может быть доставлено.RET specifies whether the whole message or only the headers should be returned to the sender if the message can't be delivered. RETможет иметь значение HDRS или FULL. ENVID — это идентификатор конверта сообщения.RET can have a value of HDRS or FULL. ENVID is a message envelope identifier. BODYЗадает кодировку текста сообщения.BODY specifies the text encoding of the message. authЗадает механизм проверки подлинности для сервера обмена сообщениями, как описано в RFC 2554.auth specifies an authentication mechanism to the messaging server as described in RFC 2554.

  • X-приемник: этот x-заголовок заменяет обязательное поле заголовка To сообщения в типичном SMTP-сообщении.X-Receiver: This X-Header replaces the To message header field requirement in a typical SMTP message. Должно существовать по X-Receiver крайней мере одно поле, содержащее один адрес электронной почты.At least one X-Receiver field that contains one email address must exist. Несколько X-Receiver полей разрешено нескольким получателям.Multiple X-Receiver fields are allowed for multiple recipients. В каталоге преобразования игнорируются поля заголовка To сообщения, хотя почтовый клиент получателя отображает значения полей заголовков To сообщений в качестве получателей сообщения.The Replay directory ignores the To message header fields if they're present, although the recipient's email client displays the values of the To message header fields as the recipients of the message. В X-Receiver полях могут присутствовать и другие необязательные параметры, как показано в следующем примере.Other optional parameters may exist in the X-Receiver fields, as shown in the following example.

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

    Примечание

    Эти параметры являются значениями конверта сообщения, которые обычно создаются отправляющим сервером.These parameters are message envelope values that are ordinarily generated by the sending server. Похожие параметры можно увидеть в экспортированных файлах сообщений.You may see parameters similar to this in exported message files. Эти параметры относятся к сообщениям уведомления о доставке (DSN), как описано в RFC 1891.These parameters are related to delivery status notification (DSN) messages as described in RFC 1891.
    NOTIFYможет иметь значение NEVER, DELAYили. FAILURENOTIFY can have a value of NEVER, DELAY, or FAILURE. ORcptСохранение исходного получателя сообщения.ORcpt preserves the original recipient of the message.

X-заголовки, описанные в следующем списке, не являются обязательными в файлах сообщений каталога преобразования.The X-Headers described in the following list are optional for message files in the Replay directory:

  • X CreatedBy: используется для функций брандмауэра заголовков.X-CreatedBy: Used for header firewall functionality. Если этот X-заголовок существует, он не может быть пустым.If this X-Header exists, it must not be blank. Если X-CreatedBy поле не существует, оно добавляется с незаданным значением ****.If the X-CreatedBy field doesn't exist, it's added with a value of Unspecified. Как правило, это поле имеет значение MSExchange15, однако оно также может содержать тип адресного пространства, не являющегося адресным пространством SMTP, который задан для соединителя отправки, например Примечания.Typically, the value of this field is MSExchange15, but it also may contain the non-SMTP address space type set on a Send connector, such as Notes.

  • X — ендофинжектедксхеадерс: размер в байтах всех имеющихся X заголовков.X-EndOfInjectedXHeaders: Size in bytes of all the X-Headers present. Данный X-заголовок можно использовать в качестве метки, обозначающей последний X-заголовок перед началом обычных полей заголовка сообщения.This X-Header may be used as a marker to indicate the last X-Header before the regular message header fields start.

  • X — екстендедмессажепропс: расширенные свойства сообщения для сообщения.X-ExtendedMessageProps: Extended message properties for the message.

  • X-хелодомаин: строка домена HELO/EHLO, представленная во время начальной беседы по протоколу SMTP.X-HeloDomain: HELO/EHLO domain string presented during the initial SMTP protocol conversation.

  • X источник: используется средством просмотра очереди в столбце мессажесаурценаме .X-Source: Used by Queue Viewer under the MessageSourceName column. Если значение этого X-заголовка не указано, используется значение Воспроизведение.If the value of this X-Header isn't specified, the value of Replay is used. Другие возможные значения для этого X-заголовка — это Соединитель получения Smtp и Соединитель отправки Smtp.Other possible values for this X-Header are Smtp Receive Connector and Smtp Send Connector.

  • X-SourceIPAddress: IP-адрес отправляющего сервера.X-SourceIPAddress: IP address of the sending server. В этом поле 0.0.0.0 указывается, если IP-адрес не указан.This field is 0.0.0.0 if no IP address is specified.

В следующем примере показано простое текстовое сообщение, в котором используется допустимый формат для каталога преобразования.This example shows a plain text message that uses acceptable formatting for the Replay directory.

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, в котором используется допустимый формат для каталога преобразования.MIME content is also supported in Replay directory message files. MIME defines a broad range of message content that includes languages that can't be represented in 7-bit ASCII text, HTML, and other multimedia content. A complete description of MIME and its requirements is beyond the scope of this topic. This example shows a simple MIME message that uses acceptable formatting for the Replay directory.

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>

Изменения заголовка сообщения в каталоге воспроизведенияReplay directory message header modifications

В каталоге преобразования из файла сообщения Bcc удаляется поле заголовка сообщения.The Replay directory deletes the Bcc message header field from the message file.

Каталог преобразования добавляет в сообщение собственное Received поле заголовка сообщения в рамках процесса отправки сообщения.The Replay directory adds its own Received message header field to a message as part of the message submission process. Поле заголовка сообщения Received имеет следующий формат.The Received message header field is applied in the following format.

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

Каталог преобразования изменяет следующие поля заголовка сообщения:The Replay directory modifies the following message header fields in the message header:

  • Message-ID: если это поле заголовка сообщения отсутствует или пусто, каталог преобразования добавляет поле заголовка сообщения Message-ID с помощью формата * <>GUID*@<>DefaultDomain*.Message-ID: If this message header field is missing or empty, the Replay directory adds a Message-ID message header field by using the format <GUID>@<defaultdomain>*.

  • Дата: если это поле заголовка сообщения отсутствует или имеет неправильный формат, каталог преобразования добавляет поле даты заголовка сообщения с использованием даты и времени обработки сообщений каталогом преобразования.Date: If this message header field is missing or malformed, the Replay directory adds the Date message header field using the date and time of message processing by the Replay directory.

Сбои при обработке сообщений в каталоге раскладки и преобразованияFailures in Pickup and Replay directory message processing

Постановка в очередь доставки файла сообщения, скопированного в каталог раскладки или преобразования, может завершиться неудачно. Могут возникнуть следующие категории сбоев при передаче сообщения:A message file copied to the Pickup or Replay directories may not be successfully queued for delivery. The following categories of message submission failure can occur:

  • Ошибки доставки: правильно отформатированный файл сообщений вместе с допустимым отправителем, которые не удается отправить для доставки, создает отчет о недоставке (NDR).Delivery failures: A correctly formatted message file together with a valid sender that can't be successfully submitted for delivery generates a non-delivery report (NDR). Неправильный формат содержания или нарушения ограничений сообщений каталога раскладки могут также стать причиной создания отчета о недоставке.Malformed content or Pickup directory message restriction violations could also cause an NDR. Если отчет о недоставке создается в процессе обработки сообщения, в сообщение отчета вкладывается исходный файл сообщения, который после этого удаляется из каталога раскладки или каталога преобразования.When an NDR is generated during message processing, the original message file is attached to the NDR message, and the message file is deleted from the Pickup directory or the Replay directory.

    Примечание

    При доставке правильно отформатированного сообщения в транспортный конвейер может произойти сбой, в этом случае сообщение возвращается отправителю с отчетом о недоставке. Такой тип сбоя может быть вызван проблемами передачи, не имеющими отношения к каталогам раскладки или преобразования, например сбоем сервера обмена сообщениями или сбоями маршрутизации в процессе доставки сообщения.A correctly formatted message submitted into the transport pipeline may later experience a delivery failure and be returned to the sender with an NDR. This kind of failure may be caused by transmission issues unrelated to the Pickup or Replay directories, such as messaging server failures or routing failures along the delivery path of the message.

  • Badmail: сообщение об ошибке, классифицированное как Badmail , имеет серьезные проблемы, которые не позволяют каталогам раскладки или преобразования отправлять сообщение для доставки.Badmail: A message classified as badmail has serious problems that prevent the Pickup or Replay directories from submitting the message for delivery. Такие сбои также возникают в том случае, если сообщение имеет правильный формат, однако указаны недопустимые получатели сообщения, а также недопустимый отправитель, что не позволяет отправить отчет о недоставке.The other condition that causes badmail is when the message is formatted correctly, but the recipients aren't valid, and an NDR message can't be sent to the sender because the sender isn't valid.

    Файлы сообщений, которые были определены как Badmail, остаются в каталогах раскладки или преобразования и переименованы из * <файла filename>. EML в * <filename>. Bad.Message files determined to be badmail are left in the Pickup or Replay directories and are renamed from <filename>.eml to <filename>.bad. Если файл * <filename>. Bad уже существует, он переименовывается в * <filename><DateTime>. Bad.If the <filename>.bad file already exists, the file is renamed to <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.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.

    Примечание

    Всегда формируйте и сохраняйте файлы сообщений в другом расположении перед их копированием в каталог раскладки.Always compose and save message files in a different location before you copy them into the Pickup directory for delivery. Каталог раскладки опрашивается на наличие новых сообщений каждые пять секунд.The Pickup directory polls for new messages every five seconds. Таким образом, если сообщение создается и сохраняется непосредственно в каталоге раскладки, файлы сообщения могут быть обработаны до завершения их сборки.Therefore, if you try to compose and save the message files in the Pickup directory itself, the Pickup directory may try to process the message files before you finish composing them.

Вопросы безопасности, связанные с каталогами раскладки и преобразованияSecurity considerations for the Pickup and Replay directories

В следующем списке описаны вопросы, связанные с безопасностью, которые являются общими как для каталога раскладки, так и для каталога преобразования:The following list describes security concerns that are common to the Pickup directory and the Replay directory:

  • Любые проверки безопасности, настроенные на соединителе получения, такие как защита от нежелательной почты, вредоносных программ, фильтрация отправителей или фильтрация получателей, не выполняются в отношении сообщений, предоставленных через каталог раскладки или каталог преобразования.Any security checks configured on a Receive connector, such as anti-spam, anti-malware, sender filtering, or recipient filtering actions, aren't performed on messages submitted through the Pickup directory or the Replay directory.

  • Взломанные каталоги раскладки и преобразования могут служить открытыми ретрансляторами. Это позволяет передавать, или ретранслировать сообщения с использованием другого сервера в целях маскировки настоящего источника сообщений.A compromised Pickup directory or Replay directory can act as an open relay. This enables messages to be resubmitted or relayed by using a different server to mask the true source of the messages.

В следующем списке описаны дополнительные вопросы безопасности, относящиеся к каталогу преобразования:The following list describes additional security concerns that apply to the Replay directory:

  • X-заголовки, используемые каталогом преобразования, позволяют создать конверт сообщения вручную.The X-Headers used by the Replay directory allow for the manual creation of the message envelope. X-Sender Сведения в полях X-Receiver и могут быть полностью отличаться от To полей заголовка From сообщения, отображаемых почтовыми клиентами.The information in the X-Sender and X-Receiver fields can be completely different from the To or From message header fields displayed by email clients. Подобная фальсификация отправителя или домена часто называется подделкой.Such an impersonation of a sender and a domain is frequently called spoofing. Поддельное сообщение — это почтовое сообщение, адрес отправителя которого был изменен таким образом, чтобы он выглядел, как если бы сообщение исходило от отправителя, отличного от фактического отправителя.A spoofed mail is an email message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message.

  • Если X-CreatedBy поле имеет значение MSExchange15, назначение считается заслуживающим доверия, а брандмауэр заголовков не применяется.If the X-CreatedBy field has the value of MSExchange15, the destination is considered trustworthy, and header firewall isn't applied. Брандмауэр заголовков позволяет серверу Exchange сохранять X-заголовки в сообщениях, передаваемых между доверенными серверами Exchange, либо удалять потенциально опасные для конфиденциальности X-заголовки из сообщений, передаваемых ненадежным получателям за пределами организации Exchange.Header firewall is a way for Exchange to preserve X-Headers in messages transmitted between trusted Exchange servers or to remove potentially revealing X-Headers from messages transmitted to untrusted destinations outside the Exchange organization. Эти X-заголовки могут быть использованы для предоставления доступа к данным Exchange, таким как вероятность нежелательной почты, подписи сообщений или шифрование между авторизованными серверами Exchange.These X-Headers can be used to share Exchange information such as spam confidence level (SCL), message signing, or encryption between authorized Exchange servers. Раскрытие этих сведений неавторизованным источникам может представлять угрозу безопасности.Revealing this information to unauthorized sources could pose a potential security risk. Дополнительные сведения о брандмауэре заголовков можно узнать в статье Общиесведения о брандмауэре заголовков.For more information about header firewall, see Understanding Header Firewall.

К каталогу преобразования следует применять более жесткие параметры безопасности, поскольку с этим каталогом связаны дополнительные угрозы безопасности. Пользователям или приложениям, которые должны создавать и передавать сообщения, можно предоставить доступ к каталогу раскладки, однако им не нужен доступ к каталогу преобразования.Tighter security should be applied to the Replay directory because of the additional security risks associated with the Replay directory. Users or applications that must generate and submit messages can be granted access to the Pickup directory, but they shouldn't require access to the Replay directory.

Каталог раскладки и каталог преобразования включены по умолчанию на всех серверах почтовых ящиков и пограничных транспортных серверах.Both the Pickup directory and the Replay directory are enabled by default on all Mailbox servers and Edge Transport servers. Если каталог раскладки или каталог преобразования не требуется на определенном сервере почтовых ящиков или пограничном транспортном сервере в Организации, можно отключить каталог раскладки или каталог преобразования на этом сервере, задав путь к каталогу раскладки или повторить путь к каталогу для $nullзначения.If the Pickup directory or the Replay directory isn't required on a specific Mailbox server or Edge Transport server in your organization, you can disable the Pickup directory or the Replay directory on that server by setting the Pickup directory path or Replay directory path to the value $null. Дополнительные сведения см. в разделе Настройка каталога раскладки и каталога преобразования.For more information, see Configure the Pickup directory and the Replay directory.

Разрешения для каталогов раскладки и преобразованияPermissions for the Pickup and Replay directories

Для каталогов раскладки и преобразования необходимы следующие разрешения.The following permissions are required on the Pickup and Replay directories:

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

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

  • Сетевая служба: чтение, запись и удаление вложенных папок и файловNetwork Service: Read, Write, and Delete Subfolders and Files

По умолчанию служба транспорта Microsoft Exchange использует учетные данные для безопасного доступа к учетной записи пользователя сетевой службы для управления расположением и разрешениями каталогов раскладки и преобразования. Учетной записи сетевой службы требуются эти разрешения в отношении каталога раскладки для открытия EML-файлов, переименования их в TMP-файлы и удаления либо переименования в BAD-файлы, если сообщение признано недопустимым.By default, the Microsoft Exchange Transport service uses the security credentials of the Network Service user account to manage the location and permissions of the Pickup and Replay directories. The Network Service account requires these permissions on the Pickup directory so that .eml files can be opened, renamed to .tmp and deleted, or renamed to .bad if the message is classified as badmail.

Вы можете переместить расположение этих каталогов с помощью параметров PickupDirectoryPath и ReplayDirectoryPath в командлете Set/TransportService .You can move the location of these directories by using the PickupDirectoryPath and ReplayDirectoryPath parameters on the Set-TransportService cmdlet. Успех попытки изменить расположение каталога раскладки зависит от прав, предоставленных учетной записи сетевой службы, в новом расположении каталога раскладки, а также от того, существуют ли уже новые каталоги.Successfully changing the location of the Pickup directory depends on the rights granted to the Network Service account at the new directory locations, and whether the new directories already exist. Если новый каталог не существует, а учетная запись сетевой службы обладает всеми правами для создания папок и применения разрешений к новому местоположению, то создается новый каталог со всеми необходимыми разрешениями.If the directory doesn't exist, and the Network Service account has the rights required to create folders and apply permissions at the new location, the directory is created, and the correct permissions are applied to it. Если новый каталог уже существует, разрешения существующего каталога не проверяются.If the new directory already exists, the existing folder permissions aren't checked. При перемещении расположений каталогов с помощью параметра PickupDirectoryPath или ReplayDirectoryPath с помощью командлета Set – TransportService всегда проверяйте, что новый каталог существует, а новый каталог имеет к нему применены правильные разрешения.Whenever you move the directory locations by using the PickupDirectoryPath or ReplayDirectoryPath parameter with the Set-TransportService cmdlet, always verify that the new directory exists and that the new directory has the correct permissions applied to it.