A correctly formatted .eml message file that is copied into the Replay directory is processed for submission in the following steps:

1. The Replay directory is checked for new message files every 5 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-TransportServer cmdlet. The default value is 100 messages per minute. Files that cannot be opened are left in the Replay directory and are reevaluated at the next poll.
   
   
2. 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 Replay process proceeds to the next file.
   
   
3. After the .tmp file is successfully converted into an e-mail message, a "delete on close" command is issued to the .tmp file. The .tmp file appears to remain in the Replay directory, but the file cannot be opened by anyone else.
   
   
4. After the message is successfully queued for delivery, a "close" command is issued, and the .tmp file is deleted from the Replay 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 Replay directory, all .tmp files are renamed as .eml files and are reprocessed. This could lead to duplicate message transmission.
   
   

A standard SMTP e-mail message consists of a message envelope and message content. The message envelope contains information that is required for transmitting and delivering the message. The message content contains message header fields that are 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.

When a sender composes an e-mail message and submits it for delivery, the message contains the basic information that is 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. Recipients never see the message envelope, because it is generated by the message transmission process and is not actually part of the message. Each server that is involved in the transmission of the message may insert message header fields related to the server's role in delivery or other application-specific message header fields into the message header. When the recipient opens the message by using an e-mail client, the e-mail client displays some of the more relevant information from the message header, such as the sender, the recipients, and the subject.

The best analogy for explaining the relationship between the message envelope and the message header is sending conventional mail in a large company. You write a formal business letter with your company's address and the recipient's address in the salutation at the top of the letter. You give the letter to your company's mail room for processing. The mail room personnel create an envelope by using the recipient information in your letter, seal your letter in an envelope, and drop the envelope in the mailbox for delivery. The postal service delivers the envelope to the recipient's company based on the address on the envelope. The mail room personnel at the recipient's company receive the envelope, determine the recipient based on the envelope, open the envelope, and put the letter in the recipient's personal mail box. When the recipient retrieves your letter from their personal mail box, he or she knows, from the information in the salutation, that you wrote the letter and that the letter is for him or her.

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 an administrator or other application 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.

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 are not 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 2007-specific X-Headers that are 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 that is copied into the Replay directory must meet the following requirements for successful delivery:

• The message file must be a text file that complies with the basic SMTP message format. Multipurpose Internet Mail Extensions (MIME) message header fields and content are supported.
  
  
• The message file must have an .eml file name extension.
  
  
• X-Headers must occur before all regular header fields.
  
  
• A blank line must exist between the header fields and the message body.
  
  

The X-Headers that are described in the following list are required by messages in the Replay directory:

• X-Sender:   This X-Header replaces the From: message header field requirement in a typical SMTP message. One X-Sender: field that contains one e-mail address must exist. The Replay directory ignores the From: message header field if it is present, although the recipient's e-mail 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:
  
  

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

  Note:

  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= specifies whether the whole message or only the headers should be returned to the sender if the message cannot 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-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 e-mail address must exist. Multiple X-Receiver: fields are allowed for multiple recipients. The Replay directory ignores the To: message header fields if they are present, although the recipient's e-mail 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:
  
  

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

  Note:
  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= can have a value of NEVER, DELAY, or FAILURE. ORcpt= is used to preserve the original recipient of the message.

The X-Headers that are described in the following list are optional for message files in the Replay directory.

• X-CreatedBy:   If this X-Header exists, it must not be blank. If the X-CreatedBy: field does not exist, it is added with a value of Unspecified. Typically, the value of this field is MSExchange12, but it also may contain the non-SMTP address space type that is set on a Send connector, such as Notes. This message header field is used for header firewall functionality.
  
  
• X-EndOfInjectedXHeaders:   The size in bytes of all the X-Headers that are 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:   Extended message properties for the message.
  
  
• X-HeloDomain:   The HELO/EHLO domain string presented during the initial SMTP protocol conversation.
  
  
• X-LegacyExch50:   Used to preserve custom properties that are generated by Exchange Server 2003 if Exchange 2003 servers are present.
  
  
• X-Source:   If the value of this X-Header is not specified, the value of Replay is used. This X-Header is used by the Queue Viewer under the MessageSourceName column. Other possible values for this X-Header are Smtp Receive Connector and Smtp Send Connector.
  
  
• X-SourceIPAddress:   The IP address of the sending server. This field is 0.0.0.0 if no IP address is specified.
  
  

The following is an example of a plain text message that uses acceptable formatting for the Replay directory:

	Copy Code
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 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. The following is an example of a simple MIME message that uses acceptable formatting for the Replay directory:

Copy Code

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>

The Replay directory deletes the Bcc: message header field from the message file.

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:

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

The Replay directory modifies the following message header fields in the message header:

• 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.
  
  

Any problems converting a message file into an e-mail message causes the Replay directory to consider the message undeliverable (badmail). A badmail message file has serious problems, such as a missing sender, missing recipients, or formatting problems. Message files that are determined to be badmail are left in the Replay directory 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 Replay directory, an event log error is generated, but the same badmail messages do not generate repeated event log errors.

Exchange Server 2003 uses a single Pickup directory for creating and submitting text message files. Exchange 2007 splits this functionality into separate Pickup and Replay directories. The Pickup directory is intended for users or applications to manually create new message files. The Replay directory is intended for the re-submission of exported Exchange e-mail messages and for receiving messages from non-SMTP connectors. This separation of duties allows for the appropriate security to be applied to one directory without affecting the functionality of the other directory.

The following list describes security concerns that are common to the Pickup directory and the Replay directory:

• Any security checks that are configured on a Receive connector, such as anti-spam, antivirus, sender filtering, or recipient filtering actions, are not performed on messages that are submitted through the Pickup directory and the Replay directory at the time of message submission.
  
  
• 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:

• The X-Headers that are 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 that are displayed by e-mail clients. Such an impersonation of a sender and a domain is frequently called spoofing. A spoofed mail is an e-mail 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.
  
  
• If the X-CreatedBy: field has the value of MSExchange12, the destination is considered trustworthy, and a header firewall is not applied. A header firewall is a way for Exchange to preserve X-Headers in messages that are transmitted between trusted Exchange 2007 servers or to remove potentially revealing X-Headers from messages that are transmitted to untrusted destinations outside the Exchange organization. These X-Headers can be used to share Exchange 2007 information such as spam confidence level (SCL), message signing, or encryption between authorized Exchange 2007 servers. Revealing this information to unauthorized sources could pose a potential security risk.
  
  

The separation of the Pickup directory and the Replay directory means you can apply different levels of security to each directory. Tighter security should be applied to the Replay directory because of the additional security risks that are associated with the Replay directory. Users or applications that must generate and submit new messages can be granted access to the Pickup directory, and should not need access to the Replay directory.

The following permissions are required on the Replay directory:

• Administrator: Full Control
  
  
• System: Full Control
  
  
• Network Service: Read, Write, and Delete Subfolders and Files
  
  

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 Replay directory. The Network Service account requires these permissions on the Replay directory so that .eml files can be opened, renamed to .tmp and deleted, or renamed to .bad if the message is classified as badmail.

You can move the location of the Replay directory by using the ReplayDirectoryPath parameter on the Set-TransportServer cmdlet. Successfully changing the location of the Replay directory depends on the rights that are granted to the Network Service account at the new Replay directory and whether the new Replay directory already exists. If the new Replay directory does not already exist, and the Network Service account has the rights that are required to create folders and apply permissions at the new location, the new Replay directory is created, and the correct permissions are applied to it. If the new Replay directory already exists, the existing folder permissions are not checked. Whenever you move the Replay directory by using the ReplayDirectoryPath parameter with the Set-TransportServer cmdlet, it is always a good idea to verify that the new Replay directory exists and that the new directory has the correct permissions applied to it. If your change to the Replay directory is not successful, you can create the new Replay directory and apply the correct permissions to it before you use the ReplayDirectoryPath parameter with the Set-TransportServer cmdlet.

For more information, see the following topics:

• How to Configure the Replay Directory
  
  
• Managing the Replay Directory
  
  
• Set-TransportServer