Lesson 1: Managing SMTP Message Transfer Support | MCSA/MCSE Self-Paced Training Kit (Exam 70-284): Implementing and Managing MicrosoftВ® Exchange Server 2003 (Pro-Certification)

SMTP uses SMTP connectors and virtual servers to implement connections, and you can configure SMTP for a variety of environments. SMTP recipients can have a single SMTP address or multiple SMTP addresses. Exchange Server 2003 can segregate recipients into virtual organizations, each with its own SMTP address space.

After this lesson, you will be able to

Explain how an SMTP connection works
Describe common SMTP commands and reply codes
Explain how an ESMTP connection works
Describe common ESMTP commands
Configure DNS to support SMTP
Configure an SMTP connector
Identify methods of troubleshooting SMTP connectivity

Estimated lesson time: 90 minutes

How SMTP Implements a Connection

Note

This lesson gives an overview of SMTP and ESMTP commands but does not describe the contents of SMTP and ESMTP network packets in detail. For more information, refer to Requests for Comments (RFCs) 821, 822, and 1869. RFCs can be found at www.rfc-editor.org/rfc.html.

When an Exchange Server 2003 host communicates with another host, it does so using standard SMTP commands and numerical reply codes over TCP port 25. This communication uses an asymmetric request-response protocol, which simply means that one host sends a command, waits for a reply, and then sends the next command. Suppose that an SMTP client (Host01) sends a message to an SMTP server (Server01). The procedure is as follows:

Host01 initiates a TCP connection to Server01. Server01 returns response 220 (ready), which indicates that it has opened a connection.
Host01 sends a helo command. This requests that an SMTP session be initiated. Server01 returns response 250, which indicates that the requested action is okay and has been completed.
Host01 identifies the sender of the message using the mail from: command. Server01 returns response 250.
Host01 identifies Server01 as the recipient using the rcpt to: command. Server01 returns response 250.
Host01 indicates that it is ready to send the message using the data command. Server01 returns a 354 response, which indicates that the message should start.
Host01 sends the message.
Host01 indicates the end of the session using the quit command. Server01 returns a 221 response, indicating that the SMTP service is closing the connection.

Common SMTP Commands

The SMTP commands define the mail transfer or the mail system function requested by the user. The commands consist of alphabetic character strings terminated by the carriage return/line feed character (<CRLF>). If a command code has parameters, then it is followed by a space character (<SP>), the parameters, and then <CRLF>. Table 10-1 lists the common SMTP commands. This list is not comprehensive. A full list of commands can be found in the RFCs.

Table 10-1: Common SMTP Commands
Command	Description
helo	Requests an SMTP session and identifies the sending SMTP host to the receiving SMTP host. The argument field contains the fully qualified domain name (FQDN) of the sending host.
mail from:	Identifies the sender of the message. This is not necessarily the same as the sending SMTP host; for example, the sending host could be acting as a relay.
rcpt to:	Identifies the message recipient. If there are several recipients, then the command is used for each recipient.
data	Indicates that the sending host is ready to transmit the message.
quit	Indicates the end of the SMTP session.
rset	Aborts the current mail transaction.
quit	Disconnects the TCP session.
vrfy	Allows the sending host to verify that the recipient is valid before sending the message.
turn	Triggers the recipient server to send queued messages destined for the sending server. This command is used in a dial-up environment to poll a host for queued messages.

Common SMTP Reply Codes

Table 10-2 lists the common SMTP reply codes. The commands are text strings, whereas the replies are numbers. However, reply codes 220 and 221 include the FQDN of the receiving host as a parameter. As before, this list is not comprehensive.

Table 10-2: Common SMTP Reply Codes
Reply code	Description
220	Indicates that the SMTP service is ready.
221	Indicates that the SMTP service is closing the transmission channel.
250	Indicates that the requested action is okay and has been completed.
354	Indicates to the sending host that the message should be transmitted.
450	Indicates that the requested action has not been taken because the mailbox is busy.
451	Indicates that the requested action has been aborted due to a local error in processing.
452	Indicates that the requested action has not been taken because there is insufficient system storage.
500	Indicates a syntax error or unrecognized command.
550	Indicates that the requested action has not been taken because the mailbox is unavailable or not found.
552	Indicates that the requested action has been aborted because the storage allocation was exceeded.
554	Indicates that the transaction failed.

How ESMTP Implements a Connection

ESMTP uses the standard SMTP commands and response codes over TCP port 25 but also provides additional capabilities such as delivery notification. ESMTP communication can be made more secure by means of advanced messaging commands that support host authentication and encryption. If an ESMTP host initiates a session with a host that does not support the protocol, then it will use normal SMTP.

Windows 2000 and Windows 2003 operating systems support ESMTP by default. There are also ESMTP clients available for UNIX and Apple Macintosh operating systems.

Let us again suppose that an ESMTP client (Host01) sends a message to an SMTP server (Server01). The procedure is as follows:

Host01 initiates a TCP connection to Server01. Server01 returns response 220 (ready), which indicates that it has opened a connection.
Host01 sends an ehlo command (rather than a helo command). This requests that an ESMTP session be initiated. If Server01 supports ESMTP, then it returns response 250, which indicates that the requested action is okay and has been completed. If, however, Server01 does not support ESMTP, then it returns response 500, indicating that it does not recognize the command.
If Host01 receives response 250, then it continues with the ESMTP session. This is similar to an SMTP session except that the extended commands are available. If, on the other hand, Host01 receives response 500, then it sends an SMTP helo command and starts a normal SMTP session.

Common ESMTP Commands

ESMTP uses the standard SMTP commands (with the exception of helo) and also uses some additional commands. Table 10-3 lists some common ESMTP commands. A more detailed list of ESMTP commands is available in RFC 1869. Further details are given in the additional RFCs listed in the table.

Table 10-3: Common ESMTP Commands
Command	Description
atrn	An authenticated turn command (refer to Table 10-1) that runs only if the session has been authenticated. It is described in RFC 2645.
etrn	This command is similar to turn, but it specifies the remote host to which the mail is to be delivered. It is described in RFC 1985.
pipelining	Allows SMTP commands to be sent in batches without waiting for a response from the receiving host.
chunking	Makes the sending of large Multipurpose Internet Mail Extensions (MIME) messages more efficient by "chunking" data together as it is transported between SMTP hosts.
starttls	Provides a Secure Sockets Layer (SSL) connection between the SMTP client and server by initiating a Transport Layer Security (TLS) connection. The client system must initiate the TLS connection.
auth	Provides a form of Simple Authentication and Security Layer (SASL) SMTP authentication that uses Kerberos and Microsoft's new technology local area network (LAN) manager (NTLM) protocol to authenticate SMTP hosts. The SASL mechanism used is specified in the command parameter.
auth=login	Provides a form of SASL for clients such as Netscape and Exchange Server 5.5 that require basic SMTP authentication.
help	Outputs a list of the commands supported by the SMTP host. It is described in RFC 821.
vrfy	Determines whether an e-mail account exists and whether the account is disabled by default. It is described in RFC 821.
dsn	Generates and sends a delivery status notification to the sending host if there is a delivery failure. The command is considered an improvement on the non-delivery report (NDR) mechanism. It is described in RFC 1891.
size	Determines the size of a message prior to its acceptance. In standard SMTP, a message must be transmitted to the receiving system in whole or in part before it can be rejected for exceeding a size limitation. The command is described in RFC 1870.
x-eps gssapi ntlm login	Uses an authentication mechanism that supports Kerberos and NTLM. It supports the same authentication mechanisms as auth.
x-exps=login	Uses an Exchange Server 5.5–specific authentication mechanism that supports NTLM and provides compatibility with Exchange Server 5.5.
x-link2state	Specifies support for the Exchange 2000 Server link state command verb. For example, it can be used to advertise the fact that a server is capable of exchanging link state information.
xexch50	Used when establishing a connection with another server running Exchange. It is used to transfer Exchange-specific content in messages.

Real World Hazards of Using the vrfy Command

In real-world systems, the vrfy command is often disabled. Many administrators consider it a security risk because it could help a malicious third party determine the identity of enabled e-mail accounts.

Testing an ESMTP Connection

The ehlo command may be used to test connectivity between your Exchange Server 2003 server and a remote SMTP host. If the remote host recognizes the command, then you can authenticate sending and receiving hosts and use encryption. You first establish a connection over TCP port 25 using the telnet utility. On establishing the connection, telnet will indicate whether the remote host supports ESMTP. However, this is not sufficient to indicate that an ESMTP connection can be established. It is possible, for example, that the recipient host is an Exchange server with the System Attendant service stopped. To test ESMTP connectivity, you must then issue the elho command. If you are testing the connection while logged on at another computer (which should be the case in a production network), then you need to follow the command with the FQDN of your server. If the remote host responds with a 250 reply, then it supports ESMTP commands. Figure 10-1 illustrates this technique.

click to expand
Figure 10-1: Testing ESMTP connectivity

You can use the same technique to test standard SMTP connectivity between your server and a remote host. In this case, you should use the helo command rather than the ehlo command.

Exam Tip

You should know that ESMTP is required for facilities such as authentication, encryption, and delivery notification (but not for NDRs), and you should be able to distinguish between the helo and ehlo commands. You should also be able to recognize commands as SMTP or ESMTP and summarize their functions.

SMTP Folders

SMTP uses three system folders to temporarily store messages in transit. By default, these folders are created on an Exchange Server 2003 server in C:\Program Files\Exchsrvr\Mailroot\vsi 1. The folders are as follows:

Pickup SMTP delivers any SMTP formatted messages that are placed in the Pickup folder. Exchange Server 2003 does not use this folder.
Queue SMTP stores inbound SMTP messages in this folder when they are received. Internet Information Services (IIS) then processes these messages for delivery.
Bad Mail SMTP stores undeliverable messages that cannot be returned to the sender in this folder.

If you want to change the location of these folders, you need to make the change in the configuration partition of Active Directory. Otherwise the changes will be overwritten. Use the Adsiedit.exe tool for this purpose.

Configuring DNS to Support SMTP

Having a well-designed DNS service is critical to the operation of an Exchange Server 2003 organization. In a production network, you should ensure that DNS does not constitute a single point of failure by the use of secondary DNS servers, Active Directory Integrated DNS, or both. When an SMTP host sends an e-mail message to another SMTP host, DNS resolves the SMTP domain name of the receiving host to its IP address. SMTP domain names and host addresses are held in DNS Mail Exchanger (MX) records.

Typically, an organization registers multiple MX records in DNS to provide fault tolerance if an SMTP host becomes unavailable. If the recipient SMTP host is unavailable, then the sending SMTP host retrieves all MX records for the receiving domain from DNS and resolves the lowest-preference SMTP host name to an IP address. If the SMTP host with the lowest preference is not available, the SMTP host with the second-lowest preference is used. When an available SMTP host's IP address is resolved, an SMTP session is established with that host.

Exchange recipients can have a single SMTP address or multiple SMTP addresses. Exchange can segregate recipients into multiple virtual organizations, each with its own SMTP address space and domain name. You can configure DNS to support multiple Exchange servers within your organization and implement a single or multiple domain namespaces. Your DNS configuration also depends on how your Exchange organization is connected to the Internet and whether your DNS records are managed internally or by your Internet service provider (ISP).

MX Records for an Organization that Manages Its Own DNS

Table 10-4 shows how you could configure MX records if your organization manages its own DNS and has a single namespace. Host (A) records should exist for Server01, Server02, and Server03.

Table 10-4: MX Records for a Single Namespace
Record	Preference	SMTP host
MX	10	server01.tailspintoys.com
MX	20	server02.tailspintoys.com
MX	30	server03.tailspintoys.com

Tables 10-5 and 10-6 show how you could configure MX records if your organization manages its own DNS and has multiple namespaces. Host (A) records should exist for Server01 and Server02 in both the tailspintoys.com and nwtraders.com namespaces.

Table 10-5: MX Records Added to the tailspintoys.com Namespace
Record	Preference	SMTP host
MX	10	server01.tailspintoys.com
MX	20	server02.tailspintoys.com

Table 10-6: MX Records Added to the nwtraders.com Namespace
Record	Preference	SMTP host
MX	10	server01.nwtraders.com
MX	20	server02.nwtraders.com

MX Records for an Organization Whose ISP Manages Its DNS

Table 10-7 shows how your ISP could configure MX records if your organization has a dial-up connection to the Internet and the ISP manages your organization's DNS. Notice that the ISP's smart hosts are in a load-sharing configuration and have equal preference. Host (A) records for Smarthost01 and Smarthost02 must exist in the ISP's namespace.

Table 10-7: MX Records in an ISP's Namespace for a Dial-Up Connection
Record	Preference	SMTP host
MX	10	smarthost01.yourisp.com
MX	10	smarthost02.yourisp.com

Table 10-8 shows how your ISP could configure MX records if your organization has a permanent connection to the Internet and the ISP manages your organization's DNS. In this configuration, messages will be delivered to the ISP's smart hosts if the connection goes down, and you can retrieve them when the connection is re-established. Host (A) records for Smarthost01 and Smarthost02 must exist in the ISP's namespace, as must a Host (A) record for server01.tailspintoys.com.

Table 10-8: MX Records in an ISP's Namespace for a Permanent Connection
Record	Preference	SMTP host
MX	10	server01.tailspintoys.com
MX	20	smarthost01.yourisp.com
MX	20	smarthost02.yourisp.com

Configuring Internet Connectivity

If you want to change how messages flow in and out of your Exchange organization, you have several options that allow you to control and configure Internet connectivity. These include the following:

Creating and configuring an additional SMTP virtual server and configuring an SMTP connector to use this virtual server as a bridgehead.
Limiting the scope of the SMTP connector to the routing group.
Configuring the credentials on the SMTP connector.
Configuring the SMTP connector only to receive e-mail or only to send e-mail.

Configuring Internet message formats and message delivery parameters.

Exam Tip

You do not need to configure an SMTP connector for e-mail to function. Nor do you need to connect an Exchange server either to other servers in an organization or to the Internet. The default SMTP virtual server manages all these connections. Beware of exam questions that ask what you need to do to implement Exchange Server 2003 connectivity to the Internet. Exchange Server 2003 can connect to the Internet by default.

Creating an Additional SMTP Virtual Server

You can use the default virtual server to configure control filters, relay restrictions, message formats, outbound security, and smart host options. However, if you want to control these items domain by domain, you should create an additional virtual server and then configure an SMTP connector to use the virtual server as a bridgehead server.

When you configure the virtual server in this way, the SMTP connector overrides any settings that the SMTP virtual server and SMTP connector share. You can, for example, create an SMTP connector with an address space for a specific e-mail domain and configure that connector to use a virtual server that does not have any filters configured. This setup can be used for sending messages across an extranet to one of your organization's associate companies. You create and configure an SMTP connector later in this lesson. You should have created an additional SMTP virtual server in Chapter 9.

Limiting the Scope of an SMTP Connector

You can limit the scope of an SMTP connector to a specific routing group. You would do this if you did not want messages from other routing groups to be delivered by the SMTP connector. However, if you want the SMTP connector to act as a backup to other similarly configured SMTP connectors in other routing groups, then you should accept the default scope setting, which is Entire Organization.

Configuring the Credentials on an SMTP Connector

You would configure the credentials on an SMTP connector if, for example, the connector is configured to deliver messages to a domain, and the SMTP server in that domain requires authentication. Configuring connector credentials does not affect the virtual server, which could, for example, be configured with no outbound security. Clients could then connect to other domains anonymously, while authentication is required to connect to the domain where it is specified.

Configuring an SMTP Connector Only to Receive E-Mail or Only to Send E-Mail

Suppose, for example, that your Exchange Server 2003 server cannot perform DNS lookups for Internet addresses, and you want to designate this server as your gateway to the Internet. In this case, you can configure an SMTP connector and then designate a bridgehead server for the connector to use. You also need to configure the connector scope, message routing, and address space.

Configuring Internet Message Formats and Message Delivery Parameters

Internet message formats enable you to configure the encoding, format, and type of messages (such as out-of-office or NDRs) that you send to a specific domain. The domain can then reference a specific destination, such as nwtraders.com. Alternatively, you can use a wildcard, for example *.edu, to reference a large group of destinations. You can define the message format for all SMTP domains or for specific domains.

Note

You can also use the Internet Mail Wizard to create an SMTP connector and to configure an Exchange Server 2003 server to send and receive Internet mail. This wizard is intended primarily for small to medium-sized companies with less complex environments than large enterprise companies. Internet Mail Wizard creates the SMTP connector for outgoing Internet e-mail and then configures the SMTP virtual server to accept incoming e-mail. However, if you have already set up SMTP connectors or created additional SMTP virtual servers on your Exchange Server 2003 server, then you cannot run the wizard unless you reset your server configuration to its default state.

Configuring SMTP Relays

Relaying occurs when one SMTP host forwards SMTP e-mail to another SMTP host without resolving the recipient addresses. You can use an SMTP connector to relay email messages between Exchange Server 2003 and other SMTP-compatible messaging systems such as UNIX Sendmail (see www.sendmail.org) or to other SMTP hosts on the Internet. The bridgehead server or servers defined on SMTP connectors will relay email messages directly to a smart host or to a remote server on which recipient addresses are stored.

There are six different ways to configure SMTP relays in Exchange Server 2003:

Configuring an SMTP virtual server to use a smart host
Configuring an SMTP virtual server to forward unresolved messages to a smart host
Configuring an SMTP virtual server as a relay host
Configuring an SMTP virtual server to limit the servers that can relay e-mail messages
Configuring an SMTP connector to use a smart host
Configuring the domains to which you want to relay messages

Configuring an SMTP Virtual Server to Use a Smart Host

An SMTP virtual server, by default, uses DNS to resolve the recipient's SMTP address. You can instead configure the virtual servers in your organization to forward all outbound mail to a smart host. The virtual server does not then attempt to resolve the SMTP domain name through DNS but instead sends the message to the smart host for delivery. Reasons for using a smart host include

It provides an entry and an exit point for all Internet messages or messages to a foreign messaging system. This allows you to manage Internet message traffic.
It provides dial-up solutions. Clients can use a dial-up connection to send messages to and receive messages from the permanently connected SMTP smart host. This reduces connection time because the clients do not need permanent connections to the Exchange server.

You identify the smart host by an FQDN or by an IP address. However, if you use the latter method and then change the IP address, then you need to change that IP address on every virtual server. If you use an IP address, then you must enclose it in square brackets. Exchange checks first for a server name and then for an IP address. The brackets identify a value as an IP address, and Exchange bypasses the DNS lookup. You configure a virtual server to use a smart host by entering the smart host's identity in the Smart Host box in the virtual server's Advanced Delivery dialog box.

Configuring an SMTP Virtual Server to Forward Unresolved Messages to a Smart Host

Where an organization has other SMTP messaging systems in addition to Exchange, you can forward all unresolved SMTP messages from Exchange to a smart host. If the smart host cannot resolve the recipient's name, then the message is returned with an NDR. You configure an SMTP virtual server to forward unresolved messages to a smart host by entering the smart host's identity in the Forward All Mail With Unresolved Recipients To Host box on the virtual server's Messages tab.

Configuring an SMTP Virtual Server as a Relay Host

If you configure an SMTP virtual server as an inbound relay host, this gives Exchange Server 2003 smart host capabilities. You can then configure other SMTP servers to use the Exchange virtual server as their smart host and forward all outbound messages to the virtual server. The virtual server then resolves the recipient's SMTP domain name through DNS and delivers the messages. You configure a virtual server as a relay host by configuring Relay Restrictions on the virtual server's Access tab.

Configuring an SMTP Virtual Server to Limit the Servers That Can Relay E-Mail Messages

You can prevent unwanted SMTP hosts from using your SMTP host as a relay agent for bulk unsolicited commercial e-mail. You do this by specifying who or what can relay e-mail messages through your organization. You can specify which computers, groups of computers, or domains should be allowed to relay e-mail messages by configuring the SMTP virtual server. You configure the SMTP virtual server to specify which servers can relay e-mail messages through your organization by configuring Relay Restrictions on the virtual server's Access tab.

Configuring an SMTP Connector to Use a Smart Host

An SMTP connector, by default, uses DNS to resolve the recipient's SMTP address. You can instead configure the connector to forward all outbound mail to a smart host. You configure an SMTP connector to use a smart host by entering the smart host's identity in the Forward All Mail Through This Connector To The Following Smart Hosts box on the General tab of the SMTP connector's Properties dialog box.

Note

You can configure smart hosts on both SMTP virtual servers and SMTP connectors. Microsoft recommends that you configure smart hosts on the connector because connectors can handle message delivery on a per-domain basis.

Configuring the Domains to Which You Want to Relay Messages

You may want to limit the domains to which you relay messages rather than the domains from which you relay messages. This can be useful when your organization has multiple SMTP messaging systems that operate under different SMTP domain names. You may want your SMTP host to accept messages from any domain but then forward them only to specific domains, such as the other domains in your organization. You can specify the domains to which you want to relay messages on an SMTP connector's Address Space tab.

Practice: Creating MX Records and Configuring an SMTP Connector

In this practice, you configure DNS to support your Exchange Server 2003 organization and then create and configure an SMTP connector. These are the typical administrative tasks that you carry out when setting up SMTP in an Exchange organization.

Exercise 1: Create MX Records for Your Exchange Server 2003 Servers

In this exercise, you will create MX records for Server01 and Server02. The exercise assumes that both servers are configured as Exchange Server 2003 servers and that the domain controller, Server01, is the primary DNS server (either standard primary or Active Directory Integrated). The MX records will be configured so that an SMTP connection to your organization will first access Server01 and will access Server02 if Server01 is unavailable. After creating the MX records, you use the Command console to verify them.

To create MX records for Server01 and Server02, perform the following steps:

Open the DNS console.
In the console tree, expand Server01, expand Forward Lookup Zones, and then expand tailspintoys.com.
In the console tree, right-click tailspintoys.com, and then click New Mail Exchanger (MX).
In the New Resource Record dialog box, in the Fully Qualified Domain Name (FQDN) Of Mail Server box, type Server01.tailspintoys.com. In the Mail Server Priority box, type 10, and then click OK.
Verify that a new record of type Mail Exchanger (MX) exists for server01.tailspin-toys.com.
In the console tree, right-click tailspintoys.com, and then click New Mail Exchanger (MX).
In the New Resource Record dialog box, in the Fully Qualified Domain Name (FQDN) Of Mail Server box, type Server02.tailspintoys.com. In the Mail Server Priority box, type 20, and then click OK.
Verify that a new record of type Mail Exchanger (MX) exists for server01.tailspin-toys.com. At this point, your screen should look like Figure 10-2.

Figure 10-2: Verifying that MX records exist
To verify that the record for Server01 is resolvable, open the Command console on Server02.
At the command prompt, type nslookup -querytype=mx Server01 and then press ENTER. Information about the primary name server server01.tailspintoys.com DNS settings should be returned, as shown in Figure 10-3.

Figure 10-3: Verifying that the MX record for Server01 can be resolved
Close the Command and the DNS consoles.

Exercise 2: Create and Configure an SMTP Connector

In this exercise, you create and configure an SMTP connector and specify the default SMTP virtual server on Server02 as the bridgehead server. You must complete this exercise to complete subsequent practices in this chapter.

Open Exchange System Manager and browse to Administrative Groups\First Administrative Group\Routing Groups\First Routing Group\Connectors.
Right-click Connectors, point to New, and then click SMTP Connector.
In the Properties dialog box, in the Local Bridgeheads pane, click Add.
In the Add Bridgehead dialog box, click SERVER02 Default SMTP Virtual Server, and then click OK.
In the Properties dialog box, in the Name box, type General SMTP Connector.
Select the Address Space tab, and then click Add.
In the Add Address Space dialog box, click SMTP, and then click OK.
In the Internet Address Space Properties dialog box, verify that E-Mail Domain is set to * to indicate that all outbound SMTP e-mail uses this connector, and then click OK.
Click OK in the General SMTP Connector Properties dialog box.
Verify that the General SMTP Connector object exists in the First Routing Group\Connectors container, as shown in Figure 10-4.

Figure 10-4: The General SMTP Connector object

Practice: Configuring an SMTP Connector to Use a Relay Host for Outbound SMTP

In this practice, you will configure your SMTP connector to use a relay host for outbound SMTP. To complete this practice, an SMTP connector must exist in your organization. If an SMTP connector does not exist, you must create one by completing Exercise 2 of the previous practice, "Create and Configure an SMTP Connector."

To configure Exchange to use an SMTP relay host, perform the following steps:

Open Exchange System Manager, browse to Administrative Groups\First Administrative Group\Routing Groups\First Routing Group\Connectors, and then expand Connectors.
In the console tree, right-click General SMTP Connector, and then click Properties.
In the General SMTP Connector Properties dialog box, on the General tab, click Forward All Mail Through This Connector To The Following Smart Hosts, type SMARTHOST and then click OK. (Note that the SMARTHOST computer does not exist. It is merely a name specified for testing purposes.)
To verify that the SMARTHOST configuration is set properly, send a test message from Outlook Web Access (OWA) to d.hall@tailspintoys666.com, and then check the Queues object located in Exchange System Manager at Administrative Groups\First Administrative Group\Servers\Server02\Queues. Verify the existence of the General SMTP Connector - SMARTHOST (SMTP Connector) object, as shown in Figure 10-5.

Figure 10-5: Verifying the SMARTHOST configuration

The presence of the word SMARTHOST indicates that the connector is configured correctly. The connector is not truly functional because no SMARTHOST AU computer and no network connectivity exist outside the computers on your test network.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and then try the question again. You can find answers to the questions in the "Questions and Answers" section at the end of this chapter.

You are a network administrator, and you want to test connectivity between a host on your network and a new Exchange Server 2003 server that has just been configured. You want to ensure that e-mail messages to that server can be encrypted. You can ping the server by host name. You connect to port 25 on the server. What command should you use?
1. atrn
2. etrn
3. elho
4. helo
You are the administrator of the Contoso ISP. You have two SMTP servers configured as smart hosts: smart1.contoso.com and smart2.contoso.com. Your ISP manages DNS records for Northwind Traders, whose Exchange Server 2003 server has the FQDN mailserv.nwtraders.com. Northwind Traders has a permanent connection to your ISP. How should you configure the MX records for this setup in DNS?
1. MX 10 smart1.contoso.com
  
  MX 10 smart2.contoso.com
  
  MX 20 mailserv.nwtraders.com
2. MX 10 mailserv.contoso.com
  
  MX 20 smart1.contoso.com
  
  MX 20 smart2.nwtraders.com
3. MX 10 smart1.contoso.com
  
  MX 20 smart2.contoso.com
  
  MX 30 mailserv.nwtraders.com
4. MX 10 mailserv.contoso.com
  
  MX 10 smart1.contoso.com
  
  MX 10 smart2.nwtraders.com
You administer your company's Exchange Server 2003 organization. Your company has two e-mail domains. You want to control filters, relay restrictions, message formats, outbound security, and smart host options separately for each domain. What technique would you use?
1. Create an additional virtual server and configure an SMTP connector to use it as a bridgehead.
2. Configure all these items on the default SMTP virtual server.
3. Configure Internet message formats and delivery parameters for each domain.
4. Limit the scope of the SMTP connector to a specific routing group.
You administer an Exchange Server 2003 server. You want this server to act as a smart host. Your organization has a single SMTP domain. How do you configure your server?
1. Configure an SMTP connector to forward all outbound mail.
2. Configure the default SMTP virtual server as a relay host.
3. Configure the default SMTP virtual server to forward all unresolved messages.
4. Configure the default SMTP virtual server to specify which servers can relay email.
You want your Exchange Server 2003 organization to have smart host capability. How should you configure a virtual server to provide such capability, and how is the configuration implemented?

Lesson Summary

SMTP transfers e-mail messages using a series of plain-text commands that are passed from a sending host to a receiving host. The receiving host responds using numerical codes. ESMTP extends SMTP functionality.
DNS uses MX records to identify e-mail servers and to resolve their IP addresses.
You can control Internet access by creating and configuring additional SMTP virtual server and SMTP connectors.
When one SMTP host forwards e-mail to another SMTP host without resolving the recipient address, the process is called relaying.
You can configure SMTP relays to restrict relay traffic, to interface with foreign messaging systems, and to set up your Exchange Server 2003 server as a smart host.