9.9 Creating an SMTP connector

 < Day Day Up > 



The RGC uses SMTP, so why is there a separate SMTP connector? The answer is simple: There is a huge SMTP world out there where Exchange is a relatively small presence today. People want to communicate with other SMTP domains, and they would like to do so in as functional a manner as possible. In addition, RGCs can only connect to other routing groups and cannot send email to an SMTP server that is outside the Exchange organization, so another connector is required to link Exchange to the wider SMTP world. Exchange 2003 includes an Internet Mail Wizard to help you create SMTP connectors, but it is more fun to do the work yourself.

As with the RGC, the SMTP connector runs under the context of an SMTP virtual server. The RGC uses the Exchange configuration data held in the AD to route messages, but Microsoft designed the SMTP connector to use standard SMTP routing techniques such as the Mail Exchanger (MX) records held in DNS. You should, therefore, use an SMTP connector whenever you want to route messages to a "smart host" system, and use MX records as the basis for routing or to send messages outside Exchange (including to the IMS running on older Exchange servers).

Figure 9.33 shows a good example of an SMTP connector in action. The connector is configured to send any message to "relay.acme.com." Smart hosts are mail servers that often act as central collection and dispatch points for SMTP mail for an enterprise. You can specify either a fully qualified domain name (as in this case) or a specific IP address to point to the smart host. If you use an IP address, remember to enclose it in square brackets-for example, [22.18.19.20].

click to expand
Figure 9.33: General properties of an SMTP connector.

Bringing messages together to a central point before they are sent outside a company allows for centralized checking for viruses or profanity, as well as verification that users are complying with company standards such as disclaimer text on messages or even that classified information isn't being sent to external correspondents. The Clearswift Enterprise Suite (www.clearswift.com) is a popular example of software that often runs on smart hosts.

Setting up the connector to route all mail to a smart host is the first step toward achieving control over SMTP routing. You can achieve finer control by defining routes for specific domains through the address space property page, where you define the SMTP domains that can be reached through the connector. The default is "*"-meaning that all domains can be reached, but in some cases you might want messages for a specific domain to be handled in a certain manner. Figure 9.34 shows how you configure the address space for a specific domain, in this instance acme.com. With this configuration, the connector is only able to handle messages addressed to a recipient in acme.com, and all other messages will have to find another route.

click to expand
Figure 9.34: Specifying the address space for an SMTP connector.

At the bottom of Figure 9.34, you can see how Exchange controls the scope of a connector. The feature (also available in Exchange 5.5) allows administrators to restrict the availability of a connector to other servers. You can restrict a connector to servers at a location, site, or the organization. With Exchange 2000/2003, you can apply restrictions at either the routing group or organizational level. In our example, the connector is only available to the servers in the local routing group. Setting a scope on an SMTP connector is most useful when several connectors exist in an organization, each of which has very different capacities, possibly because of varying costs of Internet connections via ISPs from country to country. For example, assume that you have two SMTP connectors created in routing groups in Paris and New York. ISP charges are typically cheaper in North America, so if the New York connector ever goes down, you may not want to reroute messages across the Atlantic to Paris, since this would drive up the use of the ISP connection there and might result in heavier fees. In this case, you could set the scope for the SMTP connector in Paris at the level of the routing group. Microsoft built scope control into Exchange for a reason, so it is a good idea to consider this option for every SMTP connector that you create.

The SMTP connector has many advanced properties that you can manipulate, but you can rely on the defaults if you simply want to connect together SMTP-based email systems, or link Exchange to the Internet through a permanent connection. For example, as with the routing group connector, the Delivery Options property page allows you to check the "Use different delivery times for oversize messages" box to tell the SMTP connector to send messages (perhaps over 1 MB) according to a different schedule, which is a reasonable approach to giving priority to "normal" traffic. Of course, there are other ways to allocate different priorities to protocol-based traffic. For instance, Packeteer's (www.packeteer.com) Pack- etShaper product allows you to set bandwidth allocation policies for protocols such as LDAP, SMTP, and HTTP, so you could favor SMTP traffic over HTTP, or vice versa. You can even create special virtual links for applications such as Exchange to use to guarantee bandwidth. These solutions ensure that you can provide a defined quality of service for applications, which can be vital if you sign up for service-level agreements.

Companies that depend on ISPs to provide a message drop service will be happy to find that the SMTP connector is much easier to work with than the Exchange 5.5 IMS. The connector supports all the features required to make a connection to an ISP and pick up messages using the SMTP ETRN or TURN commands (Figure 9.35). Creating a connection between Exchange and an ISP can be a specialized business that requires much more discussion than can be afforded in a book such as this, so those interested in the topic should consult a specialized Web site such as that at www.swinc.com.

click to expand
Figure 9.35: Advanced properties of the SMTP connector.

9.9.1 Encrypted SMTP communications

SMTP messages are sent in plain text, so unless the actual content is encrypted using Exchange advanced security or some other secure scheme, the possibility exists that the data could be intercepted and examined by someone who you'd rather not. The Exchange 5.5 Site connector uses encrypted RPCs, so obviously security is somewhat downgraded when you switch site connectors over to RGCs or SMTP connectors.

The solution is to establish a secure connection for SMTP traffic to flow between the servers. The preferred and recommended solution is to do this with IPSec (which you can apply to specific ports or IP addresses), although it is also possible to create an encrypted connection with TLS. However, IPSec incurs far less overhead than a TLS connection and is built into Windows 2000 and Windows 2003; you can apply IPSec to a large number of servers through group policies. An IPSec connection secures all IP traffic across the link, another advantage gained by selecting this approach.

9.9.2 Delivery restrictions for SMTP-based connectors

SMTP provides the foundation for both SMTP and routing group connectors. As shown in Figure 9.36, the Delivery Restrictions property page on a connector defines the set of users who can submit messages to the connector or who the connector will explicitly reject messages from.

click to expand
Figure 9.36: Limiting users on an SMTP connector.

You access the Delivery Restrictions property page by selecting a connector through ESM and then viewing the connector's properties. For the default set of Exchange connectors, the MTA controls the restrictions placed on the X.400 connector, while a combination of the Routing Engine and SMTP service controls the restrictions on routing group and SMTP connectors. As you can see in Figure 9.36, you can use individual mailbox names or distribution groups to define who can use a connector.

Table 9.6: Registry Values to Implement SMTP-Based Connector Restrictions

Value

Meaning

CheckConnectorRestrictions

Set to 1 to enable checks.

IgnoreRestrictionforNullDSN

Set to 1 to ignore restrictions for delivery service messages (such as nondelivery messages). If set to 0, DSNs will be blocked from going across a restricted connector.

Unfortunately, for whatever reason, Microsoft decided that applying restrictions through ESM was not sufficient. To complete the job and make the restrictions effective, you also have to change the registry to instruct the SMTP service that restrictions are in force and tell the Routing Engine that it should validate submitters and recipients. The logic behind this two-step approach is probably that turning on restrictions causes additional overhead for the Routing Engine as it checks names against the restricted list. The Routing Engine validates email addresses against the Active Directory, so it is a bad idea to turn on restrictions on a bridgehead server that is already under load or has an extended connection back to the nearest GC. Remember that Exchange uses the GC to validate names, because the GC holds a copy of all mail-enabled objects in a forest. However, in production situations, bridgehead servers are typically located close to GCs, and many of the names that the Routing Engine needs to check will be in the local directory cache, so the additional overhead is not large.

Two DWORD registry values (Table 9.6) control how checking is performed. Place these values in:

HKLM/System/CurrentControlSet/Services/RESvc/Parameters

Once you have inserted the two values, stop and restart the SMTP service and the Routing Engine service to make the blocks effective. The restart is necessary to allow the two services to recognize that restrictions are in place and read the information about users you want either to permit or bar from using the connector. Once set, the restriction is active for all SMTP-based connectors on a server. You should then test that the restrictions are in place by attempting to send a message from an account on the blocked list. If the block is effective, you will receive a nondelivery notification.

Of course, any change made to the system registry can only influence components that are active on that server. If this is the only server that hosts connectors such as a shared organization-wide SMTP connector, then the block is effective for the entire organization. However, if a message can take multiple routes to get to a destination, then you need to implement the restriction at every bridgehead server along these routes.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net