Using Mail Services

You manage the configuration of SMTP through virtual servers. These virtual servers are used to handle mail submission and transport services for one or more e-mail domains and each SMTP virtual server. When you install the SMTP service as part of an IIS installation, a default SMTP virtual server is created.

The default virtual server is preconfigured so that locally generated messages can be handled and delivered. The configuration restricts the sending of messages that are generated by remote users, which include the Internet Guest account and any other named user on the Web server. The configuration also restricts relaying of e-mail through the SMTP virtual server. With these settings you can use the default virtual server in most environments without having to make further adjustments. That said, there are many times when you’ll want to optimize configuration settings to meet your environment’s needs.

You manage the configuration of POP3 using e-mail domains. Each POP3 server has a specific configuration that’s inherited by the e-mail domains configured on the server. You install the POP3 service separate from the IIS installation. To do this, you install the E-Mail Services Windows component. Because the POP3 installation is dependent on IIS and SMTP, these components are also installed if they aren’t already installed on the server.

The SMTP and POP3 services are designed to provide basic messaging services for one or more domains and you can configure them in different ways. To understand how e-mail services are used and managed, you need to understand the following concepts:

• How e-mail domains are used

• How the mail root is used

• How SMTP messages are processed

Understanding E-Mail Domain Usage

The SMTP and POP3 services use the e-mail address provided in a message’s To, Cc, Bcc, and From fields to determine how the message should be handled. To, Cc, and Bcc fields are used to determine where the message should be delivered. The From field determines from where the message originated.

E-mail addresses, such as [e-mail], have three components:

• An e-mail account, such as williams

• An at symbol (@), which separates the account name from the domain name

• An e-mail domain, such as tech.microsoft.com

The key component that determines how the server handles messages is the e-mail or service domain. Service domains can be either local or remote. A local service domain is a Domain Name System (DNS) domain that’s serviced locally by the server. A remote service domain is a DNS domain that’s serviced by another server or mail gateway.

Any message with a local domain name in a message’s To, Cc, or Bcc fields is delivered locally. With SMTP you can designate a local domain as the default domain or an alias domain. The default domain serves as the default for all messages transferred into or out of the domain. Messages addressed to the default domain are stored in the virtual server’s Drop directory and, if POP3 is configured, delivered to the appropriate mailbox, if it’s available. Outgoing messages that don’t have a domain set in the From field of the e-mail address use the default domain as their domain of origin. An SMTP virtual server can have only one default domain.

Any other local domains that you create on an SMTP virtual server are specified as alias domains. Alias domains allow you to create secondary domains that point to the default domain and use its settings. When working with alias domains, keep in mind that any message sent to an alias domain is stamped with the default domain name. This means that the alias domain uses the same configuration settings and the same Drop directory as the default domain. For example, an SMTP virtual server could specify tech.microsoft.com as the default domain and dev.microsoft.com as an alias domain. Any messages that specify either of these domains are handled locally by the SMTP virtual server on which they’re configured and are stamped with the default domain name.

Any message with a nonlocal domain in a message’s To, Cc, or Bcc fields is queued for delivery to a remote server. If you have unique delivery requirements for a specific remote domain, you can add a remote domain to the SMTP server and configure settings that allow you to handle its messages appropriately. For example, you could configure a remote domain with separate outbound security that requires message encryption. Or you could forward messages destined for a remote domain through a specific mail server designated as a smart host.

To receive e-mail, the server must be registered as the mail exchange for the domain in DNS. For example, if you wanted to receive mail for dev.microsoft.com, you’d need to have your Internet service provider (ISP) create a Mail Exchange (MX) record in DNS. This record would designate the server as an authorized mail exchange for the dev.microsoft.com domain.

When you create an MX record, you must specify a preference number for the mail server. This value denotes the mail server’s priority within the domain. The server with the lowest priority is the first to receive mail. If mail delivery to this server fails, the mail server with the next lowest priority is tried.

For example, you could configure netmail01 and netmail02 as mail servers for your organization’s data center. If netmail01 had a priority of 10 and netmail02 had a priority of 15, mail would first be routed to the netmail01 server. If delivery to that server failed, the mail would be routed to netmail02.

Generally speaking, you can’t route mail to multiple servers—only one server will receive the mail, and because of this, you’ll want to plan out the implementation very carefully. In most cases you wouldn’t want mail for your company’s primary domain to be routed to your Internet, intranet, or extranet servers. For example, if microsoft.com is your primary domain and you already have a mail exchange server configured for the company, you wouldn’t want POP3 e-mail services for your Web servers to interfere with mail delivery to the microsoft.com domain. Here, you might configure a new e-mail domain, such as dev.microsoft.com, and use this domain for your Internet, intranet, or extranet servers.

Understanding the Mail Root

During the installation of mail services, a default SMTP virtual server is installed. Both SMTP and POP3 use this default virtual server, and you can’t delete it.

The default virtual server uses the Inetpub\Mailroot folder to manage message submission and delivery. You can install additional SMTP virtual servers. When you do this, each virtual server has a separate mail root that’s located in the directory you specify during creation. The only mail root shared by POP3 servers, however, is Inetpub\Mailroot or the directory you specify when configuring the POP3 mail server.

Each mail root has seven subfolders associated with it. These folders are used as follows:

• Badmail Used to store messages that are undeliverable and can’t be returned to the sender. Each badmail message has an error message associated with it that you can use to help diagnose the problem. You should periodically monitor the Badmail folder to ensure that messages are flowing through the system as expected.

• Drop Drop box for all incoming messages addressed to recipients located on the server, such as the virtual server’s postmaster. If an incoming message is addressed to a local recipient, the SMTP service moves the message from the Queue folder to this folder. This folder becomes the final destination unless POP3 is configured. When POP3 is configured, the message is passed from the Queue folder to the appropriate mailbox store, bypassing the Drop folder.

• Mailbox Used to store mailboxes. For the Inetpub\Mailroot folder, this is where you’d look to find mailboxes for users who have POP3 e-mail domains. Each domain configured has a separate folder and within this folder are subfolders for any mailboxes you’ve created for the domain. With Mailbox folders, individual e-mail messages are stored as flat files.

• Pickup Used as a pickup point for messages that are to be delivered by the SMTP service. The SMTP service monitors this mailbox continuously for new messages. Any message placed in this folder is picked up by the SMTP service and transferred to the Queue folder for further processing and delivery.

• Queue Holds messages that are ready for processing and delivery. Messages are transferred to the Queue folder from the Pickup folder when they’re received by SMTP. Messages that the SMTP service is unable to deliver due to bad connections or busy destination servers are stored in the Queue folder as well. These messages remain in the Queue folder until they can be delivered or until they’re deemed undeliverable and transferred to the Badmail folder.

• Route Used to store temporary data needed to route messages along specific paths. Typically used when you configure a route domain for an SMTP virtual server.

• SortTemp Serves as a temporary sorting area for messages. Temporary files are created in this directory and are cleared out after messages are sorted and queued for delivery.

When you configure e-mail services for use on a server, you should periodically monitor the Badmail and Queue folders. The Badmail folder provides the best indicator that you might have a problem with e-mail transfer. Messages in this folder couldn’t be delivered to the intended recipients, and they couldn’t be returned to the sender. If the number of messages in this folder is growing, your mail server might have a problem accessing the network or delivering mail. Likewise, if the number of queued messages is growing and messages aren’t clearing out of the Queue folder, your mail server might have a problem connecting to the network or delivering mail.

Understanding Mail Processing

The SMTP service is very systematic in the way it processes mail messages. Mail messages can originate from two sources:

• Pickup folder Message files placed in the Pickup folder by an application, such as an Active Server Page, or by a user, such as an administrator

• SMTP Message files received using the SMTP network protocol

When a message is copied to the Pickup folder or comes in through the SMTP network protocol, it’s placed in the Queue folder for processing and delivery. What happens to a message next depends on the type of recipient. Mail recipients fall into two categories:

• Local recipients A local recipient is a recipient with an e-mail domain serviced locally by the SMTP server. Locally serviced domains are the default domain and any alias domains configured on the server. Mail messages for local recipients are handled locally.

• Remote recipients A remote recipient is a recipient with an e-mail domain serviced remotely by the SMTP server. Mail messages for remote recipients can be relayed directly, routed through DNS, or forwarded to a designated mail gateway.

  Note

  The e-mail domain is the portion of the e-mail address to the right of the at symbol (@). For example, the e-mail domain for the [e-mail] address is tech.microsoft.com. E-mail addresses and domain names are always processed by the server from right to left.

If a message is for local recipients and POP3 isn’t configured, the message is moved from the Queue folder to the Drop folder designated for the default domain. After the message is placed in the Drop folder, the SMTP service is done processing the message. By default, the Drop folder is located at Inetpub\Mailroot\Drop. However, the Drop folder’s location is configurable and you can change it using the Properties dialog box for the default domain.

If a message is for local recipients and POP3 is configured, the message is moved from the Queue folder to the appropriate mailbox store. The Drop folder isn’t used in this case.

If a message is for remote recipients, the recipients for the message are sorted by domain so the SMTP service can deliver the messages to these recipients as a group and thereby attempt to deliver multiple messages in a single mail session. After sorting, the message is queued for delivery.

Messages in the queue are handled in first in, first out (FIFO) order, which means that the first message into the queue is the first message that SMTP attempts to deliver. When a message is at the front of the queue, the SMTP service attempts to connect to the destination mail server. If the SMTP service is able to establish a connection, the recipients are verified, the message is sent, and it’s up to the destination server to confirm receipt. If the destination server fails to respond or isn’t ready to receive the message, the message remains in the queue and the SMTP service attempts to deliver the message according to the retry intervals you’ve specified. Processing will continue on lower-ranked messages while the SMTP service waits to retry delivery.

Messages that can’t be delivered within a specific expiration period are marked as non-deliverable, and the SMTP service generates a non-delivery report. The non-delivery report provides an error message that explains why delivery failed, along with the original message. The SMTP service then attempts to deliver this report to the sender of the original message.

The message delivery process for the non-delivery report is the same as it is for any other message. The SMTP service places the message in the Queue folder and processes the message according to whether the sender is a local or remote recipient. However, if the non-delivery report can’t be delivered to the sender of the original message, the non-delivery report is moved to the Badmail folder and the SMTP service is finished processing the message.