• Choose a category
• All
• Classic-Fiction

• To receive incoming mail from the outside world

• To deliver mail to end users’ desktops with IMAP or POP

At a small site, the servers that implement these functions might all be the same machine wearing different hats. At larger sites, they should be separate machines. It is much easier to configure your network firewall rules if incoming mail arrives at only one machine and outgoing mail appears to originate at only one machine.

Some sites use a proxy to receive mail from the outside world. The proxy doesn’t really process mail; it just accepts and spools it. A separate process then forwards the spooled mail to sendmail for transport and processing. smtpd and smtpfwdd from www.obtuse.com are examples of such proxies for sendmail; smtpd can also filter incoming mail with access lists. Both are open source products.

Using mail servers

Pick stable, reliable machines to use as your mail servers. Here, we outline a mail system design that seems to scale well and is relatively easy to manage and secure. It centralizes the handling of both incoming and outgoing mail on servers dedicated to those purposes. Exhibit C illustrates one form of this system.

Exhibit C Mail system architecture

The mail system depicted in Exhibit C has a single point of exposure to the outside world: the mail server that receives messages from the Internet. That server can be carefully monitored, can be upgraded with security patches, and can run the latest version of sendmail with spam filters for incoming mail.

The server that handles outgoing mail must also be well maintained. It can include spam filters of its own to verify that no local user is contributing to the spam problem. If your site has concerns about the leakage of proprietary information, establishing a single server through which all outgoing mail must pass makes it easier to implement or enforce content policies. If your site manages large mailing lists, the outgoing mail server can be configured to take advantage of some of sendmail’s performance-oriented features.

Both the incoming and outgoing mail servers can be replicated if your mail load requires it. Don’t pass any mail directly between the incoming servers and the outgoing servers, however; they should be separated from each other by an internal firewall.

ISPs who are designing a mail system for customers should add another server that acts as the target of customers’ backup MX records and handles mailing lists. This machine has to accept mail and relay it back out, but it must be heavily filtered to make sure that it only relays the mail of actual customers. It, too, should be separated from the incoming and outgoing mail servers by a firewall.

Garden-variety UNIX hosts can be given a minimal sendmail configuration that forwards outgoing mail to the server for processing. They do not need to accept mail from the Internet. Some sites may want to relax this funneling model a bit and allow arbitrary UNIX hosts to send mail directly to the Internet. In either case, nonserver machines can all share the same sendmail configuration. You might want to distribute the configuration with a tool such as rdist or rsync.

See page 515 for a discussion of file distribution issues.

Sites that use software such as Microsoft Exchange and Lotus Notes but are not comfortable directly exposing these applications to the Internet can use a design modeled on that shown in Exhibit D.

Exhibit D Mail system architecture diagram #2

Whatever design you choose, make sure that your sendmail configuration, your DNS MX records, and your firewall rules are all implementing the same policy with respect to mail.

Using mail homes

It is convenient for users to receive and keep their mail on a single machine, even if they want to access that mail from several different systems. Mail homes can be enforced through the aliases file, the maildrop field of the user database, or even an LDAP database (see page 560). Remote access to each user’s