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

1. The Pickup 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 Pickup directory and are reevaluated at the next poll.
   
   
2. Limits that are 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 KB, and the maximum number of recipients is 100 recipients. You change these limits by using the Set-TransportServer cmdlet.
   
   
3. 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. 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 Pickup directory, but the file cannot be opened by anyone else.
   
   
5. 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.
   
   

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 to the recipient's messaging server. 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 delivering the message 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 together with the message body.

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

A message file that is copied into the Pickup 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.
  
  
• At least one e-mail address must exist in the Sender or From: message header fields in the message header. If a single e-mail address exists in both the Sender and From: fields, the e-mail address in the From: field is used as the originator of the message in the message envelope.
  
  
• Only one e-mail address can ever exist in the Sender field. Multiple e-mail addresses are not allowed. The Sender field is optional if only one e-mail address exists in the From: field.
  
  
• Multiple e-mail addresses are allowed in the From: field, but a single e-mail 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.
  
  
• At least one e-mail address must exist in the To:, Cc:, or Bcc: fields.
  
  
• A blank line must exist between the message header and the message body.
  
  

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

	Copy Code
To: mary@contoso.com From: bob@fabrikam.com Subject: Message subject This is the body of the message.

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

	Copy Code
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>

The Pickup directory removes any of the following message header fields from the message header:

• Received:
  
  
• Resent-*:
  
  
• Bcc:   Any e-mail addresses that are 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.
  
  

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:

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

The Pickup directory modifies the following message header fields if they are missing or malformed:

• 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:   If the Date field is missing or malformed, the Pickup directory adds the date and time of message processing by the Pickup directory.
  
  

A message file that is copied into the Pickup directory 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 by the Pickup directory generates a non-delivery report (NDR). Malformed content or Pickup directory message restriction violations could also cause the Pickup directory to generate an NDR. When an NDR is generated during Pickup directory message processing, the original message file is attached to the NDR message, and the message file is deleted from the Pickup directory.
  
  

  Note:
  A correctly formatted message that is submitted by the Pickup directory 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 that are unrelated to the Pickup directory, such as messaging server failures or routing failures along the delivery path of the message.

• Badmail   A message that is classified as badmail has serious problems that prevent the Pickup directory from submitting the message for delivery. The other condition that causes badmail is when the message is formatted correctly, but the recipients are not valid, and an NDR message can't be sent to the sender because the sender is not valid.
  
  Message files that are determined to be badmail are left in the Pickup 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 Pickup directory, an event log error is generated, but the same badmail messages do not generate repeated event log errors.
  
  

Note:
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 5 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.

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 resubmission of exported Exchange e-mail messages, and for receiving messages from foreign gateway servers.

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 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 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 messages can be granted access to the Pickup directory, but they should not require access to the Replay directory.

Both the Pickup directory and the Replay directory are enabled by default on all Hub Transport servers and Edge Transport servers. If the Pickup directory or the Replay directory are not required on a specific Hub Transport server or Edge Transport server in your organization, you can disable the Pickup directory or the Replay directory on that server. For more information, see the following topics:

• How to Configure the Pickup Directory
  
  
• How to Configure the Replay Directory
  
  

The following permissions are required on the Pickup 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 Pickup directory. 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.

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

For more information, see the following topics:

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