Configuring SMTP for Both Authenticated and Anonymous Connections at Microsoft

Note on IT

To reduce administrative overhead, the Microsoft Information Technology (Microsoft IT) group needed to change the way Microsoft® Exchange Server 2003 makes internal Simple Mail Transfer Protocol (SMTP) connections. Microsoft IT set the SmtpIpRestrictionFlag attribute to 1 to configure an SMTP virtual server to allow anonymous connections from an explicit list of IP addresses, yet allow all authenticated connections from other Exchange servers.

Download Note on IT 515 KB Microsoft Word file Document Definition A Note on IT is a short, technically deep drilldown on a specific topic related to Microsoft IT and is usually associated with an existing IT Showcase document. A Note might illustrate how Microsoft IT performs a specific operational task step by step or configures a hardware device or software application. It might also relate details of a best practice or contain frequently requested information about Microsoft IT’s operations. Intended Audience Microsoft Exchange Server 2003 administrators Products & Technologies • Exchange Server 2003 • SMTP

On This Page

	Introduction
	Situation
	Changed Behavior
	Implementation

Introduction

Many messaging environments use internal gateway servers for routing messages that originate from a variety of sources. These sources may include servers within the local e-mail environment, application servers that are outside the e-mail environment, and servers from other e-mail environments. When an environment uses a variety of technologies, permitting anonymous connections is often necessary because authentication between all of the hosts is not always possible or feasible. Although the option exists to simply allow all anonymous connections, doing so creates an unmanaged environment. Conversely, managing lists of permitted connections can lead to unwanted administrative overhead.

Microsoft IT treats SMTP transport in its Exchange infrastructure as a valuable resource, so the group controls and regulates access to that infrastructure. In some cases, Microsoft IT needs to allow some specific SMTP clients to connect anonymously, but still allow connections from all authenticated clients.

In an environment that uses Microsoft Exchange 2000 Server, if even a single Internet Protocol (IP) address is added to the permit-to-connect list on an SMTP virtual server, no other clients (anonymous or authenticated) can connect. For authenticated clients (such as other Exchange servers) to connect, their IP addresses must be added to the permit-to-connect list. In an enterprise environment, this work can amount to dozens or even hundreds of IP addresses. Because the changes are not shared—they are configured on each virtual server—the problem is compounded if there are multiple SMTP virtual servers.

Microsoft IT wanted to ensure that only authorized entities (such Exchange servers or specific SMTP clients) can submit e-mail directly to the group's internal Exchange transport, as shown in Figure 1.

Figure 1. Topology diagram of the SMTP requirements in Microsoft IT

As part of its effort to provide security for the SMTP routing environment without incurring a significant amount of administrative overhead, Microsoft IT needed to change the behavior of its SMTP virtual servers. The changes that Microsoft IT implemented cause an SMTP virtual server to allow anonymous connections from an explicit list of IP addresses, yet allow all authenticated connections from other Exchange servers.

This document is intended for Exchange administrators. It assumes that the reader has working knowledge of Microsoft Windows Server™ 2003, Microsoft Exchange Server 2003 SMTP and routing concepts and various system tools. This document does not elaborate on the details of any system tool, except as necessary to complete the tasks within.

Note: For security reasons, the sample names of any forests, domains, internal resources, organizations, and internally developed applications and files used in this document do not represent actual names used within Microsoft and are for illustration purposes only. In addition, the contents of this document describe how Microsoft IT runs its enterprise data center. The procedures and processes in this document are not intended to be prescriptive guidance on how to run a generic data center and may not be supported by Microsoft Customer Support Services.

Top of page

Situation

Microsoft IT supports several forests in its Active Directory® directory service architecture. The majority of Microsoft employees use the primary corporate network forest. Production users populate many of the smaller forests.

In some situations, Microsoft IT needs to allow anonymous connections from a finite number of e-mail clients, yet also allow all authenticated connections, regardless of their source IP addresses. Enabling this behavior provides the flexibility necessary for a single server to be used as both an interforest and an intraforest hub without incurring an excessive amount of administrative overhead.

For example, Microsoft IT uses the MSFT-HUB-xx servers as SMTP bridgeheads between the various Microsoft IT–managed forests and as interrouting group hubs. If, as part of an effort to provide security for the routing environment, Microsoft IT adds the IP addresses of designated SMTP bridgehead servers located in the nonprimary corporate network forests to the permit-to-connect list, only those servers will be able to connect. None of the Exchange servers in the primary forest will be able to connect to the MSFT-HUB-xx servers unless their IP addresses are also added to the list. Maintaining the list therefore requires a significant amount of administrative overhead. Because the Exchange servers for the primary corporate network forest are already trusted entities by virtue of their authenticated status, adding them to the permit-to-connect list is redundant.

Two out-of-the-box configuration settings allow connections to an SMTP virtual server, as shown in Table 1.

Note: A client may be able to connect to an SMTP virtual server, but whether the client is able to submit e-mail to the server depends on other settings, such as the supported domains and the supported authentication methods.

The flowchart shown in Figure 2 illustrates the logic used by the SMTP virtual server when connections are established and messages are submitted.

Figure 2. Original SMTP connection workflow methodology

The default behavior illustrated in Figure 2 does not take advantage of the authenticated SMTP status of Exchange servers in the organization and does not grant those authenticated Exchange servers the ability to submit e-mail to the protected SMTP virtual server.

Top of page

Changed Behavior

The configuration change that Microsoft IT made as a solution allows the SMTP virtual servers to be configured such that the IP restrictions are applied only to anonymous connections. The restrictions do not affect servers that connect and authenticate.

Because authentication occurs after a connection is established, the configuration change alters the underlying behavior of the SMTP virtual server. All connections are initially permitted; however, if the client's IP address is not on the list and the client does not authenticate before attempting the mail from command, the connection will end and will cause a 5.7.3 SMTP response ("Client was not authenticated").

Microsoft IT accomplished the configuration change by modifying the Microsoft Internet Information Services (IIS) version 6.0 metabase parameter on the server running as the protected SMTP virtual server. By creating the metabase key SmtpIpRestrictionFlag=1, Microsoft IT modified the behavior for allowing connections to an SMTP virtual server as shown in Table 2.

_{* Allowed message submission does not guarantee successful message acceptance. Messages submitted may be subject to further restrictions and filtering.}

Figure 3 illustrates the connection control setting referenced in Table 2. For example, in the following scenarios, anonymous SMTP connections from the host 10.168.0.1, as well as authenticated SMTP connections, will be accepted.

Figure 3. The IP addresses specified for allowing connections

Setting the flag affects only which clients are allowed to attempt to submit e-mail. The setting does not alter the SMTP virtual server’s behavior concerning the treatment of anonymous relaying versus authenticated relaying. For example, submissions by means of an anonymous connection still abide by the Sender Display Name Resolution, Sender ID, Sender/Recipient Filtering, and Exchange Intelligent Message Filter settings on the server; they do not bypass these functions.

The flowchart shown in Figure 4 illustrates the logic used by the SMTP virtual server when connections are established and messages are submitted.

Figure 4. Revised SMTP connection workflow methodology

Top of page

Implementation

There are two steps for implementing the change:

By default, the SmtpIpRestrictionFlag attribute does not exist in the metabase. However, an administrator can use IIS Metabase Explorer to create a new record and change the attribute value. IIS Metabase Explorer is part of the IIS 6.0 Resource Kit Tools collection and can be installed from http://www.microsoft.com/downloads/details.aspx?FamilyID=56FC92EE-A71A-4C73-B628-ADE629C89499&displaylang=en. The user interface (UI) of IIS Metabase Explorer is similar to the UI of Microsoft Windows® Explorer.

To create the record and set the value:

1.	Open IIS Metabase Explorer and connect to the server to be changed.
2.	Browse to the container of the SMTP virtual server to be changed.
3.	On the Edit menu, point to New, and then click DWORD Record.
4.	In the New Record dialog box, in the Record Name or Identifier list, select SmtpIpRestrictionFlag, as shown in Figure 5. Figure 5. New Record dialog box in IIS Metabase Explorer Note: The numeral 1 in the Owner Key listing of Figure 5 indicates the number of the SMTP virtual server.
5.	Click OK to save the new record.
6.	Double-click the new record to open the properties. The SmtpIpRestrictionFlag attribute has two possible values: • 0: Enables authenticated or trusted IP address connections (original behavior). The connecting server must be on the IP list regardless of the authentication. • 1: Enables both authenticated connections and anonymous connections from IP addresses listed in the Connection Control settings.
7.	Change the attribute value to 1 (as shown in Figure 6), and then save the changes. Figure 6. Changing the value of the SmtpIpRestrictionFlag attribute in IIS Metabase Explorer

The SMTP server can now allow authenticated connections in addition to those on the permit-to-connect list.

Top of page