Sample MTA Scenarios

Refer to the MTA scenario that best matches your company's mail server set up plans.

Mail Server Supporting Few Users in a Single Domain

Alpha Corporation has 1000 mail users and is part of the alpha.com domain. Based on average mail use, Alpha Corporation designates one machine as the mail server, mailserver.acme.com.

Since there is only one mail server for the entire company, it has to be able to route messages sent to any user in the alpha.com domain.

If Alpha Corporation has a firewall, locating the corporate mail server and the firewall on different machines is preferable. In this way, the firewall MTA can be responsible for merely forwarding messages to and from the Internet to mailserver.alpha.com. The mailserver.alpha.com machine handles the task of distributing the mail to its user community.

Mail Server Supporting Many Mail Users in a Single Domain

Bravo Corporation has a larger mail community than Alpha Corporation. As a result, it requires multiple mail servers to support its mail traffic. In this case, the company can designate multiple mail servers such as mailserver1.bravo.com and mailserver2.bravo.com.

Each mail user is assigned to one of these mail servers, either mailserver1.brovo.com or mailserver2.bravo.com. In other words, for a given user, a single mail server delivers its messages.

To route messages from one mail server to the other, at least one of the two mail servers must have the ability to route to every user in bravo.com. Bravo Corporation can also specify more than one MTA with the ability to route with the bravo.com domain. This will increase the database lookup times (since the amount of addressing information cached by the average MTA is greater) but reduce the message transfer time (by reducing the average number of hops messages have to go through to travel across the network).

Mail Server Supporting Mail Users in a Single Domain Divided into Subdomains

Net International Corporation has split its parent xyx.com domain into several subdomains. Each of the subdomains has at least one MTA capable of resolving all addresses in the xyx.com domain.

Net Corp has implemented a firewall that provides a single entry point for all incoming and outgoing mail from the corporation. The firewall machine is also the corporate backbone server.

		If all incoming mail is addressed to one of the subdomains, the firewall MTA can serve as a proxy MTA. It can route messages to the various subdomains without looking up individual users. To set up your company mail distribution in a similar manner, configure your mail server to route to one channel per subdomain.
		On the contrary, if an incoming message is addressed to <user>@net.com, the corporate MTA must have the ability to resolve these addresses in order to forward messages to the appropriate subdomains. As the router MTA, it also needs information on any additional configured SMTP router channels.

Creating A New Rewrite Rule Versus Creating A New Channel

Typically, if you want particular messages to be placed in a particular Internet Message Transfer Agent (IMTA) channel queue, you can create a new domain rewriting rule. For example, imagine that you want messages addressed to <user>@corp.alpha.com to go into the Sun Message Store channel queue. Domain rewriting rules (or from this point forward, rewrite rules) are a tool that the IMTA uses to route messages to the correct queue and thereafter, host. For more information on rewrite rules, see the Sun Internet Mail Server 3.5 Administrator's Guide.

There are some situations in which rather than creating a new rewrite rule for an existing channel, creating a new channel may better serve your purposes. The following are examples of such situations:

		When you wish to isolate heavy message traffic to and from a particular address in the event of a mail server failure
		When your domain is divided into subdomains, you have implemented a smart host in each subdomain, and you wish to monitor mail traffic addressed to and from these subdomains

To illustrate the situation described in the first bullet, imagine that a large number of messages pass daily between two companies, Alpha Corporation and Bravo Corporation. Alpha's e-mail administrator can elect to isolate message traffic addressed to and from Bravo by creating an SMTP channel that handles Bravo message traffic only. In this situation, if a problem arises with Bravo's mail server, Bravo's messages will back up in Alpha's Bravo-exclusive SMTP channel only and will not affect message traffic in other channels.

To illustrate the situation described in the second bullet, imagine that Bravo Corporation has implemented multiple subdomains, for example, Corp, Eng, and Sales. In turn, Bravo has implemented a smart host in each subdomain. (A smart host is an IMTA in a particular domain to which other IMTAs acting as routers forward messages if they do not recognize the recipient.) Bravo's e-mail administrator can elect to isolate messages routed to the smart hosts in the Corp, Eng, and Sales subdomains by creating a channel that handles mail traffic addressed to and from each of these subdomains. In this situation, the e-mail administrator can monitor the volume of e-mail addressed to and from each of these subdomains for any patterns, changes, and so on.

Unique User Identification

You must implement a unique user ID for each user in the following ways:

		If your organization is not divided into subdomains, you must implement a unique user ID for each user in the domain. For example, if Alpha Corporation is composed of the domain alpha.com, the user ID for each user, for example, hgreen, must be unique.
		If your organization is divided into subdomains, at a minimum, you must specify a unique user ID for each user in each subdomain. For example, imagine that the Bravo Corporation is composed of the domain bravo.com and bravo.com is further divided into the subdomains eng.bravo.com, corp.bravo.com, and sales.bravo.com. e-mail user Harold Green exists in the eng.bravo.com subdomain, Harvey Green exists in the corp.bravo.com subdomain, and Harry Green exists in the sales.bravo.com subdomain. If desired, you can implement the same user ID (hgreen) for each of these e-mail users since they exist in separate subdomains. Their e-mail addresses respectively would be hgreen@eng.bravo.com, hgreen@corp.bravo.com, hgreen@sales.bravo.com. Alternatively, you can implement a unique user ID for each user in the domain. Using the same example, you could implement haroldg, harveyg, and harryg, respectively. Their e-mail addresses respectively would be haroldg@bravo.com, harveyg@bravo.com, and harryg@bravo.com. Note that when implementing unique IDs in a domain, e-mail users would not have to specify a subdomain(s).

Sun also recommends that when e-mail users specify addresses for e-mail recipients, they specify a fully qualified domain name for each recipient. For example, to specify Harry Green from Bravo Corporation as the recipient of an e-mail, Sun recommends specifying the following:

harry.green@sales.bravo.com

Specifying a fully qualified domain name minimizes e-mail address ambiguities that in the worst case scenario could lead to an e-mail being delivered to the wrong recipient.

Not specifying a fully qualified domain name places the responsibility of fully qualifying e-mail addresses on the IMTA. The IMTA must be configured to perform this task via rewrite rules.