Messaging Server Administrator's Guide: Message Routing

You can set values for the following attributes by using Netscape Console or by using the command-line interface. For information about setting the user attributes, see Chapter 4, Managing Mail Users and Mailing Lists. For information about setting the server attributes, see Chapter 3, Configuring SMTP Services. An exception is the mailRoutingAddress attribute. You can set this attribute only by using Netscape Directory Server tools, such as ldapmodify. For more information about LDAP object classes and setting attributes using LDAP tools, see the Netscape Directory Server Administration Guide and the Netscape Directory Server Schema Reference Manual.

Table 9.1 User attributes


Addressing	Description
mail	Identifies the user's email address
mailAlternateAddress	Identifies the user's alternate email address(es)
uid	Identifies the user
Routing	Description
mailHost	Identifies the host on which the user's mailbox resides
mailRoutingAddress	Identifies the address to place in the envelope when routing a message to this user

Table 9.2 Server options


Attribute	Description
service.smtp.defaultdomain	Identifies the domain name used to complete addresses that do not contain a domain name
service.smtp.smtp-router. localmaildomains	Identifies domains local to Messaging Server
service.smtp.domainname	Identifies the domain of this server machine
service.smtp.messagehostname	Identifies the host name on which Messaging Server resides

To determine how to route a message, Messaging Server must decide the following:

Does the recipient address have a matching LDAP entry?

Is the recipient address local or remote?

If the recipient address is remote, to where should the message be routed?

To make these decisions, the server performs the following steps, which are illustrated in Figure 9.2, and described in detail throughout this chapter.

Qualifies the SMTP Address.

Searches for matching LDAP entries. If no match is found, proceeds to step 3; if exactly one match is found, proceeds to step 4.

Checks to see if the domain is local or remote. If the domain is local, searches for the recipient using the specified search method. If the domain is remote, proceeds to step 5.

Checks routing attributes in LDAP entry.

Routes to remote server.

Figure 9.2 Routing diagram

Step 1: Qualifying the Address

Messaging Server requires standard, fully-qualified SMTP addresses in the RCPT TO: field of the message envelope (for example, joe@airius.com). If an envelope does not have a fully-qualified SMTP address (for example, joe), Messaging Server attempts to make the address standard by adding the domain to the address as follows:

If the service.smtp.defaultdomain attribute has been defined, Messaging Server appends the value defined for this attribute to the envelope address. (For information about specifying this attribute, see Specifying an Address Completion Domain.)

If the service.smtp.defaultdomain attribute has not been defined, Messaging Server appends the value defined for the service.smtp.messagehostname attribute to the envelope address (for example, joe@airius.com).

If the address is of the form joe@server, Messaging Server appends the value defined for its server domain extension (service.smtp.domainname) to the envelope address (for example, joe@server.airius.com).

If the address includes an IP address, such as joe@[198.93.93.10], Messaging Server will perform IP address resolution and replace the IP address with the matching host name (for example, joe@gethost).

Step 2: Searching for matching LDAP Entries

Messaging Server searches for an LDAP entry with a mail or mailAlternateAddress attribute that matches the envelope recipient address. (For information about specifying these attributes, see Specifying User Email Addresses.)

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.

If no match is found, Messaging Server tries any alternate search methods that are enabled. If it still cannot find a match, Messaging Server proceeds to Step 3.

For more information about alternate search methods, see About Alternate Search Methods.

If exactly one matching address is found, Messaging Server proceeds to Step 4.

If multiple matches are found, Messaging Server treats the address as invalid and bounces the message.

Step 3: Checking if Domain is Local or Remote

If Messaging Server cannot find a matching LDAP entry for an address, it must decide whether the domain specified in the address is local or remote. It considers the address local if the domain part of the address matches:

The fully-qualified domain name of the host on which Messaging Server resides

A local domain setting if set (For information on setting the local domain, see Specifying the Domains Local to Your Server.)

If the domain is local, Messaging Server assumes the message is addressed to an unknown user and bounces the message.

Otherwise, Messaging Server considers the address to be remote and proceeds to Step 5.

Step 4: Checking Routing Attributes

If Messaging Server finds exactly one LDAP entry that matches the address, it checks the routing attributes for the address and takes the following actions:

If the LDAP entry contains a mailHost attribute, Messaging Server will deliver or route the message to the server specified by the attribute:

Local Server. If the mailHost attribute indicates the local server (as defined by MessageHostName), then Messaging Server uses the entry's uid attribute for local delivery and handles the message locally.

Remote Server. If the mailHost attribute indicates a remote server, Messaging Server rewrites the address (see About Recipient Address Rewrites) and routes the message to the remote server as described in Step 5.

If the LDAP entry does not contain a mailHost attribute, but does contain an enabled mailRoutingAddress attribute, Messaging Server rewrites the address (see About Recipient Address Rewrites) and routes the message to the remote server as described in Step 5.

Note: You should not use the mailRoutingAddress attribute for local users.

If the LDAP entry contains no routing information (that is, no mailHost attribute and no enabled mailRoutingAddress attribute) but specifies that the account is a mailing list, Messaging Server handles the message locally. For more information about how the server handles delivery to mailing lists, see About Mailing List Expansion and Delivery.

If the LDAP entry contains no mailHost attribute and cannot be routed or handled locally, Messaging Server rejects the message.

For information about how to specify the mailHost attribute, see Specifying User Email Addresses. To set the mailRoutingAddress attribute, you must use Netscape Directory Server tools. For information, see the Netscape Directory Server Administrator's Guide.

Step 5: Routing to Remote Server

If Messaging Server assumes another messaging server is responsible for this recipient, it performs the following steps to route the message to a remote server:

Checks the SMTP routing table

Looks up address of the server in DNS

Use MX records if present

Otherwise, use A records

Checking the SMTP Routing Table

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

If the routing information is an asterisk "*", Messaging Server routes the message to the server specified in the MX record for the domain. (An "*" entry prevents entries occurring later in the routing table from handling the domain.)

If the routing information includes an IP address in square brackets, Messaging Server routes the message to the remote server at that address (and need not perform a DNS lookup).

If the routing information does not include an IP address, but includes a domain name, Messaging Server routes the message to a mail exchange server for that domain.

To find an IP address, Messaging Server checks the DNS definition for the domain. See About the Domain Name System (DNS).

Example Routes

This section provides sample routing table entries. For information about how to specify routing table entries using Netscape Console, see Editing SMTP Routing Table Entries.

In the following example, all outgoing mail is routed to bigserver:

*:bigserver.airius.com

The next example routes all mail to subdomains of airius.com through a hub server:

*.airius.com:hub.airius.com

In the next example, messages for any subdomain inside the top-level domain airius.com are sent directly to the mail exchange server for the respective domain:

*.airius.com:*

The next example directs mail for the hub to the server with the specified IP address. Messaging Server need not perform a DNS lookup to find the IP address.

hub.airius.com:[123.345.456.7]

The next example directs all mail sent outside airius.com to a firewall server:

airius.com:*
*.airius.com:*
*:firewall.airius.com

Note: Keep in mind that the server processes entries in the SMTP routing table in order. If, for example, you have a routing entry that sends all non-local mail to a firewall messaging server, you want this entry to be the last entry in the routing table.

Looking Up Address of the Server in DNS

If a routing table entry does not include an IP address in brackets, Messaging Server must know the IP address of the host machine to which it is sending. To find the IP address, Messaging Server uses the Domain Name System (DNS) as follows. For more information on DNS and DNS records, see About the Domain Name System (DNS).

Asks for Mail Exchange Records (MX records) defined for the domain. If MX records are found, tries to route the message to each messaging server defined in the MX records until routing is successful. The MX record must have an associated Address record (A record) that includes the IP address. (Note that Messaging Server caches MX records to decrease the number of DNS lookups required.)

If no MX record is found, asks for the A record for the domain. If the A record is found, routes the message to the host specified for the domain.

If Messaging Server cannot find an IP address for the machine to which it is routing a message, the message is considered undeliverable and Messaging Server bounces the message.

About Alternate Search Methods

If an exact match for an address is not found, but alternate search methods are enabled, the server tries each method in the order listed until a match is found:

Search for custom domain

Search using truncated domain

Search by user ID

For information about how to enable alternate search methods using Netscape Console, see Specifying Alternate Search Methods.

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

Search for custom domain. In a hosting environment, you might want the server to search for custom domain addresses.

To set up a custom domain for a user, add an alternate address for the user that includes the custom domain name. For example, assume Joe wants to receive mail addressed to joe@airius.com and a mail addressed to the custom domain, joecorp.com. To enable Joe to receive mail addressed to anything@joecorp.com, you must add a MailAlternateAddress value for Joe as follows: @joecorp.com. You must also add the MX records in DNS as necessary to route messages sent to the custom domain to the desired messaging server. For more information about DNS and MX records, see About the Domain Name System (DNS).

Search using truncated domain. In some environments, you might want the server to ignore the first component of a domain when searching for an address in LDAP. This allows the server to handle mail sent to recipient@server instead of recipient@domain.

For example, assume mail arrives for joe@foo.airius.com. With the "search using truncated domain" feature enabled, if no LDAP entry for joe@foo.airius.com is found, the server will search for joe@airius.com. Consequently, Joe can receive messages addressed to joe@anything.airius.com as well as joe@airius.com.

Note: Use this method only if for all domains listed in LDAP, all domains one level down have the same email namespace. For example, if user@host1.airius.com, user@host2.airius.com, and user@airius.com are considered different accounts, do not enable this method.

Search by user ID. With the "search by user ID" method enabled, if an address domain is local, Messaging Server searches for an LDAP entry with a uid attribute matching the address (with the @domain removed). For example, if airius.com is local, and the address is joe@airius.com, Messaging Server searches for a uid of "joe".

Note: This method is for compatibility with earlier versions of Netscape Messaging Server. If your installation is new, Netscape recommends that you disable this method.

About Recipient Address Rewrites

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

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

You can specify one or more of the following rewrite methods. By default, these methods are disabled. Messaging 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:

Use the mailRoutingAddress attribute

Combine the uid with the mailHost attribute

Combine the local part of the address with the mailHost attribute

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

mailRoutingAddress Attribute

This rewrite method uses the mailRoutingAddress attribute, which 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.

If you enable this rewrite method, you must modify the user's LDAP entry to include the mailRoutingAddress attribute. You can set this attribute only by using LDAP tools such as ldapmodify. For example:

mailRoutingAddress: joesmith@judge.airius.com

The mailRoutingAddress attribute differs from the mailForwardingAddress attribute as follows:

mailRoutingAddress determines how to route the message to the server that handles this account (the mail account that is represented by this LDAP entry)

mailForwardingAddress determines how a mail account forwards its mail to some other account

Combine uid and mailHost Attributes

This rewrite 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 rewrite 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.

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 messaging 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 server and the "truncated domain" search method is used on mail5.airius.com.

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

About Mailing List Expansion and Delivery

When a message is sent to a mailing list, Messaging Server determines whether this list is handled locally by checking the mailHost attribute defined for the list. If there is no mailHost attribute defined, or if the mailHost attribute indicates the local server, Message Server assumes the mailing list is local and performs the steps outlined in this section.

Note that attributes for mailing lists, including the restrictions and actions described throughout this section, are defined using the Netscape Console Users and Groups interface. For more information about mailing list attributes, see Chapter 4, Managing Mail Users and Mailing Lists.

Step 1. Checking Restrictions. Messaging Server checks for the following restrictions before delivering the message to the list:

Allowed sender restriction. Messaging Server checks to see if the sender is allowed to send messages to this list.

Allowed sender domain restriction. Messaging Server checks to see if the message sender's domain is allowed to send messages to this list.

Maximum message size restriction. Messaging Server checks to see if the message size is within the limits set up for this list.

Password restriction. Messaging Server checks to see if password restriction is in effect for senders to this list. If the password is present--in an Approved header or in the first line of the message--Messaging Server strips the password from the message before delivering it to the list.

If Messaging Server must reject a message, it goes to step 2; otherwise it proceeds to step 3.

Step 2. Rejecting a Message. If Messaging Server must reject a message, it first checks to see if any of the following actions are specified for the list.

Send message to moderator(s). Messaging Server sends the message to the moderator by adding the moderator(s) to the envelope recipient list and by adding a new header, "Moderation-from:".

Send a reply. Messaging Server sends a reply to the sender (using the "Reply-To:" field if present; using the "From:" field if the "Reply-To:" field is not present).

(You can configure the text for this reply using the Groups Actions tab in Netscape Console. If no text is specified, Messaging Server sends a default reply "Your message to this group has been rejected." You can also specify whether Messaging Server should send the original message as an attachment to the reply.)

Step 3. Delivering the Message. If the message passes all restrictions configured for the list, Messaging Server:

Checks to see if the mail list is moderated. If yes, Messaging Server checks to see if the message is being forwarded by the moderator (that is, the sender is a moderator). If the message has been forwarded (there is an attached message), Messaging Server strips the moderator's header from the message before delivering the message to the list.

Performs any header rewrites as necessary. For example, the Resent-From header is added.

If error messages concerning delivery to the list should be sent to a particular email address (see the "Errors-To" field in the Groups Settings Tab), Messaging Server uses this address in the Return-Path: header. This ensures that bounced messages will return to the address configured in the "Errors-To" field and not to the original sender.

At this stage, Messaging Server splits the envelope into individual recipients and list recipients. By splitting the envelope, Messaging Server ensures that modifications for mailing list delivery are not applied to other recipients of the message. Messaging Server might further split the envelope for list recipients--particularly if the list contains many members. Each envelope split is considered a separate "control" envelope.

Messaging Server adds list members to the message recipient list. Members are added according to the type of membership:

Member with email-only membership. These members are added as email addresses. If the address is found in LDAP and is local to this server, then Messaging Server handles the recipient. If the recipient is not found in LDAP or is not local to this server, Messaging Server routes the message to the appropriate server according to the mailHost attribute or the domain.

Dynamic members. These members meet search criteria specified as dynamic criteria for email-only membership (see the Groups Email-Only Members tab) or are part of a dynamic group (see the Members Dynamic Group tab). Messaging Server checks the mailHost attribute for the entry to determine whether mail for the dynamic member can be handled locally or should be routed to a remote server.

Unique members are members defined as part of a static group (see Groups Static Group tab). Messaging Server checks to see if all members are in the LDAP directory. If any members cannot be found in the directory, the member is considered an unknown recipient.

More About Mailing Lists

This section provides further information about how Messaging Server delivers mail to mailing list members.

Duplicate checks. Messaging Server performs duplicate checks to see if any message recipients, including list members, are unique members.

Duplicate checks can impact server performance--especially for large lists containing 1000 or more members. You can specify that Messaging Server not perform duplicate checks by modifying the list attribute mgrpNoDuplicateChecks. You can modify this attribute by using the ldapmodify utility. For more information on this utility, see the Netscape Directory Server Administrator's Guide.

Nested Groups. Lists can contain other lists as members.

For static groups, nested groups are expanded with the original group.

Nesting of dynamic groups can cause degradation in group handling performance if membership is not handled correctly. Consequently, Messaging Server does not, by default, automatically nest dynamic groups. If you want to nest dynamic groups, you can set the configuration parameter service.smtp.smtp-router.nestedgroups to yes.

A nested group will still enforce all its restrictions even when nested within another group. Consequently, spammers cannot avoid group restrictions by nesting groups within groups.

Nested groups are handled by recursion. Consequently, several layers of nested groups can affect server performance. Netscape recommends no more than 3 or 4 levels of nested groups.

Recipients per control envelope. If a message sent to a list is routed to another MTA, Messaging Server limits the number of recipients sent in each control envelope. The default number is 500 recipients per control envelope.

Error notification. If error notification (Errors-To field) is configured for the group, to easily track members without mail accounts, delivery status notification (DSN) extensions are added to each member.

About the Domain Name System (DNS)

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

The DNS is managed by DNS servers that store information about domains and individual host systems. 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 components, 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, server1.airius.com, would refer to a target system server1 at an organization called airius which is a subdomain of the top-level domain com, which designates it as a company.

A DNS server helps a messaging server convert the Internet domain name in an email address into an IP (Internet Protocol) address. Once the messaging server knows the other computer's IP address, the messaging server is able to contact the other computer and forward messages to it. The DNS server provides information such as the following to the messaging server:

Identification of messaging server hosts (for example, which messaging servers handle incoming mail for this domain?)

Address resolution (for example, what is the IP address for the name server1.airius.com?)

Reverse address resolution (for example, what is the name for the IP address 195.95.92.6?)

The DNS server uses the records that have been set up within it to tell querying computers how to route mail to the local messaging server host.

DNS Records

DNS servers contain several record types. This section focuses on three record types, described in Table 9.3. These record types should be entered in the primary DNS server for a domain. (For information about other record types, see the book, DNS and Bind.)

Table 9.3 DNS records


Record Type	Function
A record	Map host name to IP address
MX record	Map domain name to host name of server that handles incoming mail for the domain
PTR record	Map IP address to host name

You can use A records or a combination of A records and MX records to resolve domain names to IP addresses. To reduce the load on the DNS system, domains that receive a significant amount of mail should have at least one MX record.

Using A Records

You can use an A record at the local DNS server to resolve the local server's FQDN to its IP address. For example, the following record indicates that the IP address of server1.airius.com is 195.95.92.6:

server1.airius.com. IN A 195.95.92.6

Using MX Records

You can use an MX or mail exchange record to route messages for one domain to one or more hosts running a messaging server. For messaging services, it is recommended that you use MX records in addition to A records. 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 balance the load of incoming messages and to identify backup mail servers by inserting additional records in your DNS server.

Example 1. In the following example, inbound messages addressed to airius.com (for example joe@airius.com) are routed to the server1.airius.com host; which is assumed to be a messaging server. (Note that the example would not affect inbound messages addressed to host.airius.com.)

airius.com IN MX 10 server1.airius.com

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

Example 2. The next example provides a backup destination for times when the main destination is unavailable. The first line indicates that mail routed to airius.com should be routed to server1.airius.com. The second line indicates that if server1.airius.com is unavailable for any reason, messages are sent to an alternate server, named backupserver.airius.com:

airius.com IN MX 10 server1.airius.com
airius.com IN MX 20 backupserver.airius.com

Example 3. The next example balances the load between two servers, server1.airius.com and server2.airius.com. If both servers are unavailable, mail is routed to the alternate server, backupserver.airius.com:

airius.com IN MX 10 server1.airius.com
airius.com IN MX 10 server2.airius.com
airius.com IN MX 20 backupserver.airius.com

Note: The exchange host name in any MX record must have at least one A record that maps the host name to an IP address. Considering example 3, the exchange hosts server1.airius.com, server2.airius.com, and backupserver.airius.com must have A records, such as the following (note that the domain airius.com does not require an A record):

server1.airius.com. IN A 195.95.92.6
server2.airius.com. IN A 195.95.92.7
backupserver.airius.com IN A 195.95.92.8

Using PTR Records

PTR or pointer records map IP addresses to names for purposes of reverse address resolution. The following example creates a PTR record for the IP address 195.95.92.6:

6.92.95.195.in-addr.arpa. IN PTR server1.airius.com
7.92.95.195.in-addr.arpa. IN PTR server2.airius.com
8.92.95.195.in-addr.arpa. IN PTR backupserver.airius.com