Intelligent Front-End Hosts for SMTP

7.3

Intelligent Front-End Hosts for SMTP

by Ron Herardian
©1999 Global System Services Corporation (GSS)

This article is the second in a three-part series covering Domino and Internet e-mail. Last month I explained capacity planning issues for Internet e-mail. This month’s article describes front-end solutions that allow centralization of SMTP services and that ease migration to Domino from cc:Mail.

Internet e-mail is not what it used to be. Medium and large sized companies today have to deal with multiple DNS domains, multiple languages (character sets), multiple Internet address formats, migration issues, spam, and directory synchronization issues. Managing Internet e-mail can be complex and companies are often at a loss for ways to deal with these things. The answer, however, is much less complex than the problem: install an intelligent front-end host to process and route inbound Internet e-mail. The power and architectural simplicity of this solution will become apparent as we look at the different problems that are all solved by this solution.

An intelligent front-end solution for SMTP means that inbound SMTP e-mail is received by a mail host that forwards mail to various MTAs or gateways. Typically this means receiving e-mail from the Internet and forwarding it to other systems through a private WAN. The simplest implementation of this kind would use Berkeley sendmail and a simple alias file. A more sophisticated version would do the following:

• Handle e-mail for multiple DNS domains and address formats
• Handle mail spanning multiple languages and character sets
• Handle e-mail migration issues
• Provide industrial-strength anti-spam capabilities
• Synchronize directory information with Domino and possibly other systems

The same host may also serve as an outbound SMTP relay but this is standard functionality in sendmail so we won’t spend any time looking at outbound Internet e-mail. There may be one or many points at which mail exits an organization’s WAN.

In last month’s article I wrote about the rapid growth of Internet e-mail and the challenges that it presents. Rapid growth in Internet e-mail increases the administrative burden and creates pressure to centralize SMTP services. Centralization of SMTP services means that mail hosts must be able to handle multiple Internet domains and languages.
 

Multiple DNS Domains: The Internet Perspective

Nearly every company has to deal with multiple DNS domains. The reason why this is important is that companies want to standardize their Internet address format or limit the number of address formats. First we’ll want to deal with the mechanics of this from the Internet point of view and from the Domino point of view. It is important to note that the SMTP and DNS technologies allow mail for a given domain to be routed only to one primary point for that domain. In general, Internet mail is not routed based on the user ID (an exception is source routing).

From the Internet point of view multiple Internet domains mean multiple MX (mail exchanger) records in the company’s DNS database. In most implementations of bind, the DNS daemon, the ‘database’ is a set of related structured text files containing IP address and host name information so that machines can find each other by name based on which Internet domain they are in (or find names by looking up addresses). In the database various record types are defined for machine addresses, mail exchangers, and other things. The MX records are in the domain database file typically named after the Internet domain name, e.g., GSSNET.DOM. In the file are records in the following format:

@ IN MX 10 mail1.gssnet.com
@ IN MX 20 mail2.gssnet.com

Handling e-mail for multiple DNS domains usually means pointing MX records for more than one domain name to a single host. This host must be able to forward or deliver mail to users whose SMTP addresses contain the various domains handled by the company’s mail hosts. One way to see what mail exchangers are configured in DNS is to use the nslookup program, a command line utility available on most UNIX systems:

nslookup -type=MX gssnet.com

The output should look something like this:

gssnet.com preference = 10, mail exchanger = mail1.gssnet.com
gssnet.com preference = 20, mail exchanger = mail2.gssnet.com
gssnet.com nameserver = ns1.gssnet.com
gssnet.com nameserver = ns2.gssnet.com
mail1.gssnet.com internet address = 206.184.139.12
mail2.gssnet.com internet address = 206.184.139.13
ns1.gssnet.com internet address = 209.24.149.41
ns2.gssnet.com internet address = 209.157.102.11

nslookup -type=MX gssnet.com

messagingcentral.com preference = 10, mail exchanger = mail1.gssnet.com
messagingcentral.com preference = 20, mail exchanger = mail2.gssnet.com
messagingcentral.com nameserver = ns1.gssnet.com
messagingcentral.com nameserver = ns2.gssnet.com
mail1.gssnet.com internet address = 206.184.139.12
mail2.gssnet.com internet address = 206.184.139.13
ns1.gssnet.com internet address = 209.24.149.41
ns2.gssnet.com internet address = 209.157.102.11

In this example Internet mail for both the gssnet.com and messagingcentral.com domains is sent to mail1.gssnet.com. Causing mail for multiple domains to be routed to a particular host is a straightforward matter. It’s only a question of editing the right text files and adding or modifying the right MX record entries.

Firewalls

Of course there are other considerations, for example sending mail through a firewall. Typically the front-end host will be place on a DMZ connected to a firewall but not on the outside of the firewall (figure 1).

Configuration for SMTP Relay Host

Of course the diagram in Figure 1 is simplified but it gets at the main issue which is securing internal SMTP services to make them inaccessible to any host other than the SMTP relay or front-end host.

There are so-called e-mail firewall products on the market that provide virus scanning, content checking, anti-spam capabilities and other features but thee present article is not directly concerned with e-mail security at this level.
 

Multiple DNS Domains: The Domino Perspective

From the Domino perspective any domain and any SMTP address can be supported for inbound e-mail and for user from addresses (when users send e-mail outbound). It’s the SMTP addresses that are the main issue. The main thing to remember is that the SMTP address used must match the "Internet/short name" field in the corresponding person document in the Domino NAB, e.g., Super.Human@anyname.com, is valid for user Ron Herardian when this address appears in Ron Herardian’s Internet "Internet/short name" field.

An agent can be used to automatically populate the "Internet/short name" field based on which Domino OU the user belongs to. When writing agents of this kind keep in mind that addresses must be unique thus checking for duplicates is important. For example in applying an address scheme such as ‘First_Last’ it would be easy to forget that in Domino "First Last/Sales/GSS" and "First Last/Exec/GSS" are unique whereas the two common names are identical.

The default address format for SMTP from fields includes Domino NAB information but this results in unnatural (but functional) SMTP addresses such as First_Last/CAM/Lotus@lotus.com. The problem becomes more apparent when things are longer, e.g., LongFirst_LongLast/LongOU1/LongOU2/LongOU3/ROOT@longhost.longdomanname.com, which to most users would be incomprehensible.
 

Multiple languages and Character Sets

In currently deployed versions (prior to R5) the Domino SMTP MTA could handle only one character set per MTA. Messages piped through the wrong MTA would appear garbled or special characters would be lost. In theory MIME encoding of Internet message bodies would avoid using the wrong character set but the real world in not very theoretical. In practice we might find a Pan European version of Windows 95 configured for Lithuania running an international English version of Lotus Notes: so what’s the correct character set for Internet messages? You see the problem.

In Domino R5 the issue is not completely solved but the SMTP MTA gains the ability to forward mail to the appropriate MTA. The intelligent front-end solution solves this problem by routing inbound mail directly to the appropriate MTA or gateway.
 

E-mail Migration Issues

When migrating from cc:Mail to Domino use of both the SMTP MTA and CCMTA are necessary. Unfortunately, routing cc:Mail messages to and from the Internet via the cc:Mail and SMTP MTAs has been a less than perfect solution in the past, significantly because of cc:Mail MTA issues. Usually, companies try to consolidate SMTP services on one side or the other during migration.

In theory consolidation of SMTP services on Domino is the cleanest configuration, however, in both configurations the MTAs are dependent on each other.

Since Domino is the migration direction so consolidation of SMTP services on Domino is intuitive. Going with this solution implies that the amount of mail passing through this relatively inefficient route will be systematically reduced and ultimately eliminated when migration is completed. The negative impact of any problems related to using multiple MTAs will be reduced and these problems will ultimately be eliminated when migration is complete because the cc:Mail MTA will no longer be needed. In any case, consolidation of SMTP gateway services on Domino is more efficient than consolidation of SMTP gateway services on cc:Mail.
 

Enter the Intelligent Front-End Host

The best solution is to maintain independent SMTP services for cc:Mail and Domino during migration. The cc:Mail system can continue to use its existing gateway and Domino users use the SMTP MTA to send and receive mail from the Internet. At the same time routing Domino main to and from the Internet via a cc:Mail-based SMTP gateway can be more problematic than going the other way. The only problem with using separate SMTP services for the two systems during migration is that inbound mail can only be routed to the SMTP gateway for cc:Mail or to the SMTP MTA: enter the intelligent front-end host.

An SMTP host that can route mail based on the user ID (instead of just the domain) can send mail for Domino users to the MTA and mail for cc:Mail users to the cc:Mail SMTP gateway. This removes the dependency of the MTAs on one another so that Internet mail is autonomous for both systems. With an intelligent front-end host inbound messages for cc:Mail users are routed directly to the cc:Mail SMTP gateway while inbound SMTP messages for Domino users are routed directly to Domino.

The intelligent front-end host is the most efficient alternative and it eliminates dependency of SMTP and cc:Mail MTA services. The intelligent front-end host also provides a logical load distribution (it does not impose the burden of Internet mail for cc:Mail users on Domino or vice versa). The core technology of the front-end host solution is essentially sendmail which is known for its scalability and reliability. Using a sendmail (or derivative) as an SMTP relay for inbound mail improves both capacity and reliability is recommended by GSS for use with all SMTP gateways including the Domino SMTP MTA.
 

Directory Synchronization

In order for the front-end host to route mail to appropriate MTA or gateway it must know which SMTP domains and user IDs go with which MTA or gateway. This means that some type of directory must be used. If a directory is used it should be synchronized with the Domino NAB. We use Netscape Directory Server and Messaging Server to built front-end host solutions and synchronize the NAB one-way with the Netscape LDAP directory (using GSS LDAP Synchronizer). Domino is not used as the LDAP server because it does not support storage and retrieval of arbitrary data.

Although many versions of sendmail can be used as to front-end SMTP we prefer to use Netscape Messaging Server because of its LDAP-based routing and easy to configure SMTP routing tables. We also prefer Netscape because of its server plug-in capability and built-in powerful anti-spam capabilities: the front-end host is the correct place to eliminate spam, not at the MTA.
 

Summary

Several practical problems can be solved by implementing an intelligent front-end host for SMTP. This solution can help to address issues such as multiple Internet domains and SMTP address formats, multiple languages and character sets, coexistence and migration issues for cc:Mail and Domino, and spam. The core technology is LDAP-enabled SMTP and an LDAP directory can be synchronized with the NAB. For larger companies some type of front end host is necessary and increasingly medium-sized companies need this type of solution in order to support centralized processing and routing of Internet e-mail for a number of different business units.

About GSS

Global System Services Corporation (GSS) is the leading provider of consulting and professional services for large-scale and distributed infrastructure systems such as email and messaging, directory services, groupware, and wireless solutions. GSS customers include Fortune 500 companies, large services providers and telecom companies, government agencies, major messaging product vendors, and innovative technology startups.

GSS provides a complementary suite of services including strategic technology consultation and competitive vendor and product analysis, product and system architecture and design, system development deployment, customization, and testing, technical support, email migration, and other IT services. GSS has been directly responsible for some of the largest global systems and solutions and counts as customers many of the largest companies in the world.

From its offices in the Silicon Valley California, GSS delivers services and solutions to customers worldwide through a network of mobile consultants and qualified GSS Affiliates. With industry certified professionals on staff, GSS is a Qualified Lotus Business Partner, a Certified Microsoft Solution Provider (MCSP), a Principal Partner in the Sun Partner Advantage program and a member of the Sun Software Partner Council, as well as a member of key industry organizations.

Contact GSS

©1995-2005 by Global System Services Corporation (GSS). Portions of this material are copyright ©1995-1999 by Ron Herardian