Каталог раскладки и каталог преобразования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.

СодержаниеContents

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

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

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

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

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

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

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

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

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

Строение файла сообщения электронной почты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.

В началоReturn to top

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

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

  1. Каталогов раскладки и преобразования проверяется наличие новых файлов сообщений каждые пять секунд. Интервал опроса нельзя изменить. Можно настроить скорость обработки с помощью параметра PickupDirectoryMaxMessagesPerMinute в командлете Set-TransportService файла сообщения. Этот параметр влияет на каталога раскладки и каталога преобразования. Значение по умолчанию — 100 сообщений в минуту. Файлы, которые не могут быть открыты, исключаются из каталога раскладки и выполняется переоценка в следующем опроса.The Pickup and Replay directories are checked for new message files every five seconds. You can't modify this polling interval. 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. 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. Проверяются ограничения, установленные для файлов сообщений в каталоге раскладки, такие как максимальный размер заголовка и максимальное количество получателей. По умолчанию максимальный размер заголовка равен 64 килобайтам (КБ), а максимальное количество получателей — 100. Эти ограничения можно изменить с помощью командлета Set-TransportService. Эти параметры влияют только на каталог раскладки.Limits put on message files in the Pickup directory, such as the maximum header size and the maximum number of recipients, are checked. By default, the maximum header size is 64 kilobytes (KB), and the maximum number of recipients is 100. You change these limits by using the Set-TransportService cmdlet. These settings affect the Pickup directory only.

  3. Переименовать файл из * <filename>* EML с помощью проводника для * <filename>.tmp. Если * <filename>.tmp файл уже существует, переименовать файл как * <filename><даты и времени>*.tmp. Если не удается переименовать файл, возникает ошибка журнала событий и раскладки процесс переходит к следующему файлу.The file is renamed from <filename>.eml to <filename>.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.

  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.

В началоReturn to top

Требования к файлам сообщений в каталоге раскладки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 сообщений поля заголовка в заголовке сообщения. Если существует отдельный адрес электронной почты в обоих Sender и From поля адреса электронной почты в From поля используется в качестве инициатора сообщения в конверте сообщения.At least one email address must exist in the Sender or From message header fields in the message header. 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 поля. Не разрешается несколько адресов электронной почты. Sender Поле является необязательным, если доступно только один адрес электронной почты в From поля.Only one email address can exist in the Sender field. Multiple email addresses aren't allowed. The Sender field is optional if only one email address exists in the From field.

  • Разрешено несколько адресов электронной почты в From поля, однако отдельный адрес электронной почты должен существовать в Sender поля. Адрес в Sender поля используется в качестве инициатора сообщения в конверте сообщения.Multiple email addresses are allowed in the From field, but a single email address must also exist in the Sender field. 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>

В началоReturn to top

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

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

  • Received

  • Resent-*

  • Bcc

    Примечание

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

Каталог раскладки добавляет свой собственный Received поля заголовка для сообщений в ходе процесса отправки сообщения. Received Поле заголовка применяется в следующем формате.The Pickup directory adds its own Received header field to a message as part of the message submission process. 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 является отсутствует или пуст, каталога раскладки добавляет поле идентификатор сообщения, используя формат * <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.

В началоReturn to top

Требования к файлам сообщений в каталоге преобразования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 должны существовать в поле, которое содержит один адрес электронной почты. Игнорирует каталога преобразования From поле заголовка сообщения, если он существует, несмотря на то, что клиент электронной почты получателя — отображает значение From поле заголовка сообщения как отправителя сообщения. Другие параметры обычно находятся в X-Sender поля, как показано в следующем примере.X-Sender This X-Header replaces the From message header field requirement in a typical SMTP message. One X-Sender field that contains one email address must exist. 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. 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 может иметь значение HDRS или FULL. ENVID — это идентификатор конверт сообщения. BODY указывает кодировка текста сообщения. auth указывает механизм проверки подлинности на сервере обмена сообщениями, как описано в документе RFC 2554.RET specifies whether the whole message or only the headers should be returned to the sender if the message can't be delivered. RET can have a value of HDRS or FULL. ENVID is a message envelope identifier. BODY specifies the text encoding of the message. auth specifies an authentication mechanism to the messaging server as described in RFC 2554.

  • X-получателя X-заголовка заменяет To условием поля заголовка сообщения в типичного сообщения SMTP. По крайней мере один X-Receiver должны существовать в поле, которое содержит один адрес электронной почты. Несколько X-Receiver поля разрешено для нескольких получателей. Игнорирует каталога преобразования To сообщение поля заголовков, если этот параметр указан, несмотря на то, что клиент электронной почты получателя отображает значения To полей заголовка сообщения как получателей копии сообщения. Другие необязательные параметры могут существовать в X-Receiver поля, как показано в следующем примере.X-Receiver This X-Header replaces the To message header field requirement in a typical SMTP message. At least one X-Receiver field that contains one email address must exist. Multiple X-Receiver fields are allowed for multiple recipients. 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. 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
    

    Примечание

    Эти параметры используются значения конверт сообщения, которые обычно создаются с сервера-отправителя. Вы можете увидеть параметры следующего вида в файлах экспортированного сообщения. Эти параметры связаны с уведомлений о Доставке сообщения о состоянии доставки, как описано в документе RFC 1891.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. These parameters are related to delivery status notification (DSN) messages as described in RFC 1891.
    NOTIFYможет иметь значение NEVER, DELAY, или FAILURE. ORcpt сохраняет исходный получатель сообщения.NOTIFY can have a value of NEVER, DELAY, or FAILURE. 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 Используется для заголовка функциональные возможности брандмауэра. Если существует X-заголовка, оно не должно быть пустым. Если X-CreatedBy поля не существует, он добавляется со значением не определено. Как правило MSExchange15имеет значение в этом поле, но он также может содержать отличного от SMTP типа адресного пространства на соединитель отправки, такие как заметки.X-CreatedBy Used for header firewall functionality. If this X-Header exists, it must not be blank. If the X-CreatedBy field doesn't exist, it's added with a value of Unspecified. 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-EndOfInjectedXHeaders Размер в байтах всех заголовков X присутствует. X-заголовка может использоваться в качестве маркера для указания последнего X-заголовка до начала полей заголовка сообщения регулярных.X-EndOfInjectedXHeaders Size in bytes of all the X-Headers present. This X-Header may be used as a marker to indicate the last X-Header before the regular message header fields start.

  • X-ExtendedMessageProps Расширенные свойства сообщения для сообщения.X-ExtendedMessageProps Extended message properties for the message.

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

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

  • X-SourceIPAddress IP-адрес сервера-отправителя. Это поле является 0.0.0.0 Если не IP-адрес не указан.X-SourceIPAddress IP address of the sending server. 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>

В началоReturn to top

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

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

Каталога преобразования добавляет свой собственный Received поле заголовка сообщения к сообщению как часть процесса отправки сообщения. Поле заголовка сообщения Received применяется в следующем формате.The Replay directory adds its own Received message header field to a message as part of the message submission process. 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:

  • Код сообщения Если это поле заголовка сообщения отсутствует или пуст, каталога преобразования добавляет поле заголовка сообщения идентификатор сообщения, используя формат * <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.

В началоReturn to top

Сбои при обработке сообщений в каталоге раскладки и преобразования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:

  • Сбои доставки   Если правильно отформатированный файл сообщения с допустимым отправителем не удается доставить, создается отчет о недоставке. Неправильный формат содержания или нарушения ограничений сообщений каталога раскладки могут также стать причиной создания отчета о недоставке. Если отчет о недоставке создается в процессе обработки сообщения, в сообщение отчета вкладывается исходный файл сообщения, который после этого удаляется из каталога раскладки или каталога преобразования.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 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.

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

    Примечание

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

В началоReturn to top

Вопросы безопасности, связанные с каталогами раскладки и преобразования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-заголовков, используемых каталога преобразования разрешить создание вручную конверт сообщения. Сведения, приведенные в X-Sender и X-Receiver поля могут быть полностью отличается от To или From сообщения заголовок поля, отображаемые с клиентами электронной почты. Спуфингчасто называется таких олицетворение отправителя и домена. Подложный почты — это сообщение электронной почты, содержащее адрес отправителя, который был изменен отображаться как если бы он исходит от отправителя, фактический отправитель сообщения.The X-Headers used by the Replay directory allow for the manual creation of the message envelope. 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, назначение считается надежности и брандмауэр заголовков не будет применено. Заголовок брандмауэра — это способ Exchange сохранить X-заголовков в сообщения, передаваемые между доверенные серверы Exchange или для удаления потенциально раскрытия X-заголовков из сообщения передаются ненадежные получателям за пределами организации Exchange. X-заголовков, которые можно использовать для обмена информацией Exchange, такие как уровень вероятности нежелательной почты (SCL), сообщение для подписи, или шифрование между право серверы Exchange. В этом сведений несанкционированного источников может, представляющих потенциальную опасность безопасности. Дополнительные сведения о брандмауэре заголовка видеть Общие сведения о заголовке брандмауэра.If the X-CreatedBy field has the value of MSExchange15, the destination is considered trustworthy, and header firewall isn't applied. 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. 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.

По умолчанию на всех серверах почтовых ящиков и пограничных транспортных серверах включены каталога раскладки и каталога преобразования. Если каталога раскладки или преобразования не требуется на определенном сервере почтовых ящиков или пограничном транспортном сервере в вашей организации, можно отключить каталога раскладки или преобразования на этом сервере, задав путь каталога раскладки или преобразования путь к каталогу значение $null. Дополнительные сведения содержатся в разделе Настройка каталога раскладки и каталога преобразования.Both the Pickup directory and the Replay directory are enabled by default on all Mailbox servers and Edge Transport servers. 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.

В началоReturn to top

Разрешения для каталогов раскладки и преобразования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. Успех попытки изменить расположение каталога раскладки зависит от прав, предоставленных учетной записи сетевой службы, в новом расположении каталога раскладки, а также от того, существуют ли уже новые каталоги. Если новый каталог не существует, а учетная запись сетевой службы обладает всеми правами для создания папок и применения разрешений к новому местоположению, то создается новый каталог со всеми необходимыми разрешениями. Если новый каталог уже существует, разрешения существующего каталога не проверяются. При перемещении каталогов с помощью параметра 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. 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.

В началоReturn to top