1. Using DNS to Route SMTP Mail in Exchange Server 2007
The primary protocol for sending email on the
Internet today is known as Simple Mail Transfer Protocol, or SMTP. SMTP
has been used for quite some time in UNIX and Linux environments, and
has been incorporated into Active Directory as an alternative transport
mechanism for site traffic.
Domains that want to participate in electronic
mail exchange need to set up MX record(s) for their published zone. This
advertises the system that will handle mail for the particular domain,
so that SMTP mail will find the way to its destination.
Understanding SMTP Mail Routing
Email is arguably the most widely used TCP/IP
and Internet application today. SMTP defines a set of rules for
addressing, sending, and receiving mail between systems. As a result of a
user mail request, the SMTP sender establishes a two-way connection
with the SMTP receiver. The SMTP receiver can be either the ultimate
destination or an intermediate (mail gateway). The SMTP sender generates
commands that are replied to by the receiver. All this communication
takes place over TCP port 25. When the connection is established, a
series of commands and replies are exchanged between the client and
server. This connection is similar to a phone conversation, and the
commands and responses are equivalent to verbal communication.
Note
In
various implementations, there is a possibility of exchanging mail
between the TCP/IP SMTP mailing system and the locally used mailing
systems. These applications are called mail gateways or mail bridges.
Sending mail through a mail gateway may alter the end-to-end delivery
specification because SMTP guarantees delivery only to the mail gateway
host, not to the real destination host, which is located beyond the
TCP/IP network. When a mail gateway is used, the SMTP end-to-end
transmission is host-to-gateway, gateway-to-host, or gateway-to-gateway;
the behavior beyond the gateway is not defined by SMTP.
Examining Client DNS Use for Exchange
Before users can access their mailboxes on an
Exchange server, they must be authenticated. Authentication requires a
DNS lookup to locate a domain controller on which the users’ accounts
can be authenticated.
Clients normally cannot deliver messages
directly to destination mail hosts. They typically use a mail server to
relay messages to destinations. Using SMTP, clients connect to a mail
server, which first verifies that the client is allowed to relay through
this server, and then accepts the message destined for other domains.
A client uses DNS to resolve the name
of a mail server. For example, when configuring an Outlook mail client
to connect to an Exchange server, only the short name and not the FQDN
is used to connect to the server. The short name is resolved by DNS to
the FQDN of the Exchange server to which the client is connected.
2. Understanding DNS Requirements for Exchange Server 2007
In Active Directory, all client logons and
lookups are directed to local domain controllers and GC servers through
references to the SRV records in DNS. Each configuration has its DNS and
resource requirements. Exchange relies on other servers for client
authentication and uses DNS to find those servers. In an Active
Directory domain controller configuration, on the other hand, the
Exchange server also participates in the authentication process for
Active Directory.
Using DNS in Exchange Server 2007
As has been stated, Active Directory and DNS
access are vital to an Exchange implementation. It is critical that the
host records for all Exchange 2007 servers be properly registered and
configured in the domain name system (DNS) server for the Active
Directory forest. Clients, as well as other servers, will use DNS to
locate and communicate with Exchange 2007 servers.
Any computer acting in one of the Exchange 2007
organizational server roles must be domain members and registered in
DNS. The five server roles are as follows:
Edge Transport
Hub Transport
Mailbox
Client Access
Unified Messaging
All server roles, with the exception of the Edge
Transport, can be deployed on a single server. Although there are five
roles listed, only the Hub Transport and Mailbox server roles are
required for a minimal Exchange 2007 installation.
Configuring Edge Transport Server DNS Settings
For the Edge Transport server(s), which reside
in the perimeter network, to communicate with the Hub Transport servers
in your Exchange environment, they must be able to locate each other
using host name resolution. This is accomplished by creating host
records in a forward lookup zone on the internal DNS server that each
server is configured to query, or by editing the local Hosts file for
each server.
Before installing the Edge Transport server
role, you have to configure a DNS suffix for the server name. After you
have installed the Edge Transport server role, the server name cannot be
changed.
To complete this task, you must log on to the Edge Transport server as a user who is a member of the local Administrators group.
To use Windows Control Panel to configure the DNS suffix, complete the following steps:
1. | Open Windows Control Panel
|
2. | Double-click on System to open the System Properties dialog box.
|
3. | Click the Computer Name tab.
|
4. | Click Change.
|
5. | On the Computer Name Changes page, click More.
|
6. | In the Primary DNS Suffix of This Computer field, type a DNS domain name and suffix for the Edge Transport server.
|
DNS and SMTP RFC Standards
In 1984, the first DNS architecture was
designed. The result was released as RFC 882 and 883. These were
superseded by RFC 1034 (Domain Names—concepts and facilities) and 1035
(Domain Names—implementation and specification), the current
specifications of the DNS. RFCs 1034 and 1035 have been improved by many
other RFCs, which describe fixes for potential
DNS security problems, implementation problems, best practices, and
performance improvements to the current standard.
RFC 2821 defines the SMTP, which replaced the earlier versions of RFC 821 and 822.
Interoperability with Older Versions of Exchange
Exchange 2007 can be deployed in an existing
Exchange 2000 Server or Exchange Server 2003 organization, as long as
the organization is operating in Native mode. This interoperability is
supported; however, there are many differences between the older systems
and the newer, especially in how the servers are administered and how
server-to-server communication occurs.
Understanding Mixed Exchange Environments
For Exchange 2007 to communicate properly with
Exchange 2000 or Exchange 2003, the routing group connectors between the
Exchange 2007 Hub Transport servers and the older bridgehead servers
must be configured correctly. When you install an Exchange 2007 server
into an existing organization, the server is recognized by the Exchange
2000 Server or Exchange Server 2003 organization. However, because
server-to-server communications differ greatly, you must configure
routing group connectors to let the different versions communicate and
transfer messages. This is because of the fact that Exchange 2000 Server
and Exchange Server 2003 used SMTP as the primary communication
protocol between Exchange servers, but in Exchange 2007, the server
roles use remote procedure calls (RPCs) for server-to-server
communication and allow the Hub Transport server to manage the transport
of SMTP traffic.
Routing in Exchange Server 2007
Although Exchange 2000 Server and Exchange
Server 2003 use routing groups to define the Exchange routing topology,
Exchange 2007 uses Active Directory sites to do so, so an
Exchange-specific routing configuration is no longer needed in a pure
Exchange 2007 organization.
For the two routing topologies to coexist, all
Exchange 2007 servers are automatically added to a routing group when
the server is installed. This Exchange 2007 routing group is recognized
in the Exchange System Manager for Exchange 2000 and 2003 as an Exchange
Routing Group within Exchange Administrative Group.
For Exchange 2007 to coexist with Exchange 2000 Server or Exchange Server 2003, you need to perform the following tasks:
Note
The first routing group connector is created
during installation of the first Hub Transport server when installed in
an existing Exchange organization.
These connectors allow mail to be routed from Exchange 2000 Server or Exchange Server 2003 to Exchange 2007.
SMTP Mail Security, Virus Checking, and Proxies
Spamming and security issues are daily concerns
for email administrators. As the Internet grows, so too does the amount
of spam that mail servers have to confront. Unwanted messages not only
can take up a lot of space on mail servers, but can also carry dangerous
payloads or viruses. Administrators have to maintain a multilayered
defense against spam and viruses.
There are several security areas that have to be addressed:
Gateway security to control access to the mail server delivering messages to/from the Internet
Mail database security where messages are stored
Client mail security where messages are opened and processed
Gateway security is a primary concern for
administrators because a misconfigured gateway can become a gateway used
by spammers to relay messages. Unauthenticated message relay is the
mechanism spammers rely on to deliver their messages. When a server is
used for unauthenticated message relay, it not only puts a huge load on
server resources, but also might get the server placed on a spam list.
Companies relying on spam lists to control their incoming mail traffic
refuse mail delivered from servers listed in the database; therefore,
controlling who can relay messages through the mail relay gateway is a
major concern.
Application-level firewalls such as Microsoft
Internet Security and Acceleration (ISA) Server 2006 allow mail proxying
on behalf of the internal mail server. Essentially, mail hosts trying
to connect to the local mail server have to talk to the proxy gateway,
which is responsible for relaying those messages to the internal server.
Going one step further, these proxy gateways can also perform
additional functions to check the message they are relaying to the
internal host or to control the payload passed along to the internal
server.
This configuration is also helpful in stopping
dangerous viruses from being spread through email. For example,
dangerous scripts could potentially be attached to email, which could
execute as soon as the user opens the mail. A safe configuration allows
only permitted attachment types to pass through. Even those attachments
have to pass virus checking before they are passed to an internal mail
server.
The following process describes how one server contacts another server to send email messages that include virus checking:
1. | The sender contacts its SMTP gateway for message delivery.
|
2. | The
SMTP gateway looks up the MX record for the recipient domain and
establishes communication with it. The application proxy acting as the
SMTP server for the recipient’s domain receives the message. Before the
recipient gateway establishes communication
with the sender gateway, it can check whether the sender SMTP gateway
is listed on any known spam lists. If the server is not located on any
spam lists, communication can resume and the message can be accepted by
the proxy server.
|
3. | The application proxy forwards the message for virus checking.
|
4. | After virus checking, the mail is routed back to the application proxy.
|
5. | Mail is delivered to the internal SMTP gateway.
|
6. | The recipient picks up the mail message.
|
Note
Application proxy and virus or spam checking might be done within the same host. In that case, steps 2–5 are done in one step without having to transfer a message to a separate host.
Third-party products can be used for virus
checking not only at the gateway level, but also directly on an Exchange
email database. Database-level scans can be scheduled to run at night
when the load is lower on the server; real-time scans can perform virus
checking in real time before any message is written to the database.
The final checkpoint for any multilayered virus
protection is on the workstation. The file system and the email system
can be protected by the same antivirus product. Messages can be scanned
before a user is able to open the message or before a message is sent.
Protecting email communications and message
integrity puts a large load on administrators. Threats are best dealt
with using a multilayered approach from the client to the server to the
gateway. When each step along the way is protected against malicious
attacks, the global result is a secure, well-balanced email system.
The Edge Transport Servers Role in Antivirus and Antispam Protection
In Exchange 2007, the introduction of the Edge
Transport server role was brought about by the increased need to protect
organizations from unwanted message traffic. The Edge Transport server
is designed to provide improved antivirus and antispam protection for
the Exchange environment. This server role also applies policies to
messages in transport between organizations. The Edge Transport server
role is deployed outside the Active Directory forest in the perimeter
network and can be deployed as a smarthost and SMTP relay server for an
existing Exchange Server 2007 organization.
Actually, you can add an Edge Transport server
to any existing Exchange environment without making any other
organizational changes or upgrading the internal Exchange servers. There
are no preparation steps needed in Active Directory to install the Edge
Transport server. If you are currently using the antispam capabilities
of the Intelligent Message
Filter in Exchange Server 2007, you can still use the Edge Transport
server as an additional layer of antispam protection.
SMTP Server Scalability and Load Balancing
In a larger environment, administrators might
set up more than one SMTP server for inbound and/or outbound mail
processing. Windows Server 2003 and Exchange Server 2007 provide a very
flexible platform to scale and balance the load of SMTP mail services.
DNS and Network Load Balancing (NLB) are key components for these tasks.
Administrators should not forget about hardware
failover and scalability. Multinetwork interface cards are highly
recommended. Two network cards can be teamed together for higher
throughput, can be used in failover configuration, or can be
load-balanced by using one network card for front-end communication and
another for back-end services, such as backup.
Network design can also incorporate fault
tolerance by creating redundant network routes and by using technologies
that can group devices together for the purpose of load balancing and
delivery failover. Load balancing is the process where requests can be
spread across multiple devices to keep individual service load at an
acceptable level.
Using NLB, Exchange Server SMTP processes can be
handed off to a group of servers for processing, or incoming traffic
can be handled by a group of servers before it gets routed to an
Exchange server. The following example outlines a possible configuration
for using NLB in conjunction with Exchange.
DNS, in this example, has been set up to point
to the name of the NLB cluster IP address. Externally, the DNS MX record
points to a single mail relay gateway for companyabc.com.
Exchange server uses smarthost configuration to send all SMTP messages
to the NLB cluster. The NLB cluster is configured in balanced mode where
the servers share equal load. Only port 25 traffic is allowed on the
cluster servers. This configuration would off-load SMTP mail processing
from the Exchange servers because all they have to do is to pass the
message along to the cluster for delivery. They do not need to contact
any outside SMTP gateway to transfer the message. This configuration
allows scalability because when the load increases, administrators can
add more SMTP gateways to the cluster. This setup also addresses load
balancing because the NLB cluster is smart enough to notice whether one
of the cluster nodes has failed or is down for maintenance. An
additional ramification of this configuration is that message tracking
will not work beyond the Exchange servers.
Note
Administrators should not forget about the
ramifications of antivirus and spam checking software with NLB. These
packages in Gateway mode can also be used as the SMTP gateway for an
organization. In an NLB clustered mode, an organization would need to
purchase three sets of licenses to cover each NLB node.
A
less used but possible configuration for SMTP mail load balancing uses
DNS to distribute the load between multiple SMTP servers. This
configuration, known as DNS round-robin, does not provide as robust a
message routing environment as the NLB solution.
