This chapter covers different configurations that you need to consider before installing your SunTM Internet Mail ServerTM 4.0 system.

Topics in this chapter include:

SIMS as a proxy considerations

SIMS in SP environments considerations

Internet Message Transfer Agent considerations

SIMS as a Proxy Considerations

If you are installing SIMS as a proxy, you need to consider the following guidelines. See Appendix A, "SIMS as a Proxy Considerations," in the Sun Internet Mail Server 4.0 Administrator's Guide for different proxy scenarios, models, and configurations.

Why using SIMS as a Proxy?

The proxy servers provides two real solutions: one provides security by putting the proxy on the firewall and the backend mail server on the other side. The other is for the horizontal scalability to use multiple backend servers and multiple proxies.

See the Sun Internet Mail Server 4.0 Concepts Guide for definitions of the horizontal scalability, where large scale virtual hosting SP configurations is implemented. This guide also provides you with a horizontal scaleability scenario.

How Does a SIMS Proxy Work?

Typically, each user has a well-defined backend mail server but accesses a random proxy via a Domain Name System (DNS) round-robin. The advantage compared with just multiple servers without proxies is that all users access one single server name rather than each user having to configure their own mail host.

Once the client is authenticated on the proxy, it will contact the real mail host and redo the login using the same user name and password. After login, however, the proxy switches to a passive relay mode in which everything that comes from the client is passed onto the backend mail host and vice-versa without any interruption on the part of the proxy. Overly large machines should not be required for the proxies.

What to Consider to Install SIMS as a Proxy

When configuring for a number of users, you must look again at the total concurrent users planned for, the total number of users, the percentages of POP3 and IMAP4 that will be concurrent at peak times, and the size of the users' mailboxes. From this you can estimate the needs of the backend mail server or servers. The number of proxy servers that you need depends upon the model you choose; that is, corporate versus SP.

---

Note - Be sure that you install SIMS as a proxy on a clean system where no SIMS files are installed.

---

SIMS in SP Environments Considerations

The Sun Internet Mail Server (SIMS) product meets the needs of the corporate outsourcing services providers (SPs), by providing the following services:

Virtual hosting support

Vertical and horizontal scale ability support

Delegated administration capability

Provisioning tools

Monitoring tools

See the Sun Internet Mail Server 4.0 Concepts Guide for the key features of SIMS, domain hosting capability, and different deployment scenarios for which SIMS could be installed.

Internet Message Transfer Agent Considerations

The IMTA component of SIMS requires the following information. Be sure that you have this information ready before you begin the installation by identifying the following:

Role of an IMTA

Before you install an ensemble of mail servers, you should determine what role you will assign to the message transfer agent for each of the servers.

Two factors can help determine the role of an IMTA:

IMTA's Ability to Route Messages

The SIMS product classifies the IMTA's ability to route messages in the following three ways:

If your company has not implemented a firewall around your mail network, the mail server queries the local or a public Internet domain name server before it forwards a message. However, if your mail server is located behind a firewall system, all messages to mail users outside your company's private mail network have to travel through the firewall's IMTA. Since your IMTA is not a firewall IMTA, it also cannot query the public DNS.

This means that each mail server's IMTA depends on a smarter IMTA (except the firewall machine's IMTA) that resides on the firewall machine or a smart host, to forward all messages that it cannot route directly. The smart host may or may not serve as the firewall system. If you have two separate machines, one serving as the smart host and the other serving as the firewall system, the IMTA can forward a message to a recipient in another subdomain to the smart host, and mail addressed to a recipient outside your organization to the firewall machine.

For example, the Stream Corporation, has implemented a firewall. If a user, joan@eng.stream.com, sends a message to pierre@sales.stream.com, the message is handled by Joan's mail server. Since Joan's mail server can route only to users within eng.stream.com domain, it forwards the message to its configured smart host, mailhost.stream.com. If mailhost.stream.com has the ability to route messages to stream.com, this mail will be routed directly to Pierre's mail server. However, if mailhost.stream.com serves as a pure backbone IMTA, with no ability to route messages directly to users, it will transit the message to a configured IMTA (specified in the mailhost.stream.com 's configuration) that can route directly within Pierre's mail domain, sales.stream.com.

In this example, mailhost.stream.com does not necessarily serve as the company's firewall system. So, if a message arrives addressed to youri@net.com, mailhost.stream.com will forward this message to the firewall machine. The firewall machine will then route the message across the public Internet to the net.com domain.

For information on how to configure an IMTA's location relative to a firewall and how to configure a smart host, see "To Configure IMTA Position Relative to the Internet" in Chapter 5, "Internet Message Transport Agent (IMTA) Administration" in the Sun Internet Mail Server 4.0 Administrator's Guide.

Sample IMTA Scenarios

Use the IMTA scenario that best matches your company's mail server setup plans in this section.

Mail Server Supporting Few Users in a Single Domain

The Stream Corporation has 1000 mail users and is part of the stream.com domain. Based on average mail use, Stream 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 stream.com domain.

If Stream Corporation has a firewall, locating the corporate mail server and the firewall on different machines is preferable. In this way, the firewall IMTA can be responsible for merely forwarding messages to and from the Internet to mailserver.stream.com. The mailserver.stream.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 Stream 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 IMTA 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 IMTA 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 IMTA capable of resolving all addresses in the xyx.com domain.

Net Corporation 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 IMTA can serve as a proxy IMTA. 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 IMTA must have the ability to resolve these addresses in order to forward messages to the appropriate subdomains. As the router IMTA, it also needs information on any additional configured SMTP router channels. SWAPNA decide on the following:

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.stream.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 4.0 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, Stream Corporation and Bravo Corporation. Stream's email 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 Stream'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 email 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 email administrator can monitor the volume of email 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 Stream Corporation is composed of the domain stream.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. The email 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. You can implement the same user ID (hgreen) for each of these email users since they exist in separate subdomains. Their email addresses, respectively, would be hgreen@eng.bravo.com, hgreen@corp.bravo.com, and 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 email addresses, respectively, would be haroldg@bravo.com, harveyg@bravo.com, and harryg@bravo.com. Note that when implementing unique IDs in a domain, email users would not have to specify a subdomain(s).

Sun also recommends that when email users specify addresses for email 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 email, Sun recommends specifying the following:

harry.green@sales.bravo.com

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

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