Chapter 15: SMTP and NNTP

While the primary purpose of IIS is to provide a platform for deploying web applications and hosting websites, IIS also includes other application-layer TCP/IP services including the Simple Mail Transfer Protocol (SMTP) and Network News Transfer Protocol (NNTP) services. These two services are the focus of this chapter.

The SMTP Service

The SMTP service is included as a component of IIS for three basic purposes:

• To enable IIS machines to function as RFC 821/822–compliant SMTP hosts that can be used by service providers for forwarding e-mail across the Internet. While most service providers rely heavily on Sendmail, the standard SMTP server application for UNIX/Linux platforms, IIS is a viable alternative to Sendmail for this purpose.

• To enable an IIS machine running SMTP to act as a buffer between a corporate e-mail server running Microsoft Exchange and a Sendmail host at the company’s ISP. This provides an extra layer of security to protect Exchange servers from attack and misuse.

• To provide ASP developers with a tool for sending e-mail from their applications, for example, in response to a user submitting a form on a web page.

The SMTP service is thus designed for sending outgoing mail and forwarding incoming mail to mail servers or other SMTP hosts. The SMTP service is not designed to handle incoming mail and provide mailboxes so users can receive messages. Incoming mail is generally handled by mail servers like Microsoft Exchange that support the POP3 and IMAP protocols for message delivery and storage.

Another way of saying this is that SMTP is a mail forwarding protocol, not a mail delivery protocol. SMTP can only be used to forward mail from one SMTP host to another and cannot deliver mail directly to a client. Mail clients like Outlook Express use SMTP for sending mail and POP3 (or IMAP) for receiving mail.

Note 

Windows Server 2003 now includes a POP3 service that can be used for handling incoming mail and setting up mailboxes for users. The POP3 service is not a component of IIS 6, however, but a separate component of Windows Server 2003, so it’s not covered in this book. For information on how to set up and manage POP3, use the Help and Support Center on your server.

Installing the SMTP and NNTP Services

To use IIS as an SMTP host, you need to install the SMTP service component of IIS first, as it is not installed by default on Standard or Enterprise Editions of Windows Server 2003 (SMTP is installed by default on Web Edition, however).

To install the SMTP and NNTP services, first insert your Windows Server 2003 product CD-ROM into your CD-ROM drive. Then click Start, select Control Panel, and open Add Or Remove Programs. Click the Add/Remove Windows Components button, select Application Server, click Details, select Internet Information Services (IIS), click Details again, and select the check boxes for SMTP Service and NNTP Service. Click OK several times to return to the wizard, and the components will be installed.

To verify your installation, open IIS Manager and make sure you have nodes for Default SMTP Virtual Server and Default NNTP Virtual Server in the console tree (Figure 15-1). You can use IIS Manager to perform the following SMTP administration tasks:

Figure 15-1: Default SMTP and NNTP virtual servers in IIS Manager

• Create and configure SMTP virtual servers and start, stop, and pause them independent of one another.

• Configure connection, delivery, message, security, authentication, relay, and other settings for SMTP virtual servers.

• Create and configure new SMTP alias and remote domains.

• Display current sessions and terminate selected (or all) connections.

Message Store Directory Structure

When the SMPT service is installed on IIS, a directory structure is created with root folder \Inetpub\Mailroot on the local machine. This directory structure represents the message store for the service and consists of the following folders:

• Badmail Messages that can’t be delivered to their intended recipients after a configured number of attempts and that can’t be returned to the sender are placed in this folder so they can be examined later by an administrator to determine what went wrong.

• Drop All incoming messages addressed to local domains managed by the SMTP service are “dropped” into this folder regardless of their intended recipient, and there they wait. Note that the SMTP service does not have individual mailboxes for users, only a catch-all \Drop folder instead. If you need mailboxes for users, install the POP3 component of Windows Server 2003 or use a full-featured messaging platform like Microsoft Exchange.

• Pickup Messages placed in this folder are “picked up” by the SMTP service and processed as outbound messages. For example, you can create a message by hand using Notepad, including the necessary SMTP message headers addressing it, and then place it in this directory, and the SMTP service will try to deliver it to its intended recipient. Alternatively, you could write an application that creates a message and places it in this directory for delivery. If the destination domain in the To: header of the message is a local domain managed by the SMTP service, the message is moved to the \Drop folder.

• Queue If a message in the \Pickup folder cannot be delivered immediately because of some reason such as the connection to the remote host being down or busy, the message is moved to the \Queue folder, where the SMTP service tries to deliver it again at regular intervals.

• Mailbox, Route, and SortTemp Relics of the code base for the legacy Microsoft Commercial Internet System (MCIS), these folders are actually not used in IIS 6 and can be deleted if desired.

  Tip 

  If you are a developer and want to mail-enable your ASP application to use the SMTP service of IIS, consider using Collaboration Data Objects for Windows 2000 (CDOSYS), which replaces the earlier Collaboration Data Objects for Windows NT Server (CDONTS) library. CDONTS was used for mail-enabling applications in IIS 4 and was supported for backward compatibility reasons in IIS 5, but is no longer supported in Windows Server 2003.

How Mail Is Processed

The SMTP service (smtpsvc.dll) runs in-process within the host main IIS process Inetinfo.exe and continually monitors TCP port 25 for incoming messages and the \Pickup directory for outgoing messages. When a message comes in addressed to a user belonging to a local domain managed by the SMTP service, the message is placed in the \Drop folder and delivery is done.

To send an outgoing message to a user belonging to some other DNS domain, an ASP application running on IIS can use CDOSYS to create and place the outgoing message in the \Pickup folder. The SMTP service immediately detects the presence of the message in the \Pickup folder, parses the domain name from the recipient’s e-mail address (for example, the mtit.com in [e-mail]), and then performs a DNS lookup using TCP port 53 on the configured name server to determine the name of the SMTP host that handles mail for the remote domain. This is done by looking up the MX record for the remote domain.

Once the fully qualified domain name (FQDN) of the remote SMTP host has been identified (for example, smtp.mtit.com), the SMTP service tries to establish a connection with the remote host on TCP port 25, the standard SMTP communication port for message transfer. Depending on how the remote host is configured, credentials may need to be provided to establish the connection and transfer the message.

If the remote host accepts the connection attempt, the message is transferred to the remote host, which forwards it to the POP3 or IMAP server where the recipient’s mailbox resides. The next time the recipient opens their mail client program (such as Outlook Express or Eudora), the client connects to the POP3/IMAP server and downloads the message.

If the remote host rejects the connection attempt, the SMTP service tries to return a nondelivery report (NDR) to its original sender, for example, a mail-enabled application running on the IIS machine. If the service is unable to return the message to its original sender, the message is moved to the \Badmail directory and can be retrieved there later by the administrator to troubleshoot the delivery problem.

If the SMTP service is unable to communicate with the remote SMTP host, the message is placed in the \Queue folder, where it waits for a configurable interval of time while the service periodically tries to send the message. If the maximum time limit is exceeded, the service tries to return the message to the sender with an NDR. If it can’t return the NDR to the sender after a configurable time interval, the message is moved to the \Badmail folder.

As an alternative to direct delivery to the SMTP host managing the intended recipient’s DNS domain, the SMTP service can be configured to forward the message to an intermediate host called an SMTP relay. The relay host receives the message forwarded from the SMTP service, and in turn forwards it to the destination host (or to another relay for further forwarding).

Configuring the Default SMTP Virtual Server

When the SMTP service is installed, a Default SMTP Virtual Server is created that can immediately be used for sending mail from e-mail clients like Outlook Express and receiving mail from other SMTP hosts such as Sendmail hosts on the Internet. You can create additional SMTP virtual servers, but usually the default is sufficient and can be renamed if desired.

Like FTP sites, discussed in Chapter 9, “Creating and Configuring FTP Sites,” SMTP virtual servers are uniquely identified by their IP address and port number. If you want to add additional SMTP virtual servers to your IIS machine, you should first bind additional IP addresses to your network interface. In theory, you could have two virtual servers with the same address on the same machine if they had different port numbers, but in reality all virtual servers need to use the same port 25, or they won’t be able to send or receive mail with other SMTP hosts.

Although the default settings for the Default SMTP Virtual Server may suffice for some environments, it’s important to understand the various configuration settings for reasons of security, reliability, and performance. To configure these settings, right-click the Default SMTP Virtual Server node in IIS Manager and select Properties. The next several sections examine various aspects of configuring SMTP on your IIS machine.

General Tasks

There are several general tasks you should perform to begin configuring the Default SMTP Virtual Server. These tasks are performed using the General tab of the Default SMTP Virtual Server properties sheet (Figure 15-2):

Figure 15-2: Configuring general properties for an SMTP virtual server

• IP Address By default, a virtual server (or server, as I’ll call them from now on) is configured to listen on port 25 to all unassigned IP addresses on the machine. If your machine has two IP addresses, 172.16.11.220 and 172.16.11 221, and a remote host attempts to establish a connection on port 25 with either of these addresses, the server will respond. If you have a larger pool of addresses on your server and you only want your SMTP server to listen to a few of them, change the All Unassigned setting to a specific address, click Advanced, and specify other addresses the server should use to assign your server multiple identities.

• Enable Logging IIS can log SMTP commands received from other SMTP hosts trying to communicate with it. It’s a good idea to do this for maintenance and troubleshooting reasons. SMTP logging works the same way web logging does. In fact, when logging is enabled, SMTP writes events to the same log files used by the WWW and FTP services (unless those services have been configured to use a different logging format than SMTP uses). The only difference is that if W3C Extended Log File Format is selected, then initially no log options are selected and you have to specify which options to log using the Advanced tab on the Logging Properties sheet. For more information on how to enable and configure IIS logging, see Chapter 13, “Maintenance and Troubleshooting.”

Incoming Connections

Incoming connections are those established when a remote SMTP host tries to connect to your SMTP server to send a message to your server. There are two settings you can configure on the General tab (see Figure 15-2 again) to control how incoming connections are managed by servers:

• Limit Number of Connections To By default SMTP is configured to accept an unlimited number of simultaneous inbound connections from other hosts, but this is not always a good idea because it leaves your server susceptible to a denial-of-service (DoS) attack. This occurs when an attacker continually attempts to establish new connections with your server until no more TCP ports are available, resulting in legitimate clients being unable to access services on your machine. By limiting the number of connections to a value sufficient for the ordinary needs of your server, you can lessen the effect of this type of attack.

• Connection Timeout By default, if a remote host establishes a connection with a server and then generates no activity for 10 minutes, the connection is automatically terminated by the server. This timeout value can be lowered to further lessen the effects of a DoS attack.

Outgoing Connections

Outgoing connections are those established when your SMTP server tries to connect to a remote SMTP host to send mail to that host. Administrators familiar with the SMPT service in IIS 5 will notice immediately that the connection settings have changed their location in this version of IIS. In the previous version, a Connection button on the General tab opened a dialog box that let you configure both incoming and outgoing connections. In IIS 6, however, the connection settings on the General tab are for configuring incoming connections only (though there is no label to that effect, which is confusing), while outgoing connections are configured using the Outbound Connections button on the Delivery tab (Figure 15-3).

Figure 15-3: Delivery tab on properties sheet

Configuring outgoing connections is slightly more complicated than inbound ones. When you click the Outbound Connections button, an Outbound Connections dialog box appears (Figure 15-4) allowing you to configure the following settings:

Figure 15-4: Configuring outbound connections

• Limit Number of Connections To This specifies the total number of simultaneous outbound connections that the server can establish with remote hosts, regardless of their domain. The default limit is 1000 outbound connections, but this can be set to Unlimited by clearing the check box.

• Timeout When a connection is idle for the indicated time interval, it is terminated to free up network resources. The default timeout interval is 10 minutes, just as for inbound connections.

• Limit Number of Connections per Domain By default, the maximum number of simultaneous connections SMTP can establish with a single remote domain for sending messages is 100 connections. If you have multiple remote domains configured on your server, this setting, if configured properly, prevents any one domain from being starved of resources by other domains.

• TCP Port As I’ve mentioned, the default port for establishing outgoing connections is port 25, and this is almost always sufficient, unless you are trying to operate some kind of “stealth” SMTP server network using nonstandard ports for communicating. If you want your server to communicate with other SMTP hosts on the Internet, however, make sure you leave this set to port 25.

Security and Authentication

Ensuring the secure operation of your SMTP server is essential in today’s high-risk networking environment, and there are a number of configuration settings relating to security and authentication. Most security settings are on the Access tab (Figure 15-5).

Figure 15-5: Access tab settings

The first security setting you can configure is the authentication method your server will require when remote hosts try to establish incoming connections with your server. To configure authentication for incoming connections, click the Authentication button on the Access tab. This opens the Authentication properties sheet, which allows you to specify which methods will authenticate incoming connections (Figure 15-6).

Figure 15-6: Configuring authentication methods for inbound connections

Note 

Again, there is no label for this button specifically identifying that it applies to incoming connections as opposed to outbound ones, which can be confusing.

There are three authentication methods supported for inbound connections, whether from clients like Outlook Express trying to send mail through your server or from remote SMTP hosts trying to deliver mail to or relay mail through your server. These authentication methods are the same as their counterparts for the WWW Service and were discussed in detail in Chapter 10, “Securing IIS.” You can enable one, two, or all three of these authentication methods.

The three methods supported by SMTP for inbound connections are

• Anonymous Access Selecting this method essentially disables authentication and allows anyone to send mail to your server. You might think you should disable this method to prevent this from happening; but if your server is connected to the Internet, you should leave it enabled so that SMTP hosts around the world can send mail to your server. If anonymous access is not enabled, these SMTP hosts will have no idea what credentials you require and will be unable to forward mail to your server. So leave anonymous access enabled for inbound connections, unless your server is used for internal company use only.

• Basic Authentication This method transfers credentials in clear text, which is not secure. However, the advantage of using Basic Authentication is that it is an Internet standard that is supported by the widest number of clients. To make Basic Authentication secure, you can require TLS encryption to be used for encrypting the connection. TLS is a standardized version of SSL and is almost identical to SSL, which I discussed in Chapter 10. If you plan to enable Basic Authentication, consider enabling TLS as well. However, you’ll first have to install a certificate on your server to create the key pair necessary for TLS to work. To install a certificate, click the Certificate button on the Access tab and follow the prompts of the wizard.

• Integrated Windows Authentication This method requires incoming connections to provide a Windows account name and password to be authenticated. If your SMTP server will be used for sending mail to recipients on the Internet, you should enable this authentication method to ensure that only your users can access the server for sending mail.

Another security setting you can configure is Connection Control (see Figure 15-5 again), which lets you specify which computers (SMTP clients such as Outlook Express and/or remote SMTP hosts) are allowed to access your server. These computers can be specified by IP address, network ID and subnet mask, or DNS domain name, and you can either allow or deny access based on any of these methods. This feature is similar in operation to the one for the WWW Service discussed in Chapter 10.

Another important security setting is Relay Restrictions, which allows or denies computers (SMTP clients and/or remote SMTP hosts) the ability to use your server as an SMTP relay for forwarding mail to users in domains other than your own. By default, the server is configured to deny relay access to all hosts except those that are authenticated (Figure 15-7). This is the proper setting because it allows your users’ Outlook clients to relay mail through your server to recipients in other domains but prevents remote SMTP hosts from doing the same. By denying relaying to remote SMTP hosts, you prevent malicious users from sending spam (unsolicited commercial e-mail) through your server and causing recipients to blame you for this activity.

Figure 15-7: Configuring relay restrictions

The best combination of authentication for inbound connections and relay restrictions is to:

• Enable both anonymous access and Windows Integrated Authentication for inbound connections.

• Deny relay access to all computers except those that are properly authenticated by your server.

When your server is configured this way, here’s what happens:

• Users on your company network can use Outlook or Outlook Express to connect to your SMTP server, they can be authenticated using Windows Integrated Authentication, and their messages are then relayed to recipients in a remote domain.

• SMTP hosts on the Internet trying to send mail to your users are “authenticated” using anonymous access (in reality, no authentication occurs), and the mail is delivered to your SMTP server and “popped” into users’ mailboxes on your POP3 server.

• SMTP hosts trying to relay spam through your server to users in other domains are prevented from doing so because they have not been properly authenticated (because anonymous access does not constitute authentication but an absence of authentication).

Another security setting you can configure is the authentication methods used for outbound connections. This is configured by clicking the Outbound Security button on the Delivery tab (see Figure 15-3 again), which opens the Outbound Security properties sheet (Figure 15-8).

Figure 15-8: Configuring authentication methods for outbound connections

The options for outbound authentication are essentially the same as for inbound, with the addition that you can select a user account to specify the credentials that will be sent to remote SMTP hosts for authenticating your outbound connections to them. You can select such an account for either Basic or Integrated Windows Authentication, and the account you select can be either a local account (on a stand-alone server) or a domain account (in a domain environment).

The last security setting is on the Security tab (Figure 15-9), where you can specify which users and groups are assigned operator permissions to allow them to configure the properties of the selected virtual server. By default, only members of the local Administrators group on a stand-alone server have these permissions (plus the built-in special identities LocalService and NetworkService). You can add additional users and groups to this list if desired.  

Figure 15-9: Granting operator permissions

Message and Delivery Settings

The last group of settings you can configure for your SMTP servers are message and delivery settings. Message settings are configured on the Messages tab (Figure 15-10) and allow you to specify the following:

Figure 15-10: Configuring message settings

• Maximum incoming message size Anything over 2MB is rejected by default.

• Maximum session size The maximum amount of incoming data that can be transmitted in message bodies during the life of the connection.

• Maximum number of messages sent per connection If this number is exceeded, the server will open additional outgoing connections as necessary.

• Maximum number of recipients per message If this number is exceeded, the server will open additional outgoing connections as needed to send the message to any remaining recipients.

Note that the first two settings deal with incoming connections and the second two with outgoing. You can tune the performance of your SMTP server by adjusting these settings through judicious experimentation.

On this tab, you can also change the location of the \Badmail folder, and you can specify an e-mail address to which copies of all NDRs will be sent (typically, an account used by the mail administrator).

Delivery settings are configured on the Delivery tab (Figure 15-11) and allow you to specify the following:

Figure 15-11: Configuring delivery settings

• Outbound delivery settings These include retry intervals for attempting to retransmit messages waiting in the \Queue folder. If delivery fails after all attempts, message delivery is considered to have failed. Other outbound delivery settings include Delay Notification, to allow for delays caused by network congestion, and Expiration Timeout, to specify a final grace period before the server returns an NDR to the sender.

• Inbound delivery settings These are a subset of the outbound settings and include only Delay Notification and Expiration Timeout values.

By clicking the Advanced button, you can open the Advanced Delivery dialog box (Figure 15-12), where you can configure additional delivery options such as

Figure 15-12: Configuring advanced delivery options

• Maximum Hop Count The maximum number of remote SMTP hosts allowed to relay an outgoing message as it travels toward its destination. If this number is exceeded, delivery fails and an NDR is returned.

• Masquerade Domain This replaces the local domain in the From: line of outgoing messages with something different to hide the source domain. This only occurs on the first hop the message traverses.

• Fully-Qualified Domain Name The FQDN for the SMTP server is obtained automatically from the Computer Name tab of System in Control Panel, but it can also be configured as something different (you need to do this, for example, on a stand-alone SMTP server). Your SMTP server must also have a resolvable FQDN (one that can be resolved by a name lookup on a DNS name server), or it will be unable to receive incoming mail. This includes both an A record and an MX record in the database on the name server. Contact your company’s ISP to ensure their DNS administrator updates their name server’s database with these two records for your SMTP server.

• Smart Host This is another SMTP host through which outgoing messages are routed (unless a remote domain has been configured to override this setting for that remote domain). You can also configure your server to attempt direct delivery to the remote host before trying the smart host instead. You can specify a smart host using either its FQDN or IP address, but if you use an IP address, be sure to enclose it with square brackets (as in [204.63.144.8]), or your outgoing mail will end up in the \Badmail folder!

• Perform Reverse DNS Lookup on Incoming Messages Reverse DNS lookup ensures that incoming messages are coming from real domains and not fake domains that have been forged by spammers. However, this is a costly process that significantly slows the performance of your SMTP server and it’s generally not a good idea to enable this setting.

The final delivery settings you can configure are on the LDAP Routing tab (Figure 15-13). With these settings you can configure your SMTP server to contact a directory service such as Active Directory to try and resolve e-mail addresses from names of senders and recipients. For example, if you wanted to send a message to user Bob Smith in the mcgraw-hill.com domain, you would normally have to address your message to something like [e-mail]. By enabling LDAP routing for your server, however, you can address your message to Bob Smith instead and have Active Directory (or some other LDAP directory service) resolve the name Bob Smith into its associated e-mail address [e-mail]. For more details on how to configure this tab, see IIS Help.

Figure 15-13: Configuring LDAP routing settings

SMTP Domains

SMTP domains, also called “service domains,” are DNS domains that organize messages for delivery. When you install the SMTP service, the Default SMTP Virtual Server has a single domain called the default domain (Figure 15-14). The default domain is a local domain that cannot be deleted, and it stamps incoming messages from addresses that don’t have a domain. The name of the default domain is generated automatically from the Computer Name tab of System in Control Panel, but you can rename it by right- clicking it in IIS Manager and selecting Rename.

Figure 15-14: Displaying the default SMTP domain

To configure the default domain, right-click it and select Properties (Figure 15-15). This properties sheet lets you view or modify the location of the \Drop folder for your server, which is the location where incoming mail for your domain (here, mtit.com) is deposited. By selecting the check box for Enable Drop Directory Quota, you can limit the size of the \Drop directory to ten times the maximum message size allowed, or 20MB by default.

Figure 15-15: Configuring the default SMTP domain

Local vs. Remote Domains

I just mentioned that the default domain is a local domain. The SMTP service uses two types of domains:

• Local domain DNS domains that can receive incoming messages addressed to the domain and place them in the \Drop folder. In Figures 15-14 and 15-15, the domain mtit.com is a local domain serviced by the Default SMTP Virtual Server.

• Remote domain DNS domains managed by specific remote SMTP hosts. An example is the server smtp.mcgraw-hill.com, which manages SMTP forwarding for the mcgraw-hill.com DNS domain. By default, when you install the SMTP service on IIS, the Default SMTP Virtual Server has no remote domains configured. We’ll look at why and how to create and configure remote domains in a moment.

Alias Domains

In addition to the default domain (of which there can only be one per SMTP virtual server), the other type of local domain you can create is an alias domain. Creating alias domains lets you create secondary domains that point to your default domain and use the same \Drop directory. Incoming messages addressed to an alias domain are stamped with the name of the default domain. This way, for example, incoming messages addressed to recipients in the mtitworld.com (alias) domain can be accepted by the server and placed in the \Drop folder for the mtit.com (default) domain. This allows your SMTP server to receive mail addressed to recipients in more than one DNS domain.

Creating and Configuring Domains

To create a new domain, right-click the Domains node under Default SMTP Virtual Server and select New | Domain. This starts the New SMTP Domain Wizard (Figure 15-16), which can create either alias or remote domains.

Figure 15-16: Creating a new SMTP domain

To create an alias domain, select Alias, click Next, specify the DNS name (such as mtitworld.com) of the additional domain you want your default domain to handle incoming messages for, and click Finish. Don’t bother opening the properties sheet for your alias domain, as it has no settings to configure.

Creating a remote domain is almost as easy, but why would you want to? The main reason is that you can override some of the default delivery settings for your SMTP virtual server and specify additional advanced delivery settings by creating and then configuring remote domains. For example, you might do this for specific DNS names you frequently send messages to.

Now you’ll create a remote domain for the domain mcgraw-hill.com, pretending that you (like I do) frequently send messages to users in that domain. In the wizard, select Remote, click Next, specify mcgraw-hill.com as the name of the remote domain, and click Finish. Now open the properties sheet for the remote domain to see the delivery settings you can configure (Figure 15-17).

Figure 15-17: Configuring a remote domain

Using the General tab for your remote domain you can:

• Click the Outbound Security button and configure authentication methods for outbound messages being sent to this remote domain that are different from those methods configured at the virtual server level.

• Override the default no relay setting at the virtual server level and allow relaying of incoming messages addressed to this domain.

• Begin an SMTP communications session using the HELO command instead of EHLO. This allows your server to tell an SMTP host in the remote domain that it supports ESMTP (SMTP Extensions), an advanced form of SMTP that has additional features beyond RFCs 821 and 822.

• Specify the routing method for sending messages to the remote domain. You can either configure the remote domain so that messages sent to it by your server use DNS to look up the SMTP host servicing the remote domain so it can forward the messages directly to the host, or configure it to use a designated smart host if this provides more expedited delivery.

In addition, selecting the Advanced tab of the remote domain properties sheet allows you to configure your SMTP server to hold mail for the SMTP host servicing the remote domain. This is useful if the host connects to the Internet only occasionally (for example, using a modem) to download mail addressed to users in its domain. In this case, the host first establishes an Internet connection and then issues an ATRN command to your SMTP server to say, “I’m online! Start delivering any messages you’ve queued up for my domain!” The remote host must also be configured to supply suitable credentials in this kind of situation.

Testing the SMTP Service

I’ll finish this discussion of the SMTP service by having you test to see if you can send messages successfully. You’ll try this two ways:

• Composing a message using Notepad and saving it directly into the \Pickup folder of your Default STMP Virtual Server.

• Using a Telnet client to connect directly to the server on TCP port 25 and type the message line by line until it’s finished and sent.

Creating and Sending Messages Manually Using Notepad

First, open Windows Explorer and select the C:\Inetpub\mailroot\Queue folder in the left pane to view the contents of the folder, which should be empty initially. Then open Notepad and create a text file similar to the following. Where [e-mail] occurs in the message, you should replace it with a valid e-mail address of your own. Note the blank line between the message headers and message body: this is required.

x-sender: [e-mail] x-receiver: [e-mail] From: [e-mail] To: [e-mail] Subject: Just a test Hi there, hope you had a great vacation!

Now select File | Save and save your message as test.txt in the C:\Inetpub\mailroot\Pickup directory on your IIS machine. Immediately switch to Windows Explorer and you should see something like this in the \Pickup folder:

NTFS_984b42365c005401aad550001.EML

If you open this file in Notepad, it will look something like this:

Received: from mail pickup service by esrv220b with Microsoft SMTPSVC;     Thu, 23 Jan 2003 02:01:21 -0600 From: [e-mail] To: [e-mail] Subject: Just a test Message-ID: <ESRV220BC8wSA1XvpFV00000009@esrv220b> X-OriginalArrivalTime: 23 Jan 2003 08:01:21.0035 (UTC) FILETIME=[9DB1F5B0:01C2C2B5] Date: 23 Jan 2003 02:01:21 -0600 Hi there, hope you had a great vacation!

In a few moments, the file should leave the queue and be forwarded to the SMTP host that manages the mtit.com domain (or whatever domain your e-mail address belongs to). Open your mail client; you should see the message in your Inbox.

Creating and Sending Messages Manually Using Telnet

Open a command prompt on your server, type telnet, and press ENTER to start your Telnet session. (Be sure to type set localecho so you can see your keystrokes.) Then type open localhost 25 to connect to port 25 (the SMTP service) on your server, which should respond with something like

220 smtp.mtit.com Microsoft ESMTP MAIL Service, Version: 6.0.3718.0 ready at Thu, 23 Jan 2003 02:15:30 -0600 Now type helo me to begin submitting a message, and the server will respond with250 smtp.mtit.com Hello [127.0.0.1] 

Type mail from:[e-mail] to create the From: header for your message, and the server will respond with

250 2.1.0 [e-mail]....Sender OK

Type rcpt to:[e-mail] to create the To: header for your message, and the server will respond with

250 2.1.5 [e-mail]

Type data, and the response will be

354 Start mail input; end with <CRLF>.<CRLF>

Type the following lines:

Subject:Another test Hi Mitch: I'm coming back to work tomorrow, had a great vacation! Bob

To indicate to the server that this is the end of your message, press ENTER, type . (a period), and press ENTER a second time. The server will respond with something like

250 2.6.0 <[e-mail]> Queued mail for delivery

Type quit to end your Telnet session with the server, and check the Inbox of your mail client to see if the message has arrived. If you want to learn more about SMTP commands such as HELO, DATA, and QUIT, read RFCs 821 and 822, which define the SMTP specification.

Tip 

As an additional exercise, try composing and sending a message to a nonexistent domain and see what your SMTP server does with it!