Configuring Exchange 2007 Send Connectors

A lot of Exchange administrators are surprised to learn that in most cases a new Exchange Server 2007 deployment is not able to send mail to the outside world until the administrator does some additional configuration. The reason for this is that unless you have installed an Edge transport server, and created an Edge subscription, Exchange Server 2007 does not create a Send connector. As you probably know, hub transport servers use the SMTP protocol to send mail both internally and externally. All SMTP mail is routed through a Send connector. Exchange Server 2007 creates an implicit and invisible send connector that it uses to route mail between hub transport servers on your internal network. The reason why Exchange Server is able to create these implicit Send connectors is because it is able to compute the necessary requirements based on information that is stored in the Active Directory. Unfortunately, Microsoft assumes that you are going to create an edge transport server at your network perimeter. Creating an edge transport server, and the accompanying edge transport subscription, causes Exchange Server to create a Send connector that can be used to transmit SMTP messages to the outside world. Like the implicit Send connectors, this connector is stored in the Active Directory. If you don't have an edge transport server though, then you will have to create the send connector manually.

Creating a Send Connector

Creating a Send connector is a fairly simple task. Begin the process by opening the Exchange Management Console, and navigating through the console tree to Organization Configuration | Hub Transport. Next, click to the New Send Connector link that's found in the Actions pane. Upon doing so, Exchange will launch the New SMTP Send Connector wizard. The first thing that you will have to do is to enter a name for the new Send connector. I recommend using something descriptive that conveys that the send connector will be used to send SMTP mail to the Internet. This screen also contains an option that you can use to specify the intended use for the send connector that you're creating. Since our

goal is to be able to send SMTP mail to the outside world, choose the Internet option from the drop down list, as shown in Figure A.

Figure A Choose the Internet option from the drop down list. Click Next, and you will be taken to a screen that asks you to specify the address space to which the connector will route mail. Since our goal is to send SMTP mail to the Internet, we will use an asterisks in place of an address space. This tells Exchange to send any outbound SMTP mail through this connector (assuming that it isnt destined for a recipient within the Exchange organization). To add the address space, click the Add button, and then enter an asterisk into the Addressfield on the resulting dialog box, as shown in Figure B. Leave the cost at its default value of 1, and click OK.

Figure B Enter an asterisk into the Address field. Click Next, and you will see a screen asking you if you want to use DNS MX records to route the outbound SMTP mail automatically, or if you would prefer to route mail through a smart host. Unless your ISP requires you to use a smart host, you should use the DNS option. Click Next, and you will be taken to the screen that is shown in Figure C. As you can see in the figure, Exchange must bind the send connector to a specific hub transport server in your Exchange organization. By default, Exchange chooses the server that you are creating the connector on, but you do have the option of specifying a different hub transport server.

Figure C Make sure that the correct hub transport server is listed. Once you have verified that the correct hub transport server is listed, click Next, followed byNew. When you do, your new send connector should be displayed within the Exchange Management Console, as shown in Figure D.

Figure D The new send connector is displayed in the console.

Conclusion
In this article, I have explained that unless your Exchange 2007 organization has an edge transport server and an edge subscription, users will not initially be able to send SMTP mail to the outside world. I then went on to show you how to correct this problem by creating a send connector. Got a question? Post it on our Exchange Server Forums!

Configuring Exchange 2007 as an Authenticated or Anonymous SMTP Relay

Scenario
By default Exchange 2007 is configured to only accept SMTP email for domains it is authoritative for, and will only relay email onto other domains for authenticated local users. Usually for Outlook/OWA based clients this is entirely sufficient as even when connecting from remote locations the clients appear to be local to the Exchange Server so it is happy to relay for them. This is thanks to the connection mechanism, Outlook Anywhere and OWA both route the email data through the IIS server, or a user on a VPN will appear to be on the LAN.

This does create a problem if you need to use an alternative mail client that does not support the Outlook web protocols, in which case it will want to use SMTP to send emails. You are most likely to encounter this scenario with non-Windows/Blackberry mobile devices and "cloud" based PIM sync applications like Apple's "MobileMe". The solution is to configure your Exchange 2007 Server to accept authenticated SMTP connections and allow them to relay emails to remote domains - note that "authenticated" is essential otherwise you will turn your server into an "open relay" which will soon be abused by spammers.

Implementation
There are some fundamental differences between the SMTP implementation in Exchange 2003 and 2007 that will leave you very confused if you dont know about them. The main thing is that the Exchange 2007 no longer uses the SMTP service you were familiar with but has replaced it with the Exchange Transport service, which uses "Receive Connectors" and security permissions to define who can do what. "Receive Connectors" are like the SMTP virtual servers of before, they can be defined by the networks allowed to access them, the authentication mechanisms, and the permission groups. By default all authenticated users have full send and receive permissions for all connectors, so you shouldn't have any need to edit specific permissions. Now if you open your Exchange Management Console and navigate to the Server Configuration - Hub Transport section you should see something like this:

Exchange 2007 Receive Connectors

This screenshot is of an SBS2008 server, if you have a standalone Exchange 2007 you will just have two receive connectors - "Default" and "Client", but the principals are the same. The Default connector is configured to allow local network clients to submit email to the Exchange Server, if you check the properties you will see it is restricted to the local network and allows all permission groups except anonymous. We want to change the settings for users connecting from outside our network so we need to look at the "Windows SBS Internet Receive" properties:

As you can see this connector is listening on the local interface and will accept connections from any remote IP address.

The only security mechanism available is TLS, which means this connector will only accept standard unauthenticated SMTP sessions. We want to allow our users to authenticate so we need to tick the "Basic Authentication", but leave "Offer Basic authentication only after starting TLS" unticked unless you are sure your mail application will support it - most will not.

Finally we need to allow our Exchange Users permission to use this connection so tick the box. Now click "OK" to close the properties and then open the Server Manager (click Start, right-click "Computer" and select "Manage"), browse to the "Microsoft Exchange Transport" service and restart it to ensure all the settings are applied. The easiest way to test your new settings is to use Outlook Express (or Windows Mail on Vista) on a remote computer, setup a new account with your server IP/DNS name for the SMTP server. You should be able to email anyone by using the "my server requires authentication" option with just your domain username and password, then if you test without authentication it should only accept emails to users on your domain. Make sure you test this last point because if you have made a mistake and your connector isnt accepting email then you will not receive any inbound mail until you fix it!

Anonymous Relays
Apart from providing a solution to supporting authenticated SMTP for your remote users this method should also give you a better understanding of how the receive connectors work now. Another situation where you may need to use them is to provide an anonymous relay service for internal systems, for example photocopier/scanner units that support basic email but no authentication. Note that you will

only need an anonymous relay if your device needs to email outside your domain - internal emails will not be a problem. An incorrectly configured anonymous relay can leave you open to being used as a email server by spammers, which in turn will get you blacklisted so you can't email anyone anymore. Therefore you should approach with extreme caution and I strongly recommend you test your server with a relay check utility such as www.mxtoolbox.com . This time you need to create yourself a new receive connector so return to your Server Hub Transport section in the Exchange Management Console:

Click "New Receive Connector" to start the wizard and on the first page enter a suitable name, then select "Custom" from the drop-down menu. Configure the connector with the same Authentication settings as before but only "Anonymous Users" allowed, then in the "Network" section just add the IP addresses of the devices you wish to allow anonymous relay rights to. Make sure you get this last part right! Now by default anonymous users do not have the rights to submit email for external domains so we need to grant them, and this has to be done through the Exchange Management Shell. Enter the following command: Get-ReceiveConnector "connector name" | Add-ADPermission User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "msExch-SMTP-Accept-Any-Recipient" Make sure you enter the connector name as it appears in the Management Console and run the command, it should confirm the permission has been added. As before make sure you restart the Transport Service and then test your new connector, and don't forget the open relay test to be sure!

Defining an Exchange 2007 E-Mail Address Policy, Part 2

If you have done much work with Exchange Server 2003 or Exchange 2000 Server, then you are probably familiar with the concept of recipient policies. Recipient policies still exist in Exchange Server 2007, but they have been broken into two different components; accepted domains (which I covered in Defining an Exchange 2007 E-Mail Address Policy, Part 1), and E-Mail address policies (Which Im about to cover). E-mail address policies are the policies that allow you to define an Active Directory users E-mail address.

Creating an E-Mail Address Policy

Now that we have defined our accepted domains, we can create a new E-mail address policy. To do so, navigate through the console tree to Organization Configuration | Hub Transport. Next, click the New E-Mail Address Policy link, found in the Actions pane. When you do, Exchange will launch the New E-Mail Address Policy Wizard. The Wizards initial screen will prompt you to enter a name for the policy that you are creating, and to choose the types of recipients that you want to apply the policy to. I recommend leaving the All Recipient Types setting enabled in most cases. You can see what this screen looks like in Figure A.

Figure A Enter a name for the policy that you are creating, and leave the All Recipient Types option selected. Click Next, and you will be taken to a screen thats similar to the one thats shown in Figure B. Even though you have already told the wizard that you want to apply the policy to all recipient types, this screen allows you to narrow things down and apply the policy only to specific recipients, based on the recipients various attributes. For example, you could use the options on this screen to configure the policy so that it only applies to recipients who reside in a certain state. Of course you could also just leave these conditions blank, and the policy will apply to everyone. When you have made your selections and populated any necessary attribute fields, click Next.

Figure B You can set conditions on the new E-Mail address policy. The next step in the configuration process is to actually define the Email addresses that will be assigned to the users to whom the new EMail Address Policy applies. Begin the process by clicking the Add button. When you do, the wizard will display the SMTP EMail Addressesdialog box, shown in Figure C.

Figure C This is the screen where you actually define the recipients Email address format. As you can see in the figure, this is the screen where you can actually define the E-mail address format. To define an E-mail address policy, you must begin by verifying that the E-Mail Address Local Part check box is selected. Once you have done that, choose the option that fits the format that you want to use for the E-mail address. For example, you can base the address on the users alias, the users first initial and last name, first name and last initial, or any of the other available choices. The lower portion of the screen gives you the option of either manually specifying a fully qualified domain name (FQDN) or of selecting an accepted domain. Since we have already gone through the trouble of defining an accepted domain, choose the Select Accepted Domain for E-Mail Address option, and then click Browse and select the address that you defined earlier. Click OK, and the address format that you have chosen to use is added to the wizards current screen. If you need to make a change to the address format that you have chosen, you can select the address and click the Edit button. Assuming that everything appears to be OK though, click the Next button, and you will be taken to a screen that asks you when you want to apply the new policy. This is a very welcome change from Exchange Server 2003, because Exchange 2003

relied on the Recipient Update Service, which didnt always work right. When it did work, it sometimes took a really long time to make a policy change effective. In Exchange 2007, the wizards current screen allows you to make the policy change effective immediately, or to schedule the policy change. When you are satisfied with the choices that you have made, click Next, followed by New to create the new E-Mail address policy.

Conclusion
Although creating an E-mail address policy isnt very complicated, the procedure for doing so is quite a bit different from how things were done in previous versions of Exchange. In this article, I have shown you how to work through the new interface to define an E-mail address policy.

Configure MX Records for Incoming SMTP EMail Traffic

How do I configure and test the MX Record for my Internet Domain name? When you want to run your own mail server, and it does not matter what version and make of mail server you're using - as long as the mail server is using SMTP as the e-mail transfer mechanism - you'll need to configure the MX Records for your domain. MX is an acronym for Mail eXchange. MX is defined in RFC 1035. It specifies the name and relative preference of mail servers for the zone. MX is a DNS record used to define the host(s) willing to accept mail for a given domain. I.e. an MX record indicates which computer is responsible for handling the mail for a particular domain. Without proper MX Records for your domain, only internal e-mail will be delivered to your users. External e-mail from other mail servers in the world will not be able to reach your server simply because these foreign servers cannot tell to which server they need to "talk" (or open a connection to) in order to send the mail destined for that domain.

You can have multiple MX records for a single domain name, ranked in preference order. If a host has three MX records, a mailer will try to deliver to all three before queuing the mail. MX Records must be in the following format: domain.com. IN MX 10 mail.domain.com.

The Preference field is relative to any other MX Record for the zone and can be on any value between 0 and 65535. Low values are more preferred. The preferred value is usually 10 but this is just a convention, not a thumb rule. Any number of MX Records may be defined. If the host is in the domain it requires an A Record. MX Records do not need to point to a host in the same zone, i.e. an MX Record can. point to an A Record that is listed in any zone on that DNS or any other DNS server.

External and Internet-connected networks

When connecting your mail server to the Internet (or to another exorganizational mailing system that uses SMTP) you must always make sure that the rest of the world can successfully resolve your domain's MX Record. Failing to do so will cause e-mail traffic not to be delivered to you. In order to properly configure your domain's MX Record you should contact your ISP (Internet Service Provider) or the party responsible for hosting your DNS Domain name. They will ask you for your FQDN (Fully Qualified Domain Name) and IP address of your mail server. Make sure you know them. When your mail server is connected directly to the Internet In cases where no NAT (Network Address Translation) is being used and where your mail server is directly connected to the Internet, you will need to provide them with the FQDN and IP address of your mail server. Note: This is, by far, the least secure method for connecting a mail server to the Internet. Let's say you have the following LAN configuration:

In the above example you need to give the mail server's IP address as your MX Record. Domain name: dpetri.net
Record FQDN mail.dpetri.net dpetri.net Record Type A MX Record Value 212.143.143.130 mail.dpetri.net 10 MX Pref

You should make sure the ISP has had all the necessary routing tables updated in order to provide Internet availability to your internal IP network range. Note: It doesn't matter if the real host name of the mail server is NOT "mail". Internet hosts don't mind that, they just need to know what's the name of the mail server, and what's the IP address for that name. When NAT is being used In cases where NAT (Network Address Translation) is being used you will need to provide them with the IP address of your external NAT interface, and configure your NAT device with Static Mapping for TCP Port 25, and have all TCP Port 25 traffic forwarded to the internal IP address of your mail server.

Let's say you have the following LAN configuration:

In the above example you need to give the NAT's IP address as your MX Record. Domain name: dpetri.net
Record FQDN mail.dpetri.net dpetri.net Record Type A MX Record Value 192.90.1.1 mail.dpetri.net 10 MX Pref

Note: Make sure you properly configure the NAT device to forward all TCP Port 25 traffic to 192.168.0.10. When a Mail Relay is being used In cases where you have a DMZ (Demilitarized Zone) with a Mail Relay host (i.e. Linux, Windows 2000/2003 + IIS and SMTP, a dedicated appliance and so on) you will need to provide the FQDN and IP address of your Mail Relay machine, and configure the Firewall to only allow TCP Port 25 traffic to be sent to the Mail Relay's IP address, not to your real mail server.

You should then configure the Mail Relay to forward the incoming email traffic to the real mail server (after scanning it for spam, viruses and so on). Let's say you have the following LAN configuration:

In the above example you need to give the Mail Relay's IP address as your MX Record.

Domain name: dpetri.net

Record FQDN mail.dpetri.net dpetri.net Record Type A MX Record Value 192.90.1.17 mail.dpetri.net 10 MX Pref

Note: Make sure you properly configure the Firewall device to forward all TCP Port 25 traffic to 192.90.1.17, and to allow 192.90.1.17 to send TCP Port 25 traffic to your internal mail server at 192.168.0.10. Also, make sure you let the internal mail server communicate only with the Mail Relay device and that you set up an SMTP Connector on the mail server and configure it to relay all external mail to the Mail Relay.

Note: Some networks might use the Internet Router as their NAT device, and let the Firewall do just that. In those cases, the scenario is a mixture between option #2 (NAT) and this one.

Internal networks
As stated above, there is usually no need to configure MX Records for internal use, simply because internal (i.e. inter-organization) e-mail and replication traffic is usually controlled via Active Directory-store information. However there are some cases where you will want to configure internal MX Records. While these MX Records will generally not cause any harm even if you configure them without actually needing them, you must pay close attention to various configuration issues, especially when Mail-Relays and Smart-Hosts are involved. Therefore I cannot say for sure if configuring non-necessary MX Records will cause any problems to your local network. If you do not know for sure (and this might be the case since you've bothered to read this article in the first place) I suggest you consult a network specialist before doing any changes.

Fault Tolerance
In case your mail server fails you'd like to still be able to receive incoming e-mail messages. Most small to medium sized companies will pay their ISPs some monthly fee and that will buy them storage space on the ISPs mail servers. For that to happen, a new MX Record will be added to their DNS information, pointing to the ISPs mail server with a higher priority. For example:
Record FQDN mail.dpetri.net mail.isp.com dpetri.net dpetri.net Record Type A A MX MX Record Value 192.90.1.17 212.143.25.1 mail.dpetri.net mail.isp.com 10 100 MX Pref

Load Balancing
Medium to large sized companies will want to configure some load balancing features for their incoming mail servers. For that to happen, the company must set up a number of mail servers, each one with a different IP address (actually, one can use Network Load Balancing -

NLB, or even clustering but that's a topic for a different article). Then new MX Records will be added to their DNS information, pointing to the mail servers, all with the same priority. For example:
Record FQDN maila.dpetri.net mailb.dpetri.net mailc.dpetri.net mail.isp.com dpetri.net dpetri.net dpetri.net dpetri.net Record Type A A A A MX MX MX MX Record Value 192.90.1.17 192.90.1.18 192.90.1.19 212.143.25.1 maila.dpetri.net mailb.dpetri.net mailc.dpetri.net mail.isp.com 10 10 10 100 MX Pref

Testing the MX Record configuration

Testing the MX Record configuration is critical especially when configuring it for the first time with a new ISP you don't know that well and so on. Use NSLOOKUP or DIG or any other DNS querying tool to make sure your records are set straight. Sample screenshot is of an NSLOOKUP test to Microsoft's MX Records:

Also, make sure you can connect to the mail server by using the MX Record information. You can do so by using Telnet, as described in the SMTP, POP3 and Telnet in Exchange 2000/2003and Test SMTP Service in IIS and Exchange articles.
Thanks for reading the article. Subhash Debnath