Using an Exchange 2007 Edge Server as the Mail Relay of an Exchange 2003 Organization (Part 2)

If you would like to be notified of when Rui Silva releases the next part in this article series please sign up to our MSExchange.org Real-Time Article Update newsletter.

If you would like to read the first part in this article series please go to Using an Exchange 2007 Edge Server as the Mail Relay of an Exchange 2003 Organization (Part 1).

Internal Receive Connector from Exchange 2003

Although the default Receive connector on an Edge Transport server can be used to accept e-mail submissions from both the Internet and from the Exchange organization, as a best practice, it is recommended to configure a second Receive connector to separate SMTP traffic and to configure different authentication.

  1. Open the EMC, click Edge Transport, and then in the work pane, click the Receive Connectors tab. In the action pane, click New Receive Connector. On the New SMTP Receive Connector page (Figure 21), type a unique Name for the connector. From the Select the intended use for this connector drop-down list, select Internal, and then click Next.


Figure 21: New SMTP Receive Connector

  1. On the Remote Network settings page (Figure 22), delete the all network ranges entry and click Add. In the Add IP Address(es) of Remote Servers dialog box, type the IP address(es) of the Exchange 2003 bridgehead server(s) that will relay messages to the Edge server. Click OK, and then click Next.


Figure 22: Remote Network settings

  1. On the New Connector page (Figure 23) click New and then, on the Completion page, click Finish.


Figure 23: New Connector summary

1. Create SMTP Connectors on the Exchange 2003 Bridgehead

On the Exchange 2003 server, follow these steps to create an SMTP connector that is configured to relay e-mail through the Edge server:

  1. Open Exchange 2003 System Manager. Expand Administrative Groups and then expand the administrative group that you want to configure. Expand Routing Groups, right-click the Connectors, select New, and then select SMTP Connector. On the General tab (Figure 24), type a unique Name, select Forward all mail through this connector to the following smart hosts, and type the IP address or FQDN of the Edge Transport server. Click Add and in the Add Bridgehead dialog box, select one or more Exchange 2003 servers that will act as bridgeheads for this connector.


Figure 24: Exchange 2003 SMTP Connector General tab

  1. Select the Address Space tab (Figure 25), click Add and in the Add Address Space dialog box, select SMTP and click OK. On the Internet Address Space Properties page, enter ¡°*¡± for the Address and a Cost of 10. Click OK twice to close the SMTP connector properties page.


Figure 25: Exchange 2003 SMTP Connector Address Space tab

Now that the Internal Receive Connector on the Edge server and the SMTP Connector on the Exchange 2003 bridgehead are created, we can choose what the authentication method will be:

  • Basic Authentication over TLS ¨C requires the creation of a local account on the Edge server and then granting that account permissions on the Internal Receive connector.

  • Anonymous Access ¨C requires the removal of the authentication methods on the Internal receive connector.

2. Internal Receive Connector with Basic Authentication over TLS

  1. The Edge Transport server, create the credentials that are used by the Exchange 2003 server to authenticate when sending e-mail. Create a user account in the Users folder in the Local Users and Groups container on the Edge Transport server (Figure 26).


Figure 26:New local user

  1. Modify the authentication method that is used for this Receive connector. Open the Exchange Management Console (EMC). Locate the Receive connector that you want to modify, and then in the Actions pane, click Properties. Click the Authentication tab. Select Basic Authentication and Offer Basic authentication only after starting TLS (Figure 27). Click OK.


Figure 27: Receive Connector Authentication settings

  1. Run the following command in the Exchange Management Shell to grant permissions on the new Receive connector to the local user account previously created:
    Add-AdPermission -Identity “Internal Receive Connector [from Exchange 2003]” -User E2K7EDGE\E2K3Auth -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-Accept-Headers-Routing,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-SMTP-Accept-Authoritative-Domain-Sender


Figure 28: Add-AdPermission

  1. Next, go back to the Exchange 2003 bridgehead server. On the Exchange 2003 SMTP Connector Properties, select the Advanced tab, and click Outbound Security. In the Outbound Security dialog box (Figure 29), select Basic Authentication, and then click Modify. In the Outbound Connection Credentials dialog box, enter the user name and password for the Edge Transport server local user account and then click OK. On the Outbound Security dialog box, select TLS encryption. Click OK twice.


Figure 29: SMTP Connector Outbound Security

3. Internal Receive Connector with Anonymous Access

To use Anonymous access, we have to modify the authentication method that is used for the Receive connector. 

  1. Open the EMC on the Edge server. Locate the Receive connector that you want to modify, and then in the Actions pane, click Properties. Click the Authentication tab (Figure 30). Make sure the only authentication method selected is Externally Secured (for example with IPsec) and then click OK.


Figure 30: Receive Connector Authentication settings

4. Configure MX Record

The final configuration step is to configure the Edge Transport server to accept the incoming SMTP connections to the organization. This can be accomplished by modifying the DNS MX records to direct mail for your SMTP domains to the Edge server. If there is a firewall or some other security equipment between the Edge server and the Internet, maybe all that is necessary is to edit firewall rules or make any other configuration change so that e-mail to your accepted domains is correctly routed.

But first, you may consider doing some tests…

Testing

Before putting the newly configured Edge server in production and changing the MX record, it might be a good idea to test it first. By now, there should be 4 connectors configured (Figure 31):

  • Default Receive Connector: used to receive mail from the Internet

  • Internal Receive Connector: used to receive mail from the Exchange 2003 Organization

  • Internet Send Connector: used to send mail to the Internet

  • Internal Send Connector: used to relay the incoming Internet mail to the Exchange 2003 Organization


Figure 31: Edge Connectors

Tip:
During the tests, you should disable the anti-spam features of both the Edge server (Content Filtering) and the Exchange 2003 bridgehead (IMF).

Mail flow from the Internet to Exchange 2003

Since probably at this time, the MX record is not yet redirected to the new Edge server, in order to simulate incoming mail we will have to do it the hard way: using SMTP command verbs!

  1. Telnet to the port 25 of the external IP address of the Edge server (where the Default receive connector is listening). Using SMTP command verbs, send a message to an internal user (Figure 32).


Figure 32: Testing using SMTP verbs

  1. To check that the message was successfully delivered, either check the user’s Inbox or find that specific message using the Exchange 2003 Tracking Center (Figure 33).


Figure 33: Message received on the Exchange 2003

Mail flow from Exchange 2003 to the Internet

  1. To check mail flow to the Internet, using an internal mailbox send an e-mail to some outside user (you can do this test, even if your Edge server is not yet connected to the Internet).
  2. Using Exchange 2003 Tracking Center, verify that the message was successfully delivered to the Edge Server (Figure 34).


Figure 34: Message sent to Exchange Edge server

  1. If the Edge server is already connected to the Internet and is capable of delivering mail, check the recipient’s mailbox to see if the message arrived. If the Edge server is not yet capable of sending outside mail, from the Exchange Management Console open the Queue Viewer and find the destination domain where you sent the test message to. Figure 35 depicts 1 pending message for live.com.


Figure 35: Exchange Edge Server Queue

Additional Configuration

There are some additional configuration tasks that you can do, such as configuring anti-spam, anti-virus, transport rules (adding disclaimers, for example) or even allowing application servers to relay off the Exchange 2007 Edge server.

If you have anti-spam settings defined on Exchange 2003 (IMF, sender filtering, block lists, etc.), you can use the Exchange 2007 Anti-Spam Migration Tool to migrate these settings to the Edge Transport server. For further information regarding the utilization of this tool, please read Exchange 2007 Anti Spam Migration Tool.

Troubleshooting

While configuring the Edge server, I got the first error when I was trying to create the Internet Send connector (Figure 36):

You must specify at least one source server.

Exchange Management Shell command attempted:
new-SendConnector -Name ‘Internet Send Connector’ -Usage ‘Internet’ -AddressSpaces ‘SMTP:*;10’ -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false


Figure 36: Error: You must specify at least one source server

The problem occurred because the Exchange Transport service was stopped. Starting the service solved the issue.

Anti-spam

While sending test messages (and maybe afterwards), you can get some messages blocked by the anti-spam features of Exchange Server. You can try do temporarily disable these features to troubleshoot the problem.

For the Edge Server, selectively disable the anti-spam agent filtering.

For the Exchange 2003 bridgehead, unbind the anti-spam features from the SMTP Virtual Server (Figure 37).


Figure 37: Exchange 2003 anti-spam bindings

Message Tracking Center

The Message Tracking Center (Figure 38) is a great tool you can use to find any message in the Exchange 2003 organization.


Figure 38: Message Tracking Center

Protocol Logs

Exchange Servers (2003 and 2007) have lots and lots of logs with useful information. I will not describe all the available options, I will just say that for the purpose of the subject of this article the Protocol Logs can really make a difference. For instance, let us look at the Exchange 2003 logs, available by default in the folder C:\WINDOWS\system32\LogFiles\SMTPSVC1 (some fields were truncated for better reading).

#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2009-04-25 12:40:36
#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken cs-version cs-host cs(User-Agent)
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 EHLO – +E2K7EDGE.mycorp.org 250 0 283 24 0 SMTP – –
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 STARTTLS – – 220 0 0 8 0 SMTP – –
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 STARTTLS – – 220 0 29 8 0 SMTP – –
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 EHLO – +E2K7EDGE.mycorp.org 250 0 327 24 0 SMTP – –
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 MAIL – +FROM:<[email protected]> 250 0 65 48 0 SMTP – –
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 RCPT – +TO:<[email protected]> 250 0 59 35 0 SMTP – –
2009-04-25 E2K7EDGE SMTPSVC1 VM1 0 BDAT – +<[email protected]> 250 0 117 587 157 SMTP – –
2009-04-25 E2K7EDGE SMTPSVC1 VM1 10.10.1.111 0 QUIT – E2K7EDGE.mycorp.org 240 2219 85 4 0 SMTP – –










Can you identify what this portion of the log means? It’s Exchange 2003 receiving that very test message I sent using Telnet and SMTP commands.

But Exchange 2007 also have nice protocol logs, but do not forget to enable the Verbose logging level, in the Properties of the desired connector (Figure 39).


Figure 39:  Protocol logging level

These logs are located in C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\ by default. Let’s look at a portion of the send logs for the same message in the previous log (some fields were truncated):

#Software: Microsoft Exchange Server
#Version: 8.0.0.0
#Log-type: SMTP Send Protocol Log
#Date: 2009-04-25T13:00:47.231Z
#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context
2009-04-25T13:00:47.231Z,0,*,,attempting to connect
2009-04-25T13:00:47.231Z,1,+,,
2009-04-25T13:00:47.247Z,2,<,”220 vm1.virtual.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Sat, 25 Apr 2009 14:00:47 +0100 “,
2009-04-25T13:00:47.247Z,3,>,EHLO E2K7EDGE.mycorp.org,
2009-04-25T13:00:47.262Z,4,<,250-vm1.virtual.com Hello [10.10.1.100],
2009-04-25T13:00:47.262Z,5,<,250-TURN,
2009-04-25T13:00:47.262Z,6,<,250-SIZE,
2009-04-25T13:00:47.262Z,7,<,250-ETRN,
2009-04-25T13:00:47.262Z,8,<,250-PIPELINING,
2009-04-25T13:00:47.262Z,9,<,250-DSN,
2009-04-25T13:00:47.262Z,10,<,250-ENHANCEDSTATUSCODES,
2009-04-25T13:00:47.262Z,11,<,250-8bitmime,
2009-04-25T13:00:47.262Z,12,<,250-BINARYMIME,
2009-04-25T13:00:47.262Z,13,<,250-CHUNKING,
2009-04-25T13:00:47.262Z,14,<,250-VRFY,
2009-04-25T13:00:47.262Z,15,<,250-TLS,
2009-04-25T13:00:47.262Z,16,<,250-STARTTLS,
2009-04-25T13:00:47.262Z,17,<,250-X-EXPS GSSAPI NTLM,
2009-04-25T13:00:47.262Z,18,<,250-AUTH GSSAPI NTLM,
2009-04-25T13:00:47.262Z,19,<,250-X-LINK2STATE,
2009-04-25T13:00:47.262Z,20,<,250-XEXCH50,
2009-04-25T13:00:47.262Z,21,<,250 OK,
2009-04-25T13:00:47.262Z,22,>,STARTTLS,
2009-04-25T13:00:47.262Z,23,<,220 2.0.0 SMTP server ready,
2009-04-25T13:00:47.262Z,24,*,,Sending certificate
2009-04-25T13:00:47.262Z,25,*,CN=E2K7EDGE,Certificate subject
2009-04-25T13:00:47.262Z,26,*,CN=E2K7EDGE,Certificate issuer name
2009-04-25T13:00:47.262Z,27,*,E60C8B2919103D984D2AEAD282D85C3E,Certificate serial number
2009-04-25T13:00:47.262Z,28,*,8F7D14A3ED220AAD5344E1B591FC9941D8D57522,Certificate thumbprint
2009-04-25T13:00:47.262Z,29,*,E2K7EDGE;E2K7EDGE.mycorp.org,Certificate alternate names
2009-04-25T13:00:47.262Z,30,*,,Received certificate
2009-04-25T13:00:47.262Z,31,*,D16428229959D997CF448CE94CFEEB964BBE9578,Certificate thumbprint
2009-04-25T13:00:47.309Z,32,*,Valid,Chain validation status
2009-04-25T13:00:47.309Z,33,*,,SmartHost certificate
2009-04-25T13:00:47.309Z,34,*,CN=vm1.virtual.com,Certificate subject
2009-04-25T13:00:47.325Z,35,*,”CN=My Internal CA, DC=virtual, DC=com”,Certificate issuer name
2009-04-25T13:00:47.325Z,36,*,61107EC0000000000007,Certificate serial number
2009-04-25T13:00:47.325Z,37,*,D16428229959D997CF448CE94CFEEB964BBE9578,Certificate thumbprint
2009-04-25T13:00:47.325Z,38,*,vm1.virtual.com,Certificate alternate names
2009-04-25T13:00:47.325Z,39,>,EHLO E2K7EDGE.mycorp.org,
2009-04-25T13:00:47.466Z,40,<,250-vm1.virtual.com Hello [10.10.1.100],
2009-04-25T13:00:47.466Z,41,<,250-TURN,
2009-04-25T13:00:47.466Z,42,<,250-SIZE,
2009-04-25T13:00:47.466Z,43,<,250-ETRN,
2009-04-25T13:00:47.466Z,44,<,250-PIPELINING,
2009-04-25T13:00:47.466Z,45,<,250-DSN,
2009-04-25T13:00:47.466Z,46,<,250-ENHANCEDSTATUSCODES,
2009-04-25T13:00:47.466Z,47,<,250-8bitmime,
2009-04-25T13:00:47.466Z,48,<,250-BINARYMIME,
2009-04-25T13:00:47.466Z,49,<,250-CHUNKING,
2009-04-25T13:00:47.466Z,50,<,250-VRFY,
2009-04-25T13:00:47.466Z,51,<,250-X-EXPS GSSAPI NTLM LOGIN,
2009-04-25T13:00:47.466Z,52,<,250-X-EXPS=LOGIN,
2009-04-25T13:00:47.466Z,53,<,250-AUTH GSSAPI NTLM LOGIN,
2009-04-25T13:00:47.466Z,54,<,250-AUTH=LOGIN,
2009-04-25T13:00:47.466Z,55,<,250-X-LINK2STATE,
2009-04-25T13:00:47.466Z,56,<,250-XEXCH50,
2009-04-25T13:00:47.466Z,57,<,250 OK,
2009-04-25T13:00:47.481Z,58,>,AUTH LOGIN,
2009-04-25T13:00:47.497Z,59,<,334 <authentication information>,
2009-04-25T13:00:47.497Z,60,>,<Binary Data>,
2009-04-25T13:00:47.497Z,61,<,334 <authentication information>,
2009-04-25T13:00:47.497Z,62,>,<Binary Data>,
2009-04-25T13:00:47.512Z,63,<,235 2.7.0 Authentication successful.,
2009-04-25T13:00:47.528Z,64,*,6,sending message
2009-04-25T13:00:48.794Z,93,>,MAIL FROM:[email protected]> SIZE=969 AUTH=<,
2009-04-25T13:00:48.794Z,94,>,RCPT TO:[email protected],
2009-04-25T13:00:48.794Z,95,<,250 2.1.0 [email protected]….Sender OK,
2009-04-25T13:00:48.966Z,96,<,250 2.1.5 [email protected] ,
2009-04-25T13:00:48.966Z,97,>,BDAT 574 LAST,
2009-04-25T13:00:49.122Z,98,<,250 2.6.0  <[email protected]> Queued mail for delivery,
2009-04-25T13:00:49.450Z,106,>,QUIT,
2009-04-25T13:00:49.450Z,107,<,221 2.0.0 vm1.virtual.com Service closing transmission channel,
2009-04-25T13:00:49.450Z,108,-,,Local













































































Here we can see all the processes involved, such as the certificate exchange, the TLS handshake and then all the necessary SMTP verbs.

Conclusion

Adding the Exchange 2007 Edge server to act as the SMTP relay of an Exchange 2003 organization does not require the upgrade of any internal server and does not require the schema extension of Active Directory. This means you can immediately start taking advantage of the anti-spam, antivirus, and transport rules processing features of a server that was designed to minimize the attack surface.

So, this opens new doors, as a very secure server with all the mail protection mechanisms, designed to live in the perimeter network (DMZ), can now be used with an existing Exchange 2003 organization and practically all the email systems available today.

Related Links

If you would like to be notified of when Rui Silva releases the next part in this article series please sign up to our MSExchange.org Real-Time Article Update newsletter.

If you would like to read the first part in this article series please go to Using an Exchange 2007 Edge Server as the Mail Relay of an Exchange 2003 Organization (Part 1).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top