Monday, 28 June 2010

Internet Routing

Routing mail throughout your internal infrastructure requires little extra configuration if you rely on your AD topology to do the job. Of course, you must have a well designed AD infrastructure for this to work! As the previous post explained, you may need to adjust your setup to correctly establish just how email is routed if the AD topology favours AD replication and not email routing (hub sites for example).
Routing mail out of your exchange organisation to recipients that don't have internal mailboxes, will NOT WORK by default. Sending and receiving an email to and from a hotmail account for example. This post will show you what configurations are required to get this going.

Part One

Configure Accepted Domains
Exchange will accept email if the domain is configured as an accepted domain. For example, If a hotmail user sends an email to, my exchange server will accept the email and send the message to the Andrew recipient mailbox. The message will only be accepted if is configured as an accepted domain. This would have been configured by default if the AD domain has the same name (this would be a split DNS). Many AD infrastructures use .local as a top level domain name and so in this case, (the Internet registered name) would be added as a accepted domain.
There are three main types of accepted domain:
  • Authoritative
  • Internal relay
  • External relay
In the example just given, is an authoritative domain. The exchange organisation is 'responsible' for this domain and has recipients with this email address.

Relay domains are not part of your exchange organisation. Internal relay domains would result in inbound emails being sent by your exchange server to another by using a send connector based on that domain name. This might be used where exchange is sharing the namespace with another email system. Messages are first sent to your exchange server, if no mailboxes exist then they are sent to a different server linked by a send connector.
An external relay will result in exchange not checking if a mailbox by that domain name exists in the organization. It will send the email to a different server probably in a completely different organization using a send connector. For example, email could arrive at your edge server, get cleaned up then sent by external relay to another organization.
The following cmdlets are used to configure these different accepted domains:

[PS] New-AcceptedDomain -Name " accepted domain" -DomainName -DomainType Authoritative

Different domain types can be used in the above cmdlets. These include the following:

Part Two

External DNS configuration
Another important consideration is to make sure the accepted domain name is registered properly on the Internet. Using perhaps your ISP web site you should create an MX record that references your public IP address. E.g. ..... your public ip address. This might take a while to update.

Part Three

Configure Remote Domains Message Settings
Remote domains are domains outside of your exchange organization, in other words domains that your exchange server is not authoritative for. When your exchange recipients send mail to an external address e.g. a hotmail address a default remote domain configuration is used (unless a more specific remote domain configuration has been made). These remote domains are organization wide (you can see them in the EMC under 'Organization Configration' and 'Hub Transport). There are two settings that can be applied to your remote domains:

1. Out-of-office messages (OOFs)
2. Message format

 Out-of-office messages (OOFs)

As you can see in the above screenprint, OOFs can be set to provide automatic messages on receipt of email informing senders that you are not available. These senders could be internal or external recipients of your organisation. Note however that 'Allow external out-of-office messages only' (the one shown above) applies to messages created by Outlook 2007 (or newer), OWA in Exchange Server 2007/2010 and maked as external. The next option allows all clients (Outlook 2003/2007/2010 and OWA connected to Exchange 2003/2007/2010) to send OOF messages when replying to messages marked as external. The last option allows all clients (Outlook 2003/2007/2010 and OWA connected to Exchange 2003/2007/2010) to send OOF messages when replying to messages marked as internal.

Message Format

Message Format settings can be used where perhaps you dont want automatic replies (or NDRs) to be sent to particular remote domains (maybe domains you dont trust). Spammers can determine whether the email address they send spam to is invalid or not.

Part Four
Configuring Connectors to Send and Recieve Email To/From the Internet

1. Send Connectors

The following describes how to construct a necessary 'Send Connector' that will send Internet bound email from your Hub Transport server (i.e. not using an Edge server). This is not usually recommended. We will discuss the use of Edge servers in part 5.
  1. Open the EMC and browse to the Organisation Confiuguration, Hub Transport node
  2. Select New Send Connector in the Actions pane
  3. Type a name for the connector
  4. Select 'Internet' in the Intended Use For This Send Connector section
  5. In the address space screen, click add and provide a * in the address field
  6. Under network settings, use DNS MX records to route mail automatically
  7. On the source server screen, make sure your Hub Transport server is listed and finish the wizard.
The following script should provide the same configuration:

[PS] new-SendConnector -Name 'Internet' -Usage 'Internet' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false -SourceTransportServers 'EX1'

    2. Receive Connectors

    The following describes how to modify an existing receive connector to allow a Hub Transport server to receive email from the Internet. It is best practice to allow external NAT routers to forward TCP 25 (SMTP) traffic to a Edge server in your DMZ. Without Edge servers, first configure your NAT routers to port forward to a Hub Transport server. Receive connector configuration essentialy involves changing the connectors ACL to allow sending email servers to authenicate anonymously.
    1. Open the EMC and browse to the Server Configuration, Hub Transport node
    2. From the list of Hub Transport servers, select the server that you want to receive Internet mail on.
    3. Select the defualt connector and properties
    4. Select the permissions Groups tab
    5. Select anonymous users and click OK

    Part 5

    Using Edge Transport Servers

    Edge transport servers sit in a perimeter network (in a workgroup outside of your internal AD structure). Its focus is to relay inbound and outbound messages to and from an Exchange Organization while providing message hygiene and security. Because its in a workgroup, it does not have direct contact with AD. To perform its functions, it uses AD Lightweight Directory Services (was called ADAM) which is like a read only copy of AD (at least just part of it). Replication is one way only (from Hub Transport to Edge Server). Only recipient,configuration and topology information required by the Edge server to perform its functions of message relay, message hygiene, anti-spam and use of transport rules are replicated. The MSExchangeEdgeSync service which runs on the Hub Transport server will push AD changes to AD LDS on a scheduled basis.
    The following section will explain how to install and configure an Edge Server:

    1. On a server install the AD LDS role
    2. Make sure the server has a FQDN (of AD domain name)
    3. Add the .NET 3.5.1 feature
    4. Assign the DNS IP address as the internal DNS server (on your DC)
    5. Make sure you create a host record for the edge server on the internal DNS
    6. Install the Edge Server role
    I have found that self-signed certificates are used here. If deleted (perhaps by mistake), Test-Sychronization and Test-Edgesubscription will fail. To overcome this do the following:
    1. On the Hub Transport Get-ExchangeCertificate to identify your certificates
    2. Type New-ExchangeCertificate
    3. Restart the Hub Transport service
    4. If any edge subscriptions and/or send connectors exist on the Hub Transport remove them (no subcriptions will exist if this is a first time configuration!). 
    5. Restart the Hub Transport service again
    6. Remove any existing subscriptions on the Edge server (none should exist)
    7. Create a new subscription file on the Edge server by typing New-EdgeSubscription -FileName "c:\edsub1.xml" 
    8. Copy the file to the Hub Transport server 
    9. On the Hub Transport server browse to Organization Configuration, Hub Transport and on the action menu select New Edge Subscription 
    10. In the wizard define the site and xml file to be used as shown below

    Once the edge subscription has been performed you can try a test. Try the following:

    [PS] Test-EdgeSynchronization

    And then try the following to start the synchronization process

    [PS] Start-EdgeSynchronization

    Another point to consider is to make sure that the "EdgeSync - Inbound to Default-First-Site-Name" send connector is configured correctly. The connector is shown below:

      On the connectors properties, select the network tab as shown

      You should define the IP address of the Hub Transport server as the smart host. Without it mail will go out successfully to the Internet but you will not receive it.

        No comments:

        Post a Comment