configuring exchange 2007 send connectors

7/29/2019 Configuring Exchange 2007 Send Connectors

1/21

Configuring Exchange 2007 SendConnectors

A lot of Exchange administrators are surprised to learn that in mostcases 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 routedthrough 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 edgetransport 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 usedto 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 | HubTransport. 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 thatconveys 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 theintended use for the send connector that you're creating. Since our


2/21

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 specifythe 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.
http://www.petri.co.il/images/Configuring-Exchange-2007-Send-Connectors-1.jpg


3/21

Figure B Enter an asterisk into the Address field.

Click Next, and you will see a screen asking you if you want to useDNS MX records to route the outbound SMTP mail automatically, or ifyou 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.


4/21

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 connectorshould be displayed within the Exchange Management Console, as

shown in Figure D.


5/21

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 ourExchange Server Forums!

Configuring Exchange 2007 as anAuthenticated or Anonymous SMTP Relay

Scenario

By default Exchange 2007 is configured to only accept SMTP email fordomains it is authoritative for, and will only relay email onto other

domains for authenticated local users. Usually for Outlook/OWA basedclients 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.
http://www.petri.co.il/forums/forumdisplay.php?f=4http://www.petri.co.il/forums/forumdisplay.php?f=4http://www.petri.co.il/forums/forumdisplay.php?f=4http://www.petri.co.il/images/Configuring-Exchange-2007-Send-Connectors-4.jpghttp://www.petri.co.il/forums/forumdisplay.php?f=4


6/21

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 willwant 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 theExchange 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 allauthenticated 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:


7/21

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 theExchange 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 willaccept connections from any remote IP address.


8/21

The only security mechanism available is TLS, which means thisconnector 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 afterstarting TLS" unticked unless you are sure your mail application will

support it - most will not.


9/21

Finally we need to allow our Exchange Users permission to use this

connection so tick the box. Now click "OK" to close the properties andthen 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 yourdomain. Make sure you test this last point because if you have made a

mistake and your connector isnt accepting email then you will notreceive any inbound mail until you fix it!

Anonymous Relays

Apart from providing a solution to supporting authenticated SMTP foryour remote users this method should also give you a better

understanding of how the receive connectors work now. Anothersituation 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


10/21

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 tobeing 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 aswww.mxtoolbox.com.

This time you need to create yourself a new receive connector soreturn 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 allowanonymous relay rights to. Make sure you get this last part right! Now

by default anonymous users do not have the rights to submit email forexternal domains so we need to grant them, and this has to be done

through the Exchange Management Shell. Enter the followingcommand:

Get-ReceiveConnector "connector name" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-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 forgetthe open relay test to be sure!
http://www.mxtoolbox.com/http://www.mxtoolbox.com/http://www.mxtoolbox.com/http://www.mxtoolbox.com/


11/21

Defining an Exchange 2007 E-Mail AddressPolicy, Part 2

If you have done much work with Exchange Server 2003 or Exchange

2000 Server, then you are probably familiar with the concept ofrecipient policies. Recipient policies still exist in Exchange Server 2007,

but they have been broken into two different components; accepted

domains (which I covered inDefining an Exchange 2007 E-MailAddress Policy, Part 1), and E-Mail address policies (Which Im about

to cover). E-mail address policies are the policies that allow you todefine 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 newE-mail address policy. To do so, navigate through the console tree

to Organization Configuration | Hub Transport. Next, clickthe 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 AllRecipient Types setting enabled in most cases. You can see what

this screen looks like in Figure A.
http://www.petri.co.il/defining-exchange-2007-email-address-policy-part-1.htmhttp://www.petri.co.il/defining-exchange-2007-email-address-policy-part-1.htmhttp://www.petri.co.il/defining-exchange-2007-email-address-policy-part-1.htmhttp://www.petri.co.il/defining-exchange-2007-email-address-policy-part-1.htmhttp://www.petri.co.il/defining-exchange-2007-email-address-policy-part-1.htmhttp://www.petri.co.il/defining-exchange-2007-email-address-policy-part-1.htm


12/21

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 onethats shown in Figure B. Even though you have already told the wizard

that you want to apply the policy to all recipient types, this screenallows 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.
http://www.petri.co.il/images/Defining-an-Exchange-2007-E-Mail-Address-Policy-Part-2-1.jpg


13/21

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 E-mail addresses that will be assigned to the users to whom the new E-Mail Address Policy applies. Begin the process by clicking

the Add button. When you do, the wizard will display the SMTP E-Mail Addressesdialog box, shown in Figure C.
http://www.petri.co.il/images/Defining-an-Exchange-2007-E-Mail-Address-Policy-Part-2-2.jpg


14/21

Figure C This is the screen where you actually define the recipients E-

mail 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 LocalPart 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 otheravailable 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 Domainfor 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


15/21

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 policychange effective. In Exchange 2007, the wizards current screen allows

you to make the policy change effective immediately, or to schedulethe 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 addresspolicy.

Configure MX Records for Incoming SMTP E-Mail 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 inRFC 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 isresponsible 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.
http://www.faqs.org/rfcs/rfc1035.htmlhttp://www.faqs.org/rfcs/rfc1035.htmlhttp://www.faqs.org/rfcs/rfc1035.htmlhttp://www.faqs.org/rfcs/rfc1035.html


16/21

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 todeliver 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 ex-

organizational 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, youwill 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 mailserver to the Internet.

Let's say you have the following LAN configuration:


17/21

In the above example you need to give the mail server's IP address as

your MX Record.

Domain name: dpetri.net

Record FQDN Record Type Record Value MX Pref

mail.dpetri.net A 212.143.143.130

dpetri.net MX mail.dpetri.net 10

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.
http://www.petri.co.il/wp-content/uploads/configure-mx-records-for-incoming-smtp-e-mail-traffic_1239681178729.png


18/21


In the above example you need to give the NAT's IP address as your

MX Record.

Domain name: dpetri.net




Note: Make sure you properly configure the NAT device to forward allTCP 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.


19/21

You should then configure the Mail Relay to forward the incoming e-

mail traffic to the real mail server (after scanning it for spam, virusesand so on).


In the above example you need to give the Mail Relay's IP address as your MX Record.Domain name: dpetri.net




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 mailserver and configure it to relay all external mail to the Mail Relay.


20/21

Note: Some networks might use the Internet Router as their NAT

device, and let the Firewall do just that. In those cases, the scenario isa mixture between option #2 (NAT) and this one.

Internal networksAs stated above, there is usually no need to configure MX Records for

internal use, simply because internal (i.e. inter-organization) e-mailand replication traffic is usually controlled via Active Directory-store

information. However there are some cases where you will want toconfigure 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-Relaysand 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 casesince 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 willpay their ISPs some monthly fee and that will buy them storage spaceon 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:



mail.isp.com A 212.143.25.1


dpetri.net MX mail.isp.com 100

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 adifferent IP address (actually, one can use Network Load Balancing -


21/21

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 themail servers, all with the same priority. For example:


maila.dpetri.net A 192.90.1.17

mailb.dpetri.net A 192.90.1.18

mailc.dpetri.net A 192.90.1.19

mail.isp.com A 212.143.25.1

dpetri.net MX maila.dpetri.net 10

dpetri.net MX mailb.dpetri.net 10

dpetri.net MX mailc.dpetri.net 10

dpetri.net MX mail.isp.com 100

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

theSMTP, POP3 and Telnet in Exchange 2000/2003andTest SMTP

Service in IIS and Exchangearticles.

Thanks for reading the article.

Subhash Debnath
http://www.petri.co.il/smtp_pop3_and_telnet.htmhttp://www.petri.co.il/smtp_pop3_and_telnet.htmhttp://www.petri.co.il/test_smtp_service.htmhttp://www.petri.co.il/test_smtp_service.htmhttp://www.petri.co.il/test_smtp_service.htmhttp://www.petri.co.il/test_smtp_service.htmhttp://www.petri.co.il/images/test_mx.gifhttp://www.petri.co.il/test_smtp_service.htmhttp://www.petri.co.il/test_smtp_service.htmhttp://www.petri.co.il/smtp_pop3_and_telnet.htm

configuring exchange 2007 send connectors

Documents