Complete Contents
Chapter 1 Getting Started With Netscape Messaging Server
Chapter 2 Configuring IMAP and POP Services
Chapter 3 Configuring SMTP Services
Chapter 4 Managing Mail Users and Mailing Lists
Chapter 5 Managing the Message Store
Chapter 6 Security and Access Control
Chapter 7 Working With SMTP Plugins
Chapter 8 Filtering Unsolicited Bulk Email
Chapter 9 Message Routing
Chapter 10 Monitoring and Maintaining Your Server
Chapter 11 Logging and Log Analysis
Appendix A Command Line Utilities
Appendix B Program Delivery
Appendix C sendmail Migration and Compatibility
Appendix D SNMP MIB
Glossary
Messaging Server Administrator's Guide: Message Routing
Previous Next Contents Index Bookshelf


Chapter 9 Message Routing

This chapter describes how a Netscape Messaging Server receives and delivers a message. This chapter contains the following sections:


Overview
The Messaging Server listens for incoming mail on the standard port for SMTP (port 25). Incoming mail can arrive from either a local mail client or a remote server.

 When the Messaging Server receives a message, its Message Transfer Agent (MTA) must determine how to route the message. The routing options include the following:

 Figure 9.1 shows the routes taken by two messages:

Figure 9.1 Mail Routing


Routing Resources
To determine its action, the MTA might reference information from a variety of sources, including the following:

 The MTA checks the directory service to determine if the mail recipient is local or remote. If the recipient is remote, the MTA uses the SMTP routing table and/or the Domain Name System (DNS) server to route the message to another MTA.

The Directory Service

The Netscape Directory Server stores information about the people and resources in your organization. Information about users and user groups is stored in the Directory Server as well as configuration information about the Netscape Messaging Server. Netscape Messaging Server stores information in the Directory Server as LDAP entries to map addresses and route messages.

To route a message, the Messaging Server must determine:

 Each LDAP entry has associated routing and addressing attributes that the MTA uses to determine message delivery or routing options. These attributes are described in Table 9.1. For more information about LDAP object classes and attributes, see the Netscape Directory Server Schema Reference Manual.

Table 9.1 Attributes

Addressing
Description
mail
Identifies the user's electronic mailing address
mailAlternateAddress
Identifies an alternate mail address for the user
Routing
Description
mailHost
Identifies the host on which the account resides
mailRoutingAddress
Identifies the address to place in the envelope when routing a message to this account

The SMTP Routing Table

You can use the SMTP routing table to explicitly specify domains to which the messaging server should direct message processing.

An SMTP routing table entry looks like:

 *.airius.com:*

 In this example, messages for any subdomain inside the top-level domain airius.com are processed by the receiving messaging server. Thus, if a message addressed to joe@server1.airius.com is received by another server inside of airius.com, the LDAP resolution of joe occurs on that server.

 The next example specifies that mail is to be routed to bigserver regardless of whether the mail is local or remote:

 *:bigserver.airius.com

 The Domain Name System (DNS)

The Domain Name System (DNS) is the naming system that allows computers to find each other on the Internet. Ever computer needs a DNS address to communicate on the Internet. This section provides a brief overview of DNS. For complete details about DNS, see the O'Reilly book, DNS and Bind, 2nd Edition by Paul Albitz and Cricket Liu.

The DNS is managed by DNS servers that store information about domains and individual host systems. A DNS server helps the messaging server convert the Internet domain name in an email address into a TCP/IP address. Once the messaging server knows the other computer's IP (Internet Protocol) address, it is able to contact it and forward messages to it.

 Each unit of data in the DNS distributed database is indexed by a name. These names are essentially just paths in a large inverted tree, called the domain name space.

 A Fully Qualified Domain Name (FQDN) is the unique name that identifies a specific Internet location. FQDNs consist of two or more sections, separated by dots. Each section is a string of letters or numbers without spaces, usually a recognizable word or abbreviation. The order of the sections in an FQDN is significant.

As you move from left to right, each section represents a more general level in the DNS hierarchy. As an example, yourhost.airius.com, would refer to a target system yourhost at an organization called airius which is a subdomain of the top-level domain com, which designates it as a company.

 The DNS server provides information such as the following to the messaging server:

 DNS Records

DNS servers contain "A" records and "MX" records that are used by messaging servers on the Internet to route email. MX and A records should be entered in the primary DNS server for the domain.

An A record contains a host name and its associated IP address. For example, the following record indicates that the IP address of host yourhost.airius.com is 195.95.92.6:

 
yourhost.airius.com. IN A 195.95.92.6
An MX record contains a mail exchange that maps a domain name to a host name. For example, the following record indicates that email addressed to anyone at airius.com be directed to server1.airius.com:

 
airius.com IN MX 10 server1.airius.com
The MX record contains two fields: a priority field (10 in our example) and a host field (server1.airius.com in our example). The priority field specifies the priority of this mail exchange (lower numbers have a higher priority). The host field is the name of the mail exchange host.

The exchange host name in the MX record must have at least one A record that maps the host name to an IP address. For example:

 
server1.airius.com IN A 195.95.92.6
All DNS queries regarding a specific domain are directed to the DNS server. The primary DNS server uses the MX and A records that have been set up within it to tell querying computers how to route the mail to the local Netscape Messaging Server host.

 You can use A records or a combination of A records and MX records to resolve domain names to IP addresses.

 Using A Records

You use an A record at the local DNS server to resolve the local Netscape Messaging Server's FQDN to its IP address. For example:

server1.airius.com. IN A 195.95.92.6
If you are not concerned about security, you can use an A record without an associated MX record.

However, if any of the following are true, you should use an MX record in addition to an A record:

 Using MX Records

Use of MX records in addition to A records is recommended for a messaging service. MX records are used to convert domains that do not point to any particular host into a host name or to route messages for one host to a different host that is running a messaging server.

All messaging servers look for MX records first in their search to identify an external mail host. In addition, MX records establish priority. Priority rankings enable you to identify backup mail servers by inserting additional records in your DNS server. Consider the following example:

 airius.com IN MX 10 server1.airius.com

 In this example, inbound messages addressed to airius.com (for example joe@airius.com, joe@server1.airius.com, or even joe@foobar.sna.foo.servera.server1.airius.com) are routed to the server1.airius.com host; which is assumed to be a messaging server.

 The following example provides a backup destination for times when the main destination is unavailable:

 
airius.com IN MX 10 server1.airius.com
airius.com IN MX 20 backupserver.airius.com
In this example, mail routed to airius.com is routed to server1.airius.com. If server1.airius.com is unavailable for any reason, messages are sent to an alternate messaging system, named backupserver.airius.com.

 Remember: Every mail exchange host must have an A record that maps the host name to its IP address.
How the Messaging Server Routes Messages
To route a message, the Messaging Server performs the following steps, as described below and shown in Figure 9.2.

  1. Check for SMTP address compliance.

  2. Search for matching LDAP entries. If no match is found, proceed to Step 3; if one match is found, proceed to Step 5.

  3. Check to see if the domain is local or remote. If domain is local, proceed to Step 4. If domain is remote, proceed to Step 6.

  4. Check for routed address. If none, bounce the message. Otherwise, proceed to Step 1.

  5. Check routing attributes in LDAP entry.

  6. Route to remote MTA.

Figure 9.2 Routing Diagram

 Step 1: Check SMTP Address Compliance

The Messaging Server requires standard, fully qualified SMTP addresses in the RCPT TO: field of the message envelope (for example, joe@domainname.ext).

If a message envelope does not have a fully qualified SMTP address (for example, joe), the Messaging Server attempts to make the address standard by adding the domain to the address as follows:

  1. If the Address Completion Domain field has been defined, the Messaging Server uses the value found in the LDAP entry.

  2. If the Address Completion Domain field has not been defined, the Messaging Server appends its serverhostname.domainname.ext to the envelope address (for example, joe@serverhostname.domainname.ext).

  3. If the address is of the form joe@server, the Messaging Server appends its domainname.ext extension to the envelope address (for example, joe@server.domainname.ext).

  4. If the address includes an IP address, such as joe@198.93.93.10, the Messaging Server will perform IP address resolution and replace the IP address with the matching host name (for example, joe@gethost).
Step 2: Search for matching LDAP Entries

The Messaging Server searches for an LDAP entry with a mail or mailAlternateAddress attribute that matches the envelope recipient address.

The search includes only LDAP entries that 1) have object class mailRecipient or mailGroup and 2) are in the directory subtree specified by the configured Base DN.

Alternate Search Methods

If an exact match for an address is not found, you can expand the list of possible matches by specifying one or more of the following search methods. If all search methods are specified, the server tries each method in the order listed until a match is found:

The default setting is search by user ID.

 Note: Specifying alternate search methods has a slight impact on performance.

 Search for custom domain.. Assume Joe has two addresses with his ISP: joe@isp.com and a custom domain address, joecorp.com. To enable Joe to receive mail addressed to anything@joecorp.com:

  1. Add a MailAlternateAddress value for Joe as follows: @joecorp.com.

  2. Add MX records in DNS as necessary to specify the messaging server for the custom domain.
Search using truncated domain. In a network environment, you might want the option of ignoring the host name when searching for an address. For example, assume the following:

With this feature enabled, the server can ignore the host name foo when searching in the directory for the correct address. Consequently, Joe can receive messages addressed to both joe@foo.airius.com and joe@airius.com.

 Note: Use this feature only if user accounts are not specific to a particular host. For example, if user@host1.domain.com, user@host2.domain.com, and user@domain.com are considered different accounts, do not enable this feature.

 Search by user ID. The server can search on the user ID if the domain in the address matches one of the host values specified for the MessageHostName parameter or if the domain is configured as a local mail domain.

 With this feature enabled, each user's uid attribute in LDAP is a valid email address for that user in an address such as uid@LocalMailDomain or uid@MessageHostName.

 Note: Do not use this feature if you do not want the user's uid to be treated as a valid email address.

 Step 3: Check if Domain is Local or Remote

The Messaging Server considers the address local if the domain part of the address matches:

If the domain is local, the Messaging Server proceeds to Step 4. Otherwise, the Messaging Server considers the address to be remote and proceeds to Step 6.

Step 4: Check for Routed Address

The Messaging Server checks to see if the recipient address is a routed form (for example, local%domain1@domain2). If the recipient address is a routed address, the Messaging Server rewrites the address as local@domain1. The rewritten address is considered a new address, so the Messaging Server proceeds to Step 1. If the recipient address is not a routed address, the message is bounced.

Step 5: Check Routing Attributes

If an LDAP entry matches the address, the Messaging Server checks the routing attributes for the address and takes the following actions:

Rewrite Address for Routing to Remote MTA

If the recipient was found in LDAP, but the mailHost attribute in the LDAP entry is not this server, the Messaging Server then tries to route the message to a remote MTA. The Messaging Server administrator can specify whether and how the server rewrites the envelope recipient address before routing the message to the remote MTA.

Note: The envelope address is rewritten only if the intended recipient was found in LDAP and is not local. (The server rewrites the envelope recipient address in the SMTP protocol dialog.).

The administrator can specify one or more of the following methods. By default, these methods are disabled. The server tries each enabled method in the order listed until it is able to compose a new address using the indicated attributes from the account's LDAP entry:

 If the server is unable to compose a new address (because the necessary attributes are not present in the user's LDAP entry or because no search methods are selected), the envelope address is not changed. However, if the "search by truncated domain" method was attempted in step 2, the truncated address is used instead of the original address.

The default method is to use the original address unmodified.

mailRoutingAddress Attribute

The mailRoutingAddress attribute method specifies a specific mail routing address. This method is most useful for LDAP entries that represent mail accounts on non-Netscape mail servers or gateway systems.

You must also modify the user's LDAP entry (by using ldapmodify) to include the mailRoutingAddress attribute. For example:

 
mailRoutingAddress: joesmith@judge.airius.com
The mailRoutingAddress attribute differs from the mailForwardingAddress attribute as follows:

Combine uid and mailHost Attributes

This method combines the uid attribute and the mailHost attribute found in the LDAP directory.

For example, mail arrives on one server for Joe_Smith@airius.com. The server determines that this mail belongs to jsmith whose mail account is on judge.airius.com. The server rewrites the envelope address to jsmith@judge.airius.com then relays the message to judge.airius.com.

 This method works best if the "search by user ID" method is employed on the next server.

 Note: Some sites prefer that only explicit addresses (those specified by the mail and mailAlternateAddress attributes) are valid email addresses for users. You should not use this method if the local policy does not consider uid a valid email address.

Combine Local Part and mailHost Attribute

This method combines the local part of the original address with the mailHost attribute value to create the new address. For example, Customer_Service@airius.com becomes Customer_Service@judge.airius.com. This method is useful to support entities, such as mail groups, that do not have a uid.

Note: This method is not used if the "custom domain" search method was used to resolve the address.

 Some SMTP installations prefer that addresses routed internally within the network be host-specific. This feature is most likely to work properly if the "truncated domain" search method is in use on the next server, or if all user accounts have a matching email address explicitly specified.

 Do not use this method unless, for each address of each user (as specified with the mail and mailAlternateAddress attributes), changing the domain part to a specific host does not create ambiguity about the message recipient. For example, suppose the mail server mail5.airius.com has three different users: joe@division1.airius.com, joe@division2.airius.com, and joe@airius.com. In this scenario, joe@airius.com would receive mail addressed to the other users, if the "local part at mailHost" rewrite method is used on the sending MTA and the "truncated domain" search method is used on mail5.airius.com.

Step 6: Route to Remote MTA

At this point, the Messaging Server assumes another mail server is responsible for this recipient. Two steps are taken to direct the delivery to a remote MTA:

  1. Check SMTP routing table

  2. Check Domain Name Server (DNS) definition for recipient domain
Check SMTP Routing Table

The Messaging Server checks its SMTP routing table to see if mail for the recipient's domain should be routed to a specific mail server host.

Note: Entries in the SMTP routing table are processed in order. You should keep this in mind when creating entries. For example, if you have a route entry that sends all non-local mail to a firewall mail server, you would want this entry to be the last entry in the routing table.

 Example Routes

The following example routes all internal mail through a hub server:

*.airius.com:hub.airius.com
The next example forces the use of IP addresses for frequently called servers (bypassing DNS):

 
hub.airius.com:[123.345.456.7]
The next example shows the use of a firewall server for all outside mail:

 
*airius.com:*
*:firewall.airius.com
Check Domain Name Server Definition or Local Host Files

If the route specified in the SMTP routing table does not contain a TCP/IP address, the Messaging Server assumes it should deliver the mail message to the domain's mail server as defined by the host's specified Domain Name System.

The Messaging Server asks its host machine to find the TCP/IP address of the mail server for that domain. To find the TCP/IP address of the remote mail server, the Messaging Server host machine performs the following steps:

  1. Asks for the Mail Exchange Record (MX record) defined for that domain and if found returns the TCP/IP address of that mail server.

  2. If no MX record is found, the host asks for the Address Record (A record) for that domain name and if found returns the TCP/IP address of that host.

  3. If no MX or A records are found for that domain name, the host checks its local host file (depending on the system's host name lookup configuration) to see if the domain name might be listed with a TCP/IP address.
If the Messaging Server finds a TCP/IP address, the server delivers the message to that address.

 If the Message Server does not find a TCP/IP address for that domain name, the message is considered undeliverable and the Messaging Server generates an error message that is delivered to the Postmaster and the originator (if specified in the Messaging Server configuration forms).

 

© Copyright 1998 Netscape Communications Corporation