The received message on the next hop may not contain the changes that were made by the "IMailTransportOnPostCategorize::OnMessagePostCategorize" event sink in an RFC2822 P2 header on Exchange 2003

You register an IMailTransportOnPostCategorize::OnMessagePostCategorize event sink that can change messages on Microsoft Exchange Server 2003. For example, you can add a line to the RFC2822 P2 header by using the event sink. Then, if you check the message on the next hop, the modification is successful.

However, consider the following scenario:

• A message is submitted through a MAPI client to the local information store.
• The message cannot be transferred immediately to the next hop because of a retry error.

In this scenario, the message that is received on the next hop does not contain the changes that are made by the event sink when one of the later connection retries is successful.

This problem only occurs when the sending mailbox is located on the computer where the event sink is registered. This problem occurs because the change that is made by the event sink is discarded when the following conditions are true:

• The local store driver submits a message.
• Submission to the next hop fails because of a retry error.

To resolve this problem, use one of the following methods:

• Method 1
  Use a dedicated connector server that does not host any mailboxes. The problem does not occur as long as the sink is not registered on the Mailbox server.
• Method 2
  If you cannot use a dedicated connector server, you must try to avoid the situation where the message goes into retry status immediately after the local store driver submits the message. To do this, make sure that the next hop is always available. Otherwise, in a single-server Exchange organization, follow these steps:
  1. Add an additional IP address to the network adapter.
  2. Configure the default SMTP virtual server to use one of the IP addresses. You must do this because, by default, the configuration for IP addresses for the SMTP virtual server is set to "all unassigned."
  3. Create an additional SMTP virtual server, and then configure it to use the additional IP address that you configured in step 2.
  4. Start the new SMTP virtual server.
  5. Configure the SMTP connector to use the second SMTP virtual server as the local bridgehead.
  By using this configuration, the information store submits the message to the default SMTP virtual server. Because the default SMTP virtual server is not the local bridgehead for the connector, the message is passed to the new SMTP virtual server. If the smart host is unavailable, the message remains in the new virtual server's queue. However, the change is made by the event sink.
  
  Note It is important to start SMTP virtual servers asynchronously because you cannot predict which one will start first if they start automatically. The Exchange store driver always picks the first virtual server that starts and only registers the virtual server to monitor the store's Send Queue. Therefore, you must make sure that the SMTP virtual servers are started in the correct order.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

For more information about the advanced queuing engine, visit the following Microsoft Web site: For more information about SMTP virtual servers, visit the following Microsoft Web site: