FAQs / Exchange 5.5 / How to Configure the IIS SMTP Service as a Mail Relay

01

The following describes how to support an Exchange Server Organization located behind a Microsoft Proxy Server with the SMTP server included with Internet Information Server 4.0.

Background

Microsoft Proxy Server is designed to effectively block traffic destined for inbound resources in an intranet. Traditionally, implementations of Exchange in an intranet have relied on one of two methods to insure the integrity of corporate messaging (1) third-party solutions, such as sendmail, to relay messages to the Exchange Server or (2) Binding the Exchange Server SMTP Port (25) to the Proxy Server.

The release of Internet Information Server(IIS) 4.0 in the NT 4.0 Option Pack provides another solution. Unfortunately the configuration of this server is not well documented.

IIS/SMTP Server Overview

Internet Information Server ships with a basic SMTP Server. As explained by Microsoft, the intent was to provide SMTP services to application developers. By including this service Microsoft provided a way for the developer to send and deliver SMTP messages. This is further enhanced by the inclusion of CDONTS which provides the API set for the development mail-enabled applications.

An additional “feature” of this server is the lack of mailbox support. This is also intentional. A single mailbox exists on the server to support inbound mail.

Administrators of Exchange Server will find some similarities between the hierarchy of the IIS/SMTP Server and Exchange Server. It is described in the following paragraphs.

The SMTP Server is installed in the same hierarchy as the IIS Server. By default a mailroot directory is created containing the directory structure required for the operations of the server. Of importance in the setting up of the server are the following directories.

• Pickup – This directory operates the same as on the Exchange Server. This directory will be discussed further in the section on testing the configuration.
• Queue – This directory is used for mail delivery. This directory should be empty if the server is functioning correctly; however, if you are experiencing problems with the server this is the first directory that should be checked. Two types of files exist in this directory, .eml and .rtr. The .eml files are the actual messages as they are in transit. The .rtr files contain status information about their associated messages.
• Badmail – This directory contains messages that can not be delivered for some reason.

Configuring the IIS/SMTP Server

The Microsoft Management Console, MMC, is used to configure the server. The default view of the Default SMTP Server in the MMC has two options, “Domains” and “Current Sessions” Local

The definition of domain is different than that in Exchange Server. A domain in the context of the SMTP server describes the boundaries for mail delivery. At least one domain should exist in the default installation. That domain should/must equate to the machine the IIS/SMTP server is running on (i.e., machine.domain.com). This one step is critical to the configuration. By default this domain is “local.” In regards to the SMTP server, local again relates to delivery boundaries. A better way of understanding this is to ask yourself “If I’m going to use this machine to accept mail then it has to know it and accept mail for that domain. So I need to let it know.” Before you jump to conclusions, read the next section on Remote domains. If you’ve defined aliases for your machine they can be defined here as local as well to insure proper delivery.

A wizard is used to configure this local domain and there is really no configuration that needs to be modified unless you want to change the location the mail is delivered to.

Additional local domains are automatically configured and have the same options as the Default local domain.

Remote

One or more Remotes domain must be established to let the IIS/SMTP server know how the mail should be handled. This should be the domain(s) the Exchange server is handling. As with the Local domains you can define as many as you want, but you need to define ALL of the domains your Exchange server will handle. This configuration is also done through a wizard, but there are a few options that need to be configured.

• Route Domain – This defines the server the IIS/SMTP server should route all mail destined for this remote domain to.
• Allow incoming mail to be relayed to this domain – By default, the IIS/SMTP server will not allow relay (and that is a VERY good thing), so to let it know you want the mail for your domain sent to the Exchange Server be sure you check this box. There are no other options (default) that need to be set in this dialog.

Default SMTP Site Properties

Site-wide configuration options are established here. And some really interesting options can be set.

SMTP Site

If you are familiar with the configuration of IIS this page should be fairly familiar. The one suggestion I have for this page is to enable logging. I typically use the following parameters.

New log Time Period	Extended Properties
Weekly	Date Time Client IP Address User Name Sever IP Method URI Stem HTTP Status Protocol version

Other options can be chosen as needed; however these provide good diagnostics when doing some troubleshooting.

Operators

Another IIS feature that does not have to be tweaked.

Messages

The only area that needs to be completed on this tab is “Send a copy of non-delivery report to:” You will need to define a valid user account on your Exchange or SMTP server to forward these NDRs.

Delivery

This is the most critical section of the Server setup. And where mistakes can be made. There are two possible configurations that can be supported by this server. Depending on how your “Internet” domain is structured will determine which you will use.

The areas that must be addressed are:

• Masquerade domain – By default this is the domain supported by your Exchange Server. If left blank all mail will be delivered using the “Local domain” defined earlier.

  NOTE: It does appear and it is true that you can relay mail from this server using a bogus domain name; however the SMTP does maintain all of the header information for the return route to the originating domain. So this can not be used for anonymous sending of mail.

• Fully qualified domain name – Some implemented like the mail to bear a distinct name when it is being routed. This field allows you to change the FQDN of the machine being used as the SMTP server. So instead of mail being received from “proxyserver.mydomain.com” it will arrive from (for example) “mailhost.mydomain.com.”
• Smart host – This option allows the SMTP server to forward all mail to a Smart host for delivery. This reduces the burden of DNS resolution from the server. In conjunction with this option is the option to “Attempt direct delivery before sending to a smart host.”

The final configuration option here “Perform reverse DNS lookup on incoming messages” is not suggested to be enabled. This will force the SMTP server to do a reverse lookup on all messages received. This places a significant burden on the machine and should only be used if absolutely necessary.

Directory Security

Additional security can be enabled on the machine using this property pa

Last Updated by Simpler-Webb on 8/7/2003 1:59:40 PM (QID #1219)
Categories: Exchange 5.5/How to Configure the IIS SMTP Service as a Mail Relay |