SMTP and Internet Connectivity


In Chapter 8, you saw how the SMTP Connector could be used to connect routing groups in the same organization and to connect an Exchange Server 2003 routing group to an Exchange 5.5 server site. You can also use SMTP Connectors to connect an Exchange organization to the Internet or to a foreign messaging system that uses SMTP.

SMTP Overview

The Simple Mail Transfer Protocol (SMTP) defines the methods for exchanging mail messages between applications. The protocol addresses mail transfer between an SMTP client and an SMTP server (the client may itself be another SMTP server). This section discusses SMTP and outlines how it works.

SMTP Process

The SMTP process involves a TCP connection, a series of client/server commands and replies, and the use of spooling. We will discuss each of these in the following sections.

TCP Connection

When an SMTP client application sends mail to an SMTP server, it uses TCP to establish a connection with port 25 on the SMTP server. Port 25 is the application doorway on the SMTP server for mail activity. Once that connection is established, a series of commands and replies is exchanged between the client and the server. The connection is similar to a telephone connection, and the commands and responses are similar to verbal communication over a telephone connection.

SMTP Commands and Replies

Now we will examine the steps in the SMTP process (including the TCP connection). In this example, we will send a message. You do not need to remember the reply code numbers . They are included here merely to provide a complete picture.

  1. A client establishes a connection with the server at port 25.

  2. The server confirms the connection by replying with a 220 reply code, which means ‚“ready for mail. ‚½

  3. The client computer identifies itself to the server by sending the HELO command with the computer ‚ s identity (for example, HELO server1.acme.com ).

  4. The server confirms the HELO by responding with the 250 reply code (which means ‚“all is well ‚½) and its identity. The server may also require a password or some other form of authentication.

  5. The client sends the MAIL FROM command that contains the identification of the sender.

  6. The server responds with the 250 reply code ( ‚“all is well ‚½).

  7. The sender then sends the RCPT TO (Recipient To) command with the identity of a recipient of the mail message.

  8. The server responds with either a 250 reply code or a 550 reply code (which means ‚“no such user here ‚½).

  9. After all the RCPT TO commands are sent (one command is sent per recipient), the client sends the DATA command indicating that it is ready to send the actual mail message.

  10. The server responds with a 354 reply code (which means ‚“start mail input ‚½).

  11. Upon receiving the 354 reply, the client sends its outgoing mail messages line by line. The data must be in 7-bit ASCII format. If the data is in 8-bit format, it must be translated into 7-bit format using either Multipurpose Internet Mail Extension (MIME) or UUENCODE (UNIX-to-UNIX encode).

  12. After the data has been sent, the sender sends a special sequence of control characters (e.g., CRLF.CRLF) to signal the end of the transfer.

  13. The client sends a QUIT command to end the session.

  14. The server responds with the 221 reply code (which means that it ‚“agrees with the termination ‚½). Both sides of the communication close the TCP connection.

SMTP and Spooling

The word spooling in this context means queuing . SMTP uses spooling to delay message delivery. For example, when a client sends a message addressed to another user, that message is spooled on the sender ‚ s SMTP server. The SMTP server will periodically check its spooled messages and try to deliver them to the relevant users. If it cannot deliver a message, the SMTP server will keep the message spooled and try to deliver it at a later time. When the recipient ‚ s server comes online, the SMTP server can deliver the message. If a message cannot be delivered within a time period set by the administrator, the spooled message is returned to the sender with a non-delivery message.

The advantage of the spool mechanism is that the message sender does not have to establish a connection with a recipient ‚ s computer in order to send a message. After sending a message, the sender can proceed with other computing activities because she does not need to wait online for the message to reach the recipient. The recipient also does not have to be online in order for mail to be sent to him.

DNS and SMTP

Transferring messages between SMTP hosts is dependent on the Domain Name Service (DNS). When an SMTP host sends an e-mail message to another SMTP host, DNS must resolve the domain name of the receiving host to an IP address. DNS does this by storing special records named Mail Exchanger (MX) records in the DNS database. Each MX record in a DNS database represents an SMTP host to which mail can be forwarded. You can also assign each MX record a preference relative to the other MX records in the database.

A sending SMTP host retrieves all MX records for the receiving domain from DNS, resolves the IP address for the SMTP host with the lowest preference number, and attempts to send its message to that host. If that host is unavailable, the sender tries the host with the next higher preference number. If you have three mail servers in your organization that can send and receive mail across your network boundaries, the MX record entries in your DNS forward lookup zone might look like this:

 mcseworld.com MX 10 mcsesvr3042.corp.mcseworld.com. mcseworld.com MX 30 mcsesvr3142.corp.mcseworld.com. mcseworld.com MX 50 mcsesvr3242.corp.mcseworld.com. 

Each entry is composed of several different fields. The first field specifies the name of the domain that the MX record is responsible for, in this case the mcseworld.com domain. The second field specifies the record type, in this case an MX record. The third field specifies the preference number for that mail server. The last field specifies the fully qualified domain name (FQDN) or IP address of the mail server that the MX record entry is pointing to.

SMTP Folders in Exchange Server 2003

SMTP uses three file system folders to manage messages on an Exchange Server 2003. By default, all of these folders are created in the C:\Program Files\Exchsrvr\Mailroot\vsi x folder. The three folders are as follows :

  • The Pickup folder is used for outbound messages on some SMTP hosts. Exchange Server 2003 creates, but does not normally use, this folder.

  • The Queue folder is where SMTP stores inbound messages as they are received. Once received, Internet Information Server (IIS) processes them for delivery.

  • The Bad Mail folder is where undeliverable messages that cannot be returned to the sender are stored.

Configuring Multiple SMTP Domain Names

SMTP can be configured in a number of different ways. For example, you might provide your users with one or multiple SMTP addresses. You might also segregate users into virtual organizations, each with their own SMTP address spaces. For example, you might configure some of your users to receive mail using the @widgets.com address space, while others receive mail using the @cooltools.com address space. To do this, you must configure separate SMTP virtual servers for these users and configure MX records to resolve the IP address associated with those virtual servers.

The SMTP Virtual Server

With Exchange Server 2003, you can create multiple virtual servers for every supported Internet protocol, including SMTP. Creating multiple SMTP virtual servers allows you to segment SMTP traffic to use different IP addresses or TCP ports, each with its own configuration. This allows you a good bit of leeway in your SMTP configuration. For example, you might configure one SMTP virtual server with stricter authentication policies than another. Or, you might configure one virtual server to send and receive SMTP messages between all Exchange Server 2003 servers inside an organization and configure another virtual server to send and receive SMTP messages from the Internet.

As with most other objects, you ‚ ll configure the SMTP virtual server using its property pages. Just expand the Protocols container under the Exchange server on which the virtual server is configured, and then expand the SMTP container, as shown in Figure 13.6.


Figure 13.6: Viewing SMTP virtual servers

To start with, only the Default SMTP Virtual Server exists. You can add new virtual servers by right-clicking the SMTP container and selecting the New SMTP Virtual Server command. This command opens the property pages for configuring the new server. Each of the available pages is discussed in the upcoming sections.

General Properties

The General page, shown in Figure 13.7, is used to set several general parameters, including the following:

  • The IP address assigned to the virtual server (this is unassigned by default)

  • The number of concurrent connections the server is allowed to support (no limit is set by default)

  • The maximum amount of time a connection may be idle before being timed out (again, no default is set)

  • Whether logging is enabled (disabled by default)


    Figure 13.7: General properties of an SMTP virtual server

Access Properties

The Access properties page, seen in Figure 13.8, provides access to a number of separate dialog boxes used to control access to the virtual server.


Figure 13.8: Access properties of an SMTP virtual server

Table 13.2 describes the parameters you can configure using the buttons on this page.

Messages Properties

The Messages page, shown in Figure 13.9, lets you configure how messages are handled by the SMTP virtual server. You can place several limits on messages, including the message size, the cumulative size of messages that can be transferred during a single session, the number of messages that may be sent per connection, and the number of recipients a single message can name. You can also use this page to designate a recipient to receive Non-Delivery Reports (NDRs) and change the directory in which bad mail is stored.


Figure 13.9: Configuring message properties

The final field on this page, Forward All Mail With Unresolved Recipients To Host, is probably not featured prominently enough in the list of options. This field lets you name a smart host to which messages are forwarded when they cannot be resolved within your domain. This offers the powerful ability to configure a single host to which all external mail (such as to the Internet) should go. For example, you could configure your SMTP virtual server to forward all unresolved messages (those not to recipients in your own organization) to an SMTP host at your ISP or to a smart host of your own that you have placed outside the company firewall. This allows you the ability to specify how messages are to be routed outside of your organization, such as by using a specific link that has a lower cost.

Table 13.2: Setting Access Properties for an SMTP Virtual Server

Button

Settings

Authentication

It is often useful to require an SMTP host or client to authenticate before allowing message transfer. You can use this button to choose from Anonymous, Basic, or Integrated Windows authentication methods. This dialog also lets you configure TLS encryption. Authentication and encryption are covered in Chapter 15.

Certificate

This button launches a wizard for creating and configuring web server certificates (also discussed in Chapter 15).

Communication

This button lets you configure whether a secure channel is required to transfer messages using the SMTP virtual server and whether that secure channel should use 128-bit encryption.

Connection

This button opens a dialog that lets you configure a specific list of hosts to grant or deny access to.

Relay

By default, an SMTP virtual server will accept messages from any host but will relay only messages sent from authorized clients. This allows clients in your domain using POP3 or IMAP4 clients to send SMTP messages using the SMTP virtual host. If you want to configure your SMTP virtual server to act as a smart host for relay messages coming in from other domains, you can configure the specific clients for whom to relay messages using this button. Note that this is used to configure only inbound relay restrictions. Outbound restrictions are configured using the SMTP Connector.

Delivery Properties

The Delivery page, seen in Figure 13.10, lets you set several options governing how the SMTP virtual server tries to deliver mail and some parameters governing the security and configuration of outbound connections.


Figure 13.10: Delivery properties of an SMTP virtual server

The parameters you can configure on this page are shown in Table 13.3.

Table 13.3: Setting Delivery Properties for an SMTP Virtual Server

Property

Description

Retry Intervals

By default, each virtual server tries to deliver messages as they arrive . When delivery fails for some reason, the virtual server queues the message for retries. The First through Third and Subsequent Retry Interval settings let you configure how long it takes the server to attempt to send a message after a failure.

Delay Notification

If a message has been queued for 12 hours (the default setting), the sender is notified that the message has not been delivered yet.

Expiration Timeout

After two days (again, the default setting), the message is returned to the sender with an NDR.

Local

The Delay Notification and Expiration Timeout settings in the Local section work the same as those in the Outbound section but apply only to recipients within the organization.

Outbound Security

As you saw in the previous section, inbound security is set using the Authentication button on the Access page. Outbound security is configured using this button. Usually, you should configure outbound security to use the same authentication protocols that you require for inbound security.

Outbound Connections

Use this button to assign limits on the allowable number of outbound connections.

Advanced

One common security problem with Internet mail occurs when the person sending the message misrepresents their identity. This is referred to as spoofing. To help prevent spoofing, you can configure an SMTP virtual server to perform a reverse DNS lookup on people who send messages. This confirms that the IP address of the sender is from the same network as is registered in DNS. Use the Advanced button to enable Reverse DNS lookup. One caution, however: Using reverse DNS lookup can significantly decrease performance.

Managing SMTP Virtual Server Queues

SMTP maintains four queues in which messages are held for various stages of processing. These queues are:

  • local_domain_name (Local Delivery), which contains messages waiting for delivery to a local mailbox. If this queue backs up, look for problems within IIS or the Information Store.

  • Messages awaiting directory lookup, which contains messages waiting for recipient addresses to be resolved. If this queue backs up, look for problems between Exchange Server 2003 and Active Directory.

  • Messages waiting to be routed, which contains messages waiting for Exchange Server 2003 to determine the best route along which to send them. Once the route is determined, messages are moved to various temporary link queues for delivery. If this queue backs up, look for problems with connectors.

  • Final destination unreachable, which contains messages the SMTP virtual server was unable to deliver. If this queue backs up, look for problems with the SMTP virtual server, the destination SMTP server, or improper addressing.

For more information on managing queues, see Chapter 10, ‚“Administration and Maintenance. ‚½

Note ‚  

When creating additional virtual servers, you will need to specify a single IP address/port number combination. You cannot use the IP address selection of (All Unassigned) for more than one virtual server on a specific port number.

Follow along with Exercise 13.2 as we create an SMTP virtual server.

EXERCISE 13.2: Creating an SMTP Virtual Server
  1. Click Start > Programs > Microsoft Exchange > System Manager.

  2. Expand the Administrative Groups folder, the administrative group, and the server on which you want to create the new virtual server, and then expand the Protocols container.

  3. Right-click the SMTP container and select New SMTP Virtual Server from the context menu.

  4. On the first page of the wizard that appears, enter the name for the new SMTP virtual server and click Next to continue.

  5. Select the specific IP address configured on your server to be the new SMTP virtual server. Note that the IP address and port number combination you configure must be separate from any that are already in use on your server.

  6. Click Finish to create the new connector and return to System Manager.

  7. In System Manager, expand the SMTP container.

  8. Right-click the new SMTP virtual server, and select Properties from the shortcut menu.

  9. Click the Access tab.

  10. Click the Authentication button.

  11. Remove the checkmarks next to the Anonymous Access and Basic Authentication options and click OK.

  12. Click the Messages tab.

  13. Select the Limit Message Size To (KB) option, and enter a maximum message size into the corresponding field.

  14. Click OK to set the new properties and return to System Manager.

 

The SMTP Connector

While an SMTP virtual server is used to define basic SMTP transport properties, an SMTP Connector is used to define properties for a specific address space. In Chapter 8, we covered the creation and configuration of SMTP Connectors in detail. Even though that discussion was aimed primarily at using the SMTP Connector to connect routing groups, the process of setting up the SMTP Connector for other uses is almost identical, so we refer you to Chapter 8 for specifics.




MCSA[s]MCSE
MCSA[s]MCSE
ISBN: 735621527
EAN: N/A
Year: 2004
Pages: 160

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net