Resolve Anonymous Senders Functionality in Microsoft Exchange 2003

If your Exchange organization contains Microsoft Exchange 2000 Server computers and Microsoft Exchange Server 2003 computers, and you move a user's mailbox from Exchange 2000 to Exchange 2003, when the user whose mailbox is now stored in Exchange 2003 uses Microsoft Outlook to open a message that was sent from an Exchange 2000 user, the e-mail address of the sender is not resolved correctly. The e-mail address appears as a Simple Mail Transfer Protocol (SMTP) address, as in the following example: No more information is available for the e-mail address, even though there is an associated Microsoft Active Directory service account for the sender in the Global Address List.

This behavior occurs when a message is submitted anonymously, such as from the Internet, and the sender of the message has been spoofed. By default, Exchange2003 preserves the original SMTP message submission method and does not resolve the sender's address if the SMTP submission is anonymous. If you want to permit anonymous submissions to be resolved to their respective Global Address List entries, you can use a new function named Resolve anonymous senders in Exchange 2003. This function allows you to resolve mail that is received anonymously by the SMTP virtual server. The Resolve anonymous senders function replaces the ResolveP2 function that is in Exchange 2000.

For more information about the ResolveP2 function in Microsoft Exchange 2000, click the following article number to view the article in the Microsoft Knowledge Base:

If you want to permit anonymous submissions to be resolved to their respective Global Address List entry, you must turn on the Resolve Anonymous E-mail option on the SMTP virtual server. To do so, follow these steps:

1. Click Start, click Programs, point to Microsoft Exchange, and then click System Manager.
2. In System Manager, expand Servers, and then expand the target server.
3. Expand Protocols, and then expand SMTP.
4. Right-click the SMTP virtual server, and then click Properties.
5. In the Properties dialog box, click the Access tab, click Authentication, and then click to select the Resolve anonymous E-mail check box.

Note Microsoft does not recommend that you turn on the Resolve anonymous E-mail option on any Exchange computers that receive mail from the Internet. If you turn on the Resolve anonymous senders option, any user can send anonymous mail through the SMTP server, and the mail message appears to the recipient as authenticated mail. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

This behavior only affects mail that is submitted anonymously. Mail that is submitted through Microsoft Outlook Web Access (OWA), through Distributed Authoring Version (DAV), or through MAPI by using Outlook are all authenticated mail submission methods as in the following examples:

• Authenticated sender: Jane Doe
• Anonymous sender: “Jane Doe” <jdoe@fabrikam.com>

This SMTP functionality is similar to the ResolveP2 function in Exchange 2000. However, in Exchange 2003, the registry settings have been superseded in Exchange 2003. By default, Exchange 2003 preserves the SMTP submission method (anonymous or authenticated) during each server protocol session.

Additionally, Internet border SMTP gateways must accept anonymous connections for mail flow from the Internet. Malicious users can spoof messages at the gateway by imitating the senders address to be a valid user in Active Directory. In Exchange 2003, the anonymous submission of a message is tracked as it traverses the mail servers in an organization.

Note If you turn on the Resolve Anonymous E-mail option, any user can send anonymous mail through the SMTP server and the anonymous mail appears to the recipient as authenticated mail.

Authentication in cross-forest scenarios

To enable cross-forest authentication

To enable cross-forest or inter-organization SMTP authentication, you must create connectors in each forest that uses an authenticated account from the other forest. By doing this, any mail that is sent between the two forests by an authenticated user resolves to the appropriate display name in the Global Address List. This section explains how to enable cross-forest authentication. In this example, there are two forests named OrgA and OrgB.

1. Create an account in the OrgA forest that has Send As permissions. (For all users in the OrgB forest, a contact also exists in the OrgA forest; therefore, this account permits users in the OrgB forest to send authenticated mail.) You must configure the new account with Send As permissions on all Exchange servers in OrgA that will accept incoming mail from the OrgB forest.
2. On an Exchange server that is in the OrgB forest, create a connector that requires authentication using the account that you created in the OrgA forest to send outbound mail.

To set up cross-forest authentication from the OrgA forest to the OrgB forest, repeat these steps to create an account in the OrgB forest and a connector in OrgA forest.

To create a user account in the destination forest with Send As permissions

Before you set up your connector in the connecting forest, you must create an account in the destination forest (the forest that you want to connect to) and give that account Send As permissions. Configure these permissions on all servers that are in the destination forest and that will accept inbound connections from the connecting forest. The procedures below describe how to set up an account in the OrgA forest and a connector in the OrgB forest, this will permit users in the OrgB forest to send mail to the OrgA forest with resolved e-mail addresses.

To create the account used for cross-forest authentication

1. In the destination forest (the OrgA forest), create a user account in Active Directory Users and Computers. This account must be an active account, but it does not require the following permissions:
   • Log on locally
   • Log on through terminal server
2. On each Exchange server object that will accept incoming connections from the connecting forest, configure Send As permissions for this account.
   
   Note Be careful when you create the password policy. If you set the password to expire, make sure that you have a policy rule that changes the password before its expiration date. If the password for this account expires, cross-forest authentication will fail.
   1. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.
   2. In the System Manager console tree, expand Servers, right-click an Exchange server that will accept incoming connections from the connecting forest, and then click Properties.
   3. On the Security tab in the ServerName Properties dialog box, click Add.
   4. In Select Users, Computers, or Groups, add the account that you just created, and then click OK.
   5. On the Security tab, under Group or user names, select the account that you just created.
   6. Under Permissions, click the Allow check box that is next to Send As.

To configure a connector and require authentication for cross-forest authentication

1. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.
2. In the console tree, right-click Connectors, point to New, and then click SMTP Connector.
3. On the General tab, in the Name box, type a name for the connector.
4. Click Forward all mail through this connector to the following smart hosts, and then type the fully qualified domain name or IP address of the receiving Exchange 2003 bridgehead server.
5. Click Add to select a local bridgehead server and an SMTP virtual server to host the connector.
6. On the Advanced tab, click Outbound Security, and then click Integrated Windows Authentication.
7. In Outbound Connection Credentials, specify an account and a password in the Account box, the Password box, and the Confirm password box.
   
   Note The account and password that you specify must meet the following conditions:
   • The account is in the destination forest (OrgA).
   • The account has Send As permissions.
   • The account is an authenticated OrgA account.
   Use the following format for the account name:
   domain\username
   In this format, domain is a domain in the destination forest, and username represents an account in the destination forest that has Send As permissions on all Exchange servers in the destination forest that will accept mail from this connector.