Recipe7.4.Creating an SMTP Connector

Recipe 7.4. Creating an SMTP Connector

Problem

You need to create a new SMTP Connector.

Solution

Using a graphical user interface

Open the Exchange System Manager (Exchange System Manager.msc).
Ensure that you have enabled viewing of administrative and routing groups (see Recipe 7.3).
Expand the organization Administrative Groups target administrative group Routing Groups target routing group.
Right-click the Connectors container and select New SMTP Connector.
If this connector should forward all outbound traffic to a smart host, select Forward all mail through this connector to the following smart hosts and enter either the IP address or fully-qualified domain name of the smart host. IP addresses must be in brackets. You can include multiple values by separating them with commas or semicolons.
Click Add and add at least one virtual server as a local bridgehead.
On the Address Space tab, click Add, select the address type from the list (usually SMTP), and click OK. Enter the domain name for the address space and the routing cost for this connector. A domain name of * matches all domains. Click OK.
Select the scope for this connector: Entire organization or Routing group.
Click OK to create the new connector with default settings. If you wish to change these defaults, right-click the new connector object, select Properties, and make your desired changes.

Discussion

The Exchange 2000 SMTP implementation provided a large improvement over the Internet Mail Service SMTP implementation that was included in Exchange 5.5. It solved many interoperability problems that could affect Exchange's ability to communicate with other SMTP implementations. It also added support for several standard extended SMTP verbs and keywords:

8BITMIME: Enables 8-bit message bodies
ATRN
ETRN
TURN: Enables message queuing and retrieval
BINARYMIME
CHUNKING: Enables streaming data delivery
ENHANCEDSTATUSCODES: Enables enhanced SMTP status codes
PIPELINING: Enables SMTP verb streaming

Exchange 2000 does not provide its own SMTP implementation; rather, it extends the SMTP service in IIS. Consequently, you need to be more aware of the tighter integration between Exchange and the underlying Windows operating system, as changes you make to the SMTP service in IIS can affect your Exchange organization. Exchange takes over the default SMTP virtual server unless you configure alternate virtual server instances for it to use; you generally should not need to.

You do not need an SMTP connector to receive and send Internet mail in an out-of-the-box Exchange 2000/2003 organization, although MS KB 294736 gives a list of reasons why you would need one. The default Exchange transport is SMTP and the default SMTP virtual server will accept incoming connections on all interfaces; as long as your DNS MX records point to an Exchange machine and your firewall and IPSec policy settings permit, you can receive SMTP connections. If you do not have an SMTP connector in your organization, or an IMS instance in a mixed-mode organization, then each Exchange server will use the settings of the underlying SMTP virtual server when it receives mail that is not destined to a recipient in your organization's address space. By default, this means it will perform an MX lookup for the recipient domain in DNS and attempt to send the message directly. If the underlying virtual server is configured to use a smart host, the Exchange server will hand the message to the designated machine.

You change this behavior when you add an SMTP connector, with a scope of either the routing group or the entire organization. The scope allows you to fine-tune your specific routing situation and control which routing groups can use a given connector. One scenario when this capability is useful is to ensure that branch offices use their own local Internet connection for SMTP mail instead of routing through the organization's WAN links to a central link. The connector must be bound to one or more local bridgehead servers within its routing group; each virtual server may be bound separately, permitting you to segregate traffic routing responsibilities through your virtual server definitions. Each SMTP connector must have one or more address spaces defined; the default address space "*" refers to any domains not otherwise defined by membership to the organization or by another connector. Multiple connectors can have the wildcard address space; Exchange servers will use the one that has the lowest routing cost from their location. SMTP connectors can also use DNS-based lookups to intelligently route outbound mail or forward traffic to a smart host. If the configuration of the bound virtual servers and the SMTP connector disagree, the connector wins.

There is no provision for preventing incoming mail through a specific SMTP connector in the Exchange management tools. To prevent a particular Exchange server from receiving incoming connections from the outside world, you will have to apply IPSec policy filters to one or more of the interfaces on the machine (Recipe 10.3 shows how to enable IPSec policies between back- and front-end servers, but you can adapt the same principle to create packet filters), use an external packet filtering firewall, or re-point the DNS MX records to another host record as discussed in Recipe 7.25.

Unlike the Exchange 5.5 Internet Mail Service (IMS), SMTP connectors can be used to connect routing groups without any loss of functionality. Within the same organization, SMTP connectors will pass the extended message properties (as did IMS), make use of full Active Directory-aware Kerberos authentication, and transmit organizational system messages and routing updates. Unlike RGCs, you can restrict the address space that a particular SMTP connector will service, even if it is space within your Active Directory forest. If you do this, ensure that your machines have a valid route to the affected address space or you will be troubleshooting message delivery failures.

Exchange 5.5 allowed you to authenticate SMTP connections using basic (plaintext) authentication; Exchange 2000 expanded this to permit Kerberos and NTLM as well. Although Exchange SMTP authentication follows the appropriate RFCs and interoperates with all compliant clients, it does not support some of the cryptographic authentication methods used by other mail servers, such as DIGEST-MD5 and CRAM-MD5; use of these methods requires the client's credentials to be stored using a reversible encryption method. Active Directory does permit user accounts to use reversible encryption, but this functionality has not been extended to Exchange to permit the use of these methods. Any mail system (client or server) that wishes to protect its authentication credentials with an Exchange system must support NTLM or Kerberos; in practice, you will usually end up using NTLM authentication, as Kerberos authentication requires both systems to be in the same Kerberos realm or have a cross-realm trust in place.

When you are using SMTP connections to bridge two Exchange organizations (Active Directory forests), you may have issues getting address expansion to work properly when messages are submitted anonymously in one organization and routed into the other. The way to fix this is to create two users, one in each organization, that have Send As permissions (see Recipe 5.21 for more details). These accounts are then used in conjunction with the cross-forest SMTP connectors to authenticate the connection. MS KB 828770 (Resolve Anonymous Senders Functionality in Microsoft Exchange Server 2003) has more details.

SMTP connectors share many characteristics with RGCs (see Recipe Recipe 7.3). There is a distinct lack of guidance for creating SMTP connectors programmatically. Like RGCs, SMTP connector objects reside in the CN=Connections, CN=<Routing Group>, CN=Routing Groups, CN=<Admin Group>, CN=Administrative Groups, CN=<yourorg>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<Domain> container. SMTP connectors are objects of class msExchRoutingSMTPConnector. The MSDN web site provides a reference for the specific properties of these classes.