post.office - Chapter 3 Unix

UNIX PLATFORM	3A contains introductory reference information which will help you set up a distributed E-mail network. Section 3.B covers pre-installation planning and installing `post.office.`
3A: SETTING UP YOUR E-MAIL NETWORK 3B: INSTALLATION

3.A.0 SETTING UP YOUR E-MAIL NETWORK
3.A.1 THINGS TO CONSIDER WHEN DESIGNING YOUR NETWORK
3.A.2 ADDRESSING
3.A.3 EXAMPLE SETUPS
3.B.0 INSTALLATION INSTRUCTIONS
3.B.1 PRE-INSTALLATION PLANNING
3.B.2 INSTALLING POST.OFFICE
3.B.3 COMMON INSTALLATION MISHAPS
- 3.B.3.1 Rerunning Install
- 3.B.3.2 Changing the Postmaster Account
3.B.4 DE-INSTALLATION
- 3.B.4.1 Things To Check
- 3.B.4.2 Removing post.office

3.A.0 SETTING UP YOUR E-MAIL NETWORK

The purpose of the first part of this chapter (3A) is to provide a rough blueprint of how to successfully set up even the most complicated E-mail network.

3.A.1 is a check list of issues you should consider when setting up your E-mail network.
3.A.2 discusses the tools used with post.office to take care of addressing and routing. These include account addresses, aliases, and mail routing facilities.
3.A.3 concludes with several example configurations that cover the most common situations and should spark ideas on how to approach your own solution.

Note: If you are already familiar with the material covered in section 3A, you can of course skip ahead to section 3B, which covers pre-installation planning and the installation itself.

You may run across some ground which you are not familiar with that you would like to know more about before configuring your system. You may find useful reference information in the sources we list in appendix B, References.

3.A.1 THINGS TO CONSIDER WHEN DESIGNING YOUR NETWORK

This section is a check list of key issues to review in thinking about how you're setting up your E-mail network. This is not a formula. Rather, it is a list of things you should keep in mind as you decide how many machines you need and how to configure post.office on each machine so that they work together in harmony.

SYSTEM LOAD

The load put on a machine running post.office, or any MTA, is directly proportional to the volume of mail that goes through the system. The volume obviously increases as the number of users increases, and as post.office is set up to handle more mail domains (since that means there are more users). To reduce the impact of mail on a single machine you may want to distribute users among several machines.

ADDRESSING

post.office will let you assign any valid address to an account. You may want to choose a convention for user addresses (such as First.Lastname@mail_domain). Regardless of the convention you choose, you must set up the DNS so that mail with the addresses you use will be delivered to your network.

If you want addresses to exclude host names of specific computers, you will need to follow the instructions for hostname hiding below.

USER ACCESS TO E-MAIL

post.office allows users to access their E-mail via the network using POP3, as well as by logging into the server and using a mail agent that reads their UNIX spool file (e.g. /var/spool/mail/username). Program delivery is also available, which allows users to have their mail delivered to a program which will then process it efficiently (this is mainly for users with a large volume of E-mail).

For users who want mail and don't otherwise need a login account, the best option is to set them up with a POP account in post.office which they can access from a remote PC or workstation. Users that have login accounts most likely use mail software that accesses their maildrop directly. However if POP-aware software is available, some users may prefer to have a POP account set up for them.

If you have a number of users that only use POP to retrieve their mail, it may be beneficial to set up a dedicated mail server machine for this purpose. The benefits of such a "sealed server" are ease of administration, improved performance, and improved security.

CONNECTIVITY TO THE INTERNET

There are three levels of Internet connectivity: fully connected, partially connected, and not connected. How you set up your E-mail network depends on the category you fit in.

Fully and partially connected sites are similar. Since partially connected sites are not reachable at all times throughout the day, it is especially important that MX records are set up to redirect incoming mail to an alternate host while not connected. Such sites often connect to the Internet using SL/IP or PPP to a network provider who acts as a backup mail exchanger.

Unconnected sites that use post.office on a private TCP/IP network for mail may or may not have a mail gateway to the Internet or other network such as UUCP or BITNET. post.office can be set up to deliver all non-local mail to the gateway machine which will pass it to the Internet or other network. Such a setup is very similar to having a firewall (discussed below).

FIREWALL CONFIGURATION

If your site is behind an Internet firewall you will need to ensure that mail is allowed to flow in and out of your network. Since other machines on the Internet can not directly contact any of your hosts except for the firewall, all incoming mail must be routed to the firewall with MX records. All outgoing mail needs to be sent to the firewall which will forward it to its final destination. The details of setting up post.office in a firewalled environment are discussed in section 3.A.3.

3.A.2 ADDRESSING AND ROUTING WITH `POST.OFFICE`

Addressing and routing are fundamental concerns when setting up your network, from assigning addresses to accounts to setting up alias, routing tables and MX records on other hosts. Various ways of handling addressing and routing are discussed bellow, and will reappear frequently in the examples discussed in section 3.A.3.

ACCOUNT ADDRESSES

post.office account addresses are very powerful. Any number of addresses (aliases) can be assigned to an account, which are used to determine if a piece of incoming mail should be delivered to the account. Accounts can be configured to rewrite the "From:" header of outgoing mail to list the account's official address. These features can be used to assign arbitrary addresses (such as First.Lastname) to each user and/or to implement hostname hiding, which is discussed later in this chapter.

It is trivial to handle several domains on a single machine -- simply assign the addresses to the desired accounts and post.office will recognize them. Addresses within one domain are independent of any other domain. For example, an account with the address <joe@some.domain> is different from an account with the address <joe@some.other.domain>.

LOCAL MAIL DOMAINS

The list of Local-Mail-Domains (LMD) is used to tell post.office that it alone knows every recipient in those domains. post.office will never attempt to deliver a message to these domains using a network protocol such as SMTP. If a message arrives for a recipient in one of the listed LMD's, post.office first attempts to find an account or channel alias for the recipient. If that fails, post.office will return an error report to the sender rather than attempt to forward it to the domain. This feature is used primarily to prevent people from attempting to deliver mail to PC's or other computers that are not running a mail server, or when several domains are being served by a single mail server running post.office.

CHANNEL ALIASES

Channel aliases are a simple address-rewriting way to redirect mail. A channel alias consists of two pieces of information, an incoming address and an outgoing address. Whenever a piece of mail arrives containing the incoming address of one of the channel aliases, the matching address is replaced with the outgoing address. The mail is then redirected to its new destination, generally to a different machine.

MAIL ROUTING TABLE

The Mail-Routing-Table (MRT) provides a way to redirect mail based on the domain to which it is being sent. Each entry in the MRT consists of a pattern and a domain. Before sending a message, the destination domain is compared against the patterns in the table. If a match is found, the destination host is replaced by the domain corresponding to the pattern that matched. (Note: no addresses are rewritten; the mail is just sent off to a different host.) This feature is useful for sites behind a firewall, or ones that have gateways to other networks such as UUCP or BITNET.

MX RECORDS IN THE DNS

Mail exchanger (MX) records in the Domain Name System provide a way to tell the outside world how to route mail to your domain(s). For each mail domain you can specify the hosts that should be contacted when attempting to deliver a message to the domain, along with the order they should be tried. The basic use for MX records is to specify one or more "third-party" machines that collect mail during temporary network outages. This is a must for poorly connected sites who use SL/IP or PPP to access the Internet and are only connected a few hours per day.

For sites that reside behind an Internet firewall, MX records are used to direct all incoming mail to the firewall machine (since no other machines are reachable). The firewall then relays the mail to its final destination on the internal network.

A very similar situation exists for sites that have domain-based E-mail addresses (as opposed to host-based addresses) requiring one or more mail hubs. MX records channel all incoming mail into the hubs which then relay the messages to their final destinations.

MX records also enable the creation of "virtual domains" that have no machines connected to the Internet, yet are accessible via E-mail. A network provider will often set this up for a customer who has registered a domain name. The network provider advertises MX records for the virtual domain that point to their own mail servers, and the mail is delivered to the virtual domain, for example over a UUCP connection, or by some other method.

3.A.3 EXAMPLE SETUPS

In this section, several scenarios are presented which cover most typical setups. Though your exact situation may not be covered exactly by one these examples, ideas can be pulled from the various examples as suits your situation allowing you to design a system which meets you needs.

Each example describes what is being accomplished and then explains how to set up post.office to achieve the desired effect. The first two examples cover the basic types of addressing (host- and domain-based) and the last two deal with issues unrelated to user addressing, and therefore build on the first two examples.

THE BASIC SETUP

The basic scenario is used to replace a typical sendmail installation. Sites that have sendmail now and want to make the minimal changes necessary to get post.office running should follow along this model. (If you implemented a domain-based addressing scheme using your current mail server software, skip to the next section which covers hostname hiding.)

Scenario:

All machines are directly connected to the Internet.
Users send and receive mail addressed from/to a single specific computer.
User addresses are based on their login ID.
Users use mail utilities that access their maildrop file (e.g. /var/mail/login_name) such as mailx.
Each machine acts independently; messages are sent and received directly to/from other machines on the Internet.

Network Diagram:

Figure 3.A.3a: Janie's address is Janie@xanadu.podunk.edu and her mail is delivered to her maildrop file: /var/mail/janie.

Special installation instructions:

When running Install, you will be asked if you want all existing users to be added to the account database. You definitely want to let it do this since it will save you a lot of work and get you very close to your original sendmail setup. The only major task it does not do is wade through your aliases file and users' .forward files.
When asked if you want users to receive mail addressed to the domain in addition to the host, you MUST answer "no" (the default) or users' outgoing mail will have a domain-based return address and "From:" header, which will not be usable unless the instructions for Hostname Hiding are followed (see the next example for these instructions).

MX records:

Each machine may have MX records that point to itself, and optionally to one or more backup hosts. MX records are not really necessary in this scenario since each computer has an A (address) record. When MX records are set up, they may look like this:


xanadu.podunk.edu.	IN  A	123.45.6.78

			IN MX	10 xanadu.podunk.edu.

			IN MX	20 hub.podunk.edu.

Janie's account:

This example (figure 3.A.3b) shows how Janie's account is set up in this situation. Users on the machine xanadu.podunk.edu have their mail delivered to their maildrop file. Their addresses are based on their UNIX login. Since post.office rewrites Janie's "From:" header on outgoing mail, she is sure that recipients will be able to reply to her messages.



  User's-Real-Name:          [Janie Lee]

  Internet-Addresses:        [janie@xanadu.podunk.edu]

  From-Address-Rewrite:      [comment]

  UNIX-Delivery:             [Yes]

    UNIX-Login-Name:         [janie]

Figure 3.A.3b: Janie's account form settings. Only relevant fields are shown.

Local Mail Domains:

None are needed (local machine is always implicitly on the list)

Mail Routing Table:

No entries are needed, but they can be added if you want. See other examples for uses of the Mail-Routing-Table.

HOSTNAME HIDING

"hostname hiding" refers to the practice of having domain-based E-mail addresses which do not contain the name of a particular host. This effect can be achieved almost as easily as Janie's setup. You will need one or more machines, commonly called mail hubs, to process all incoming mail and distribute the messages to the particular client computer that houses a user's account. Of course you can set up hostname hiding even if you only have one machine acting as both hub and client.

Scenario:

All machines are directly connected to the Internet.
Users send and receive mail addressed from/to their domain (or sub-domain).
User addresses are based on their login ID.
Users use typical mail utilities that access their maildrop file (e.g. /var/mail/login_name) such as mailx.
Mail hub(s) are required to forward incoming mail to client machine(s).

Network Diagram:

Figure 3.A.3c: All messages for the domain podunk.edu go through the hub machine. On the hub host, Janie has an SMTP channel alias [<janie@podunk.edu><janie@xanadu.podunk.edu>] that points to Xanadu.

Special installation instructions:

When running Install, you will be asked if you want all existing users to be added to the account database. You definitely want to let it do this since it will save you a lot of work and get you very close to your original sendmail setup. The only major task it does not do is wade through your aliases file and users' .forward files.
When asked if you want users to receive mail addressed to the domain in addition to the host, you should answer "yes" so that users' outgoing mail will have a domain-based return address and "From:" header. Note that this only applies to accounts created by Install -- you must manually configure new accounts as shown below.

MX records:

There MUST be MX records for your domain, or mail addressed to your domain will not be deliverable. The MX records should point to each of your hub machines, most likely with equal preference. Backup mail exchangers are recommended and should have lower preference (higher number). Your MX records should look similar to this example:


podunk.edu.		IN MX	10 hub.podunk.edu.

			IN MX	20 mx1.backup.net.

Hint: some existing (old) mail software does not understand MX records, so it is often a good idea to add an A record for your domain. The address should be that of one of your mail hubs.

Each client machine should have MX records that point to itself, and optionally to one or more backup hosts (usually the hub machines). For example:


xanadu.podunk.edu.	IN  A	123.45.6.78

			IN MX	10 xanadu.podunk.edu.

			IN MX	20 hub.podunk.edu.

User accounts:

This example shows how Janie's account is set up on a client machine supporting hostname hiding. Each user on the machine xanadu.podunk.edu has their mail delivered to their maildrop file ("UNIX" delivery) and their addresses are based on their login ID. It is important that both the domain-based and host-based addresses are present in each account so that mail can flow into and out of the system correctly. It is equally important that each user have a From-Address-Rewrite specified, so post.office will rewrite their "From:" headers on outgoing mail to include their primary (first in the list) address (Figure 3.A.3d).



  User's-Real-Name:      [Janie Lee]

  Internet-Addresses:    [janie@podunk.edu]

                         [janie@xanadu.podunk.edu]

  From-Address-Rewrite:  [comment]

  UNIX-Delivery:         [Yes]

    UNIX-LoginName:      [janie]

Figure 3.A.3d: Janie's account set up for hostname hiding.

Channel Aliases:

Each hub needs to have a list of channel aliases for every user that can receive mail addressed to the domain. The aliases need to redirect mail to the specific machines that hold users' accounts. In the above example, the required channel alias (on the "SMTP aliases" form) is:



   Aliases:           [<janie@podunk.edu> <janie@xanadu.podunk.edu>]

Figure 3.A.3e: Janie's channel alias on the SMTP aliases form

Note: if you set up a single machine for E-mail for your domain, it acts as both the client and the hub without the need for channel aliases; however, each account should still contain both forms of addresses so that UNIX-based mail programs will work correctly (not to mention that this will also save you a lot of work if you ever expand to multiple machines).

Local Mail Domains:

Each hub MUST list the domain (use the system form), since it knows where every account is located. If this is missing, the Postmaster will see lots of "MX loop" error messages. A loop exists when the highest preference mail exchanger for a domain tries to forward a message to the domain and realizes it would send it to itself.
No client machine should need any entries.

Mail Routing Table:

No entries needed, but may be added as desired. The next two examples illustrate the uses of the mail routing table.

BEHIND A FIREWALL

An Internet firewall provides security for a site by restricting or preventing access to internal machines by outside computers. A typical firewall is safe from hostile users of the Internet since it allows no direct connections to any internal machines, and relies on proxy servers or other trusted programs to carry communication across the divide.

A firewall introduces complexity to the delivery of mail between outside organizations. Since the firewall prevents direct connections between internal and external hosts, mail needs to be routed through the firewall in both directions. This is handled with a combination of MX records and the SMTP mail routing table for incoming and outgoing mail respectively.

Scenario:

Local network is protected from the Internet by a firewall machine.
Users have either host- or domain-based addresses as desired -- see previous examples for specifics on how to do this.

Network Diagram:

Figure 3.A.3f: Diagram of a firewall scenario.

Special installation instructions:

Follow the instructions for either host-based or domain-based addressing provided in the first two scenarios.
If post.office is installed on the firewall itself and domain-based addresses are to be used, the firewall can act as the mail hub and should include a complete list of channel aliases for distributing mail to internal hosts.

MX records:

If you have a single DNS server on the firewall machine that answers requests from both internal and external hosts, your MX records for a host should point to the host first, then the firewall, and then any backup sites on the Internet (outside your network):


xanadu.podunk.edu.	IN MX	10 xanadu.podunk.edu.

			IN MX	20 firewall.podunk.edu.

			IN MX	40 provider.net.

For sites that hide their hostnames, MX records are needed for the domain as usual. These should point to the mail hub(s) first, then the firewall, and then to any backup sites.

Another option is to run two DNS servers -- one on the firewall for outside hosts and one on an internal machine for internal use only. The external DNS server (the one on the firewall) can be set up to give out very little information about the network. In fact, it can be set up with a wildcard MX record that says to just send all mail for any host in the domain to the firewall. Here's an example accomplishing that:


podunk.edu.	IN  A	123.45.6.78   ; for dumb mailers

		IN MX	20 firewall.podunk.edu.

		IN MX	40 provider.net.

*		IN MX	20 firewall.podunk.edu.

		IN MX	40 provider.net.

The internal DNS server should contain the detailed information about the internal network and all internal hosts should be configured to use that server in preference to the external server.

Mail Routing Table:

The firewall machine should not need any explicit routes since it can directly contact any internal or external machine.
Since the firewall is the only machine capable of delivering outgoing mail, you should set up every other machine with a default route to the firewall. A default route by itself will send all mail, including internal mail, to the firewall, so you need to also have entries in the table for your local domain that override the default. This example accomplishes that:



  Mail-Routing-Table:  [podunk.edu:*]

                       [*.podunk.edu:*]

                       [*:firewall.podunk.edu]

Figure 3.A.3g: Mail routing table for a firewall scenario.

INTERMITTENTLY CONNECTED SITE

An "Intermittently Connected Site" is one that lacks good connectivity to the Internet, yet uses TCP/IP for communication. Typically these are sites that have a dial up connection to an Internet Provider and use either SL/IP or PPP to carry their packets over a phone line. Such sites are usually only "connected" for a few hours per day, or less. As such, they have some special requirements which are addressed here.

Such sites typically want to be able to connect up to the Internet, receive all their incoming mail, send all their outgoing mail, and then disconnect. For this to work, the site needs to have all their mail collect at a single location, such as their Internet provider, while they're not connected. Similarly they would like all outgoing mail delivered efficiently to minimize connect time. For best efficiency, it can all be dumped to an external site such as the Internet provider who then forwards the messages to their final destinations. These two concepts are discussed in this section.

Scenario:

Local network is seldom connected to the Internet
When connected, all machines have direct access to the Internet
Users have either host- or domain-based addresses as desired -- see previous examples for specifics on this

Network Diagram:

Figure 3.A.3g: Typical setup for an intermittently connected site.

Special installation instructions:

None. Follow the installation instructions for either host-based or domain-based addressing provided in the first two scenarios.

MX records:

Each machine should have MX records that point to itself first, and then to one or more backup hosts. The Internet provider should have the lowest preference (highest number) of all mail exchangers since it should be used only in the case where the dial up connection is down. For example:


xanadu.podunk.edu.	IN  A	123.45.6.78

			IN MX	10 xanadu.podunk.edu.

			IN MX	20 hub.podunk.edu.

			IN MX	40 provider.net.

In this scenario, the number of extra mail exchangers on the "inside" should be small to minimize the impact on outside hosts that try to send you mail while your network is not connected.

Mail Routing Table:

To achieve the most efficient delivery of outgoing mail, you should set up a default route to a single well-connected site (make sure you have an agreement with the other site before you set this up!) such as your Internet provider. A default route by itself will send all mail, including internal mail, to the default machine, so you need to also have entries in the table for your local domain that override the default. This example accomplishes that:



  Mail-Routing-Table:  [podunk.edu:*]

                       [*.podunk.edu:*]

                       [*:provider.net]

Figure 3.A.3h: Mail routing table for an intermittently connected site.

Recall that a "*" after the colon means to send directly to the matching host (actually to one of its mail exchangers -- the MRT does not override MX routing). Thus any mail destined for a host in the podunk.edu domain will be delivered directly to podunk and any other mail will be sent to the Internet provider who then forwards the mail to its proper destinations.

Retrieving Messages From An Intermittently Connected Site

Messages can be retrieved from the backup host by telneting to the SMTP port and using the "qsnd" command. See chapter 6 for details.

3.B.0 INSTALLATION INSTRUCTIONS (UNIX VERSION)

In order to install post.office, you must:

1. Go through section 3.B.1: pre-installation planning, to ensure that you are prepared to install the program. It is also a good idea to look at appendices A* and B which contain important information related to installation.

2. Follow instructions set out in section 3.B.2: Installing post.office.

3.B includes a section to assist you with any common installation mishaps (3.B.3). We conclude with de-installation instructions should the need arise (3.B.4).

*Note: If you are setting up a mail system for the first time or are thinking about re-configuring you mail system and are not clear on what your options are, you may want to review the first part of this chapter, Setting up your E-mail network, which illustrates some of the more common message system configurations.

3.B.1 PRE-INSTALLATION PLANNING

This section will help you plan a strategy for installing post.office. A checklist is provided for you to fill out with your choices of parameters. To install post.office you will need to create a new user and group for the mail system, and decide where to install each of the parts of the system. The following sections explain each of the decisions you will make, and offer suggestions for optimum performance and security.

If you are planning to install post.office on several machines or your site has some special needs, consult section 3.A before installing post.office. It covers setting up post.office in a distributed (multi-host) environment including such topics as domain-based addressing (hostname hiding), mail exchangers, and firewalls.

Also if you haven't done so already, please take a look at Appendix F for the current status on sendmail compatibility.

3.B.1.1 ESTABLISH WHAT MAIL SYSTEM YOU ALREADY HAVE

Since you are about to replace your current mail system, you probably already know which one you have. Most likely you are running sendmail, since it is included with the majority of UNIX-based operating systems. A quick way to find out which MTA is running on your machine is to connect to the mail port and check the greeting line. Here is a sample telnet session that does this:

% telnet localhost 25

Trying 127.0.0.1 ...

Connected to localhost.

Escape character is '^]'.

220 rome.software.com Sendmail 5.0/SMI-SVR4 ready ....

quit

221 rome.software.com closing connection

Connection closed by foreign host

%

In this example, the MTA running on the local machine is a version of sendmail. If you are not running sendmail on your machine, some of the installation process may be different than what you find in this chapter since it is assumed that is what you are replacing.

If by chance you are not running any MTA, the telnet session will generate the following error message:

% telnet localhost 25

Trying 127.0.0.1 ...

telnet: connect: Connection refused

telnet> quit

%

If you are not running a mail system, it's a good thing you're installing post.office.

3.B.1.2 YOUR DNS DOMAIN

Most sites installing post.office are already connected to the Internet and have a registered domain name. During the installation you will be asked for the domain name of the computer on which you are installing the system. This may be your organization's domain name, or possibly a subdomain. For example, if you were installing post.office on a machine named emile.math.ucsb.edu, the domain name you would specify is math.ucsb.edu.

3.B.1.3 SETUP USER AND GROUP FOR `POST.OFFICE`

One of the important security features of post.office is that the system runs as a non-privileged user. Before installing the system, you should create a new user that has no special permissions. All mail system programs run as this user so the system has no privileged access to sensitive files. The primary group of this new user should also be newly created and have no members (other than the new user) since anybody with permissions of the group can read mail stored in the queue or users' POP mailboxes. Specifically the mail group should be avoided since it is used by the UNIX mail system.

	Suggestion	Your choice
User Name	`mta`
Group Name	mta

3.B.1.4 LOCATIONS OF PROGRAMS AND WORKING DIRECTORIES

post.office is broken up into three major parts: the executable programs, the mail processing center (or postoffice), and the message store (or user mailboxes). The locations for each of these directories can be customized during the installation. Note that it is not a good idea to use NFS mounted directories for any part of the system, unless file locking works reliably.

THE POSTOFFICE DIRECTORY

The postoffice is a directory where mail is processed. All incoming mail is stored in the postoffice and remains there until it is either successfully delivered or returned. Often mail resides in the postoffice for only a few seconds as it is routed to its destination; however, if a message is destined for a remote computer that is temporarily unreachable, the message can remain queued up in the postoffice for several days, depending on how the system is configured. Typically the /var partition is used for such storage.

Make sure you put the postoffice in a place that gets backed up regularly since it also contains all the configuration information and the account database.

	Suggestion	Your choice
Postoffice	`/var/spool/post.office`

THE MAILBOX DIRECTORY

The mailbox directory is where mail is stored for users that retrieve their messages via the network using the Post Office Protocol (POP3). The amount of storage needed for this directory depends on the number of users that use POP3, the volume of mail they receive, and whether they leave their mail on the server or download it to their PC or workstation. The mailbox directory may require less storage than a traditional UNIX mail directory since only one copy of a message is kept regardless of the number of recipients.

This directory should also be backed up regularly since it contains users' mail.

	Suggestion	Your choice
Mailbox	`/var/spool/mailbox`

THE EXECUTABLES DIRECTORY

The executable programs that constitute post.office are all located in a single directory tree. This directory should not be located on the disk that also houses the postoffice if you can avoid it. Typically this directory will be in either /opt or /usr/local depending on your conventions.

	Suggestion	Your choice
Executables	`/usr/local/post.office`

3.B.1.5 CHANGES TO EXISTING FILES AND SERVICES

Because post.office replaces services you already have, the installation process will alter some system files. The number of modifications is small and each is described in this section.

EFFECT ON YOUR EXISTING MAIL SYSTEM

post.office replaces your current mail transport agent such as sendmail or smail. It does not, however, replace any mail user agent software you are using. Since post.office is designed to be upwardly compatible with your existing mail infrastructure, all UAs should continue to operate normally when post.office is installed as the MTA.

Notes Regarding sendmail Replacement

post.office is designed to be a drop-in replacement for sendmail in most installations (see appendix F for a discussion of compatibility). In order to be upwardly compatible, there is a replacement sendmail program provided with the system that emulates much of sendmail's functionality. The sendmail replacement is discussed at length in the sendmail compatibility appendix.

When post.office is installed, the sendmail executable on your machine is saved as sendmail.bak and a symbolic link is put in its place that points to the replacement program. This design choice lets you continue to run software that uses sendmail to deliver mail, etc. without modification. Also if there is a reason you want to disable post.office and enable sendmail, simply remove the symbolic link and rename sendmail.bak as sendmail. You then need to shutdown post.office (see command line operations in chapter 6) and start up sendmail.

Note: UUCP is not currently supported in post.office; the sendmail replacement has enough knowledge of UUCP to convert simple !-addresses to domain addresses, but delivery via UUCP is not implemented. As an example, host1!host2!user is rewritten as user%host2@host1 which then gets sent off to host1.

As a sendmail administrator, you have probably learned to do things like maintain the aliases database, set up UNIX accounts for each mail user, configure .forward files, and perhaps even modify the sendmail.cf file to rewrite addresses or do some customized routing. With post.office you don't have to do any of this; all alias and delivery information is kept in an internal account database, and address rewriting is all but eliminated.

The changes in the way things are done will simplify your job as a mail administrator so you can concentrate on setting up accounts rather than debugging configuration files. To find out everything you can do with mail accounts in post.office, please see the operations chapters which follow.

EFFECT ON OTHER FILES AND SERVICES

In addition to the mail transport agent, post.office contains a POP3 server, and a finger server. These are integrated into a single system rather than being a collection of individual services.

Finger

Typically UNIX workstations are shipped with a finger server that runs under inetd (the Internet daemon) and gets its information from /etc/passwd and each user's .project and .plan files. The installation process will disable the finger server by editing your inetd.conf file, and then resetting the inetd process (by sending it a HUP signal). At the same time every user's project and plan files will be loaded into the account database. This is the only time these files will be accessed; the finger server always pulls user information out of the post.office account database. Users will be able to change their finger information using the information form, which allows them to make limited changes to their account information (see chapter 5 for details).

Post Office Protocol (version 3)

If you have a POP3 server running on your machine, it is most likely a local customization since POP3 doesn't usually come as part of a stock UNIX system. The available POP3 servers read users' maildrop files which are typically located in /var/spool/mail or /var/mail. In post.office, users that retrieve their mail via POP3 have their mail stored in a special part of the system called the message store or the mailbox directory. This design choice eliminated the need to parse the various formats of UNIX maildrop files, removed the requirement that each mail recipient have a UNIX login account, as well as allowing for several other efficiencies. The one drawback with this design is that a user can not easily alternate between reading mail via POP3 and via standard UNIX mail programs.

If your POP3 server is launched by inetd as is the finger server, then it will also be disabled in the inetd.conf file. However, if it is a standalone daemon process, disabling it requires a bit of your help. First the daemon has to be killed, and then the commands in the boot script which starts it up have to be disabled.

3.B.1.6 THE ROLE OF THE POSTMASTER

During installation you will have to choose who the postmaster is going to be. On UNIX systems running sendmail, the postmaster or mail administrator is usually the same person as the system administrator. Mostly this is due to the fact that root privileges are required to make any changes to a sendmail-based mail system. Activities that require root privileges include adding and removing UNIX accounts, and editing the aliases and sendmail.cf files. Without being able to perform all of these tasks, you would be severely constrained in your ability to administer the mail system.

Fortunately with post.office none of the equivalent tasks require root permission. Instead, anybody listed as a recipient of mail addressed to <postmaster@your.domain> is considered a postmaster (you can also grant postmaster privileges via the web by giving people the postmaster password and having them log on as "postmaster").

Having postmaster privileges in post.office is similar to having root privileges for administering sendmail. Each postmaster is able to configure mail system parameters, add, modify, and delete mail accounts, and set up automatic repliers. Since none of these tasks require root privileges, the system administrator can safely appoint someone else to the position of mail administrator, thus reducing the system administrator workload.

Postmasters interact with the mail system either by sending it mail or logging on to the post.office host with a web browser. The postmaster does not have to be a local user of a machine to be able to configure it. In fact all configuration and account changes for an entire E-mail network can be handled from a remote site. Chapters 4, 5 and 6 contain information regarding remote configuration of post.office.

3.B.1.7 IMPACT OF MIGRATION FOR MAIL SYSTEM USERS

Typically there are three methods used to access mail on a UNIX machine: accessing the maildrop file directly, using a POP3 server, or using an IMAP (Internet message access protocol) server.

The first method is probably the most common since all standard programs such as mail and mailx read the maildrop file directly. Users who access their mail this way will not have to change what they do.

Those users who access their mail via POP3 exclusively should also few changes if their account is set up to deliver their mail to the message store. If not, their mail will collect in their UNIX maildrop file until their account configuration is corrected (note that no mail will be lost).

IMAP is probably the least common of the three methods since it is a new technology, though similar to POP3. post.office does not currently contain an IMAP server so you can continue to run your own if you have one. It will access users' maildrop files as it always has.

If any users regularly switch between POP3 and other access methods, they may find that the switch to post.office requires them to rethink how they collect their mail. Either they will have to choose a single method of mail access, have messages sent to both their UNIX maildrop and the post.office message store, or switch the delivery method in their account between UNIX and POP3 as their needs dictate. Users who opt to change regularly between the two deliveries will find that the information form allows them to do so quickly and easily, either via E-mail or by using the web.

Note: when switching between UNIX and POP deliveries, any accumulated mail will remain where it was, and appear to be "lost" when using the new type of access. This occurs because the POP server does not read the UNIX mail spool file for users' mail and vice versa. Users who experience problems as a result should select both delivery methods concurrently so that they have their full set of messages available to them however they check their mail. (This will of course result in a somewhat awkward duplication).

CREATING NEW USER ACCOUNTS

post.office will automatically create new E-mail accounts for everyone with UNIX accounts on the host it is installed on, if you so choose (Recall that post.office accounts are not linked in any way to UNIX accounts, except that during installation post.office will automatically open accounts for all users with UNIX accounts, if you want it to).

Every time post.office opens an account for a user, that user will receive a message from post.office called the greeting form. The idea of the greeting form is to welcome the user to their account and let them know how to change their password and whatnot (see below). Thus one consequence of installation may be that all the users on your host will get this message:

To: user@your.host

From: Account-Manager@your.host

Subject: Form: Greeting

And any other headers....

---------------------------------------------------------------------------

Information

An electronic mail account has just been opened for you. This account is 

configured as indicated below. Make sure you note your password and 

safeguard it since this is the only time it will be sent to you. See the 

instructions below the account summary for information on how to make 

changes to your mail account as well as for explanations about each of the 

fields.

   Your-Name:                [Last, First Name]

        (Note: your name is sometimes referred to as your account name) 

   Mail-Account-Password:    [Lock]

   Internet-Addresses:       [First.Last@oslo.software.com]

   Finger-Information:       []

                             []

========================================================================== 

Here's some information about changing your account: 

Only the system administrator can change your name or addresses. If you 

want to change your password or your finger information, you can do so 

with a World Wide Web browser (such as NCSA Mosaic), or via E-mail. You 

simply fill out a form indicating the desired changes and submit the form 

to the mail system. To request the user Information form: 

via the Web: connect to http://

via E-mail: You can get the E-mail form to modify your 

account by simply replying to this message and sending it in, or

send a new message To: <Accounts@oslo.software.com> with the word 

"Information" as the message body like this:

To: Accounts@oslo.software.com

Information

After receiving the Information Form, make the appropriate changes to the 

form (use the "Reply" feature of your mail client if you are using 

the E- mail interface), put in your password, and submit the form. If you 

don't receive an error message, the changes have been accepted. 

========================================================================== 

Here is an explanation of each of the fields shown for your account: 

Your-Name

---------

This field is for your real name as you prefer to see it in written form. 

It is not your e-mail address, although it will be included along with 

your E-mail address on messages sent out from your account if the 

Postmaster has configured your account to rewrite the "From" 

addresses on your outgoing mail. If your name is mis-spelled, you probably 

want to let your Postmaster know.

Mail-Account-Password

---------------------

Your account password is needed to modify your account. Since it prevents 

other people from changing your account, you should keep it secret and 

change it often. This same password is used to retrieve your mail over the 

network if you use the Post Office Protocol (POP) method to get your mail. 

(POP is the method used with such mail client programs as Eudora, Pegasus, 

etc.). The password is CaSe-senSiTive, so remember exactly how it is typed. 

This is the only time your password will be presented to you; however, if 

you ever forget your password, the Mail Administrator can give you a new one.

Internet-Addresses

------------------

Your account will receive Internet mail that is sent to any of these 

addresses. All addresses are matched in a case insensitive manner so they 

may be written with any mixture of upper and lower case characters (e.g. 

Jane.Doe@Domain, and jane@host.domain). The first address is your primary 

address. It is used as the "From:" address for outgoing mail (if your 

account is configured to rewrite the "From" address on your outgoing 

mail), and is the address you should generally give out to people. 

Finger-Information

------------------

The "finger" directory service lets you find information about other 

people with E-mail accounts. The information specified here will be returned 

to other users who request it using the finger service. This information can 

be anything you desire (e.g. your postal mailing address and favorite quote). 

When someone "fingers" your E-mail, the Finger- Information will be 

returned to them (as long the Mail Administrator has not limited access to 

your account).

Figure 3.B.1.7a: This is the greeting form which is sent to new users to orient them to how to get the most use out of post.office.

3.B.2 INSTALLING `POST.OFFICE`

Now that you're ready, here is a step-by-step guide to installing post.office. If you haven't gone through the previous section and planned for the installation, please do so now. A good plan at the start will make the installation run smoothly.

3.B.2.1 THE INSTALLATION PROCESS

There are three main steps to installing post.office. First the software is extracted from the archive file Post Office Installer, then it is installed on the system. Finally a special program, /.install, is run to initialize the mail system and set up accounts.

UNPACKING POST.OFFICE

The post.office system is distributed in compressed-file format. When uncompressed, the result is a series of files integrated into the MachTen operating system. To uncompress the package, first make sure that MachTen is not running. Double click the Post Office Installer to start the decompression process. You will be prompted for a directory to install into. Select your MachTen root directory. On many systems this is label MachTen Root or Machten 4.0.3 Root. To select a directory to install into, click the button at the bottom of the dialog window (not the Open button or the Install button). Once decompression is complete, you need to start MachTen and login as root user. Then execute:

# cd /

# ./install

Several questions will be asked during the installation, but you already know the answers since you went through the "pre-installation planning" in section 3.B.1.

The install program shuts down your existing mail and finger services, sets up mail accounts, and starts up the post.office system. If at any time you quit out of the install program, you can run it again later to finish the installation process.

The flowchart below (figure3.B.2.1a) outlines the steps taken by the post.office installation program.

Figure 3.B.2.1a: Installation Flowchart -- The above flowchart illustrates the steps taken by the post.office installation program. 1: The mailbox directory is used to store messages for users who access their mail via POP3. 2: The install program will offer to set this permission bit for you. 3: These are a few special accounts (described in the operations portion of the manual) which are required for operation. 4: If you select this option, a summary of the created accounts will be mailed to you at the end of installation. 5: The postmaster account is the account which allows you to configure and oversee the operation of the post.office system. See operations chapters for details. 6: The installation program checks for services (e.g. SMTP, finger, and POP3) in the services database; it will offer to add them to /etc/services if they are missing).7: The installation program checks the configuration file of inetd to see if it is set up to handle any of the services in post.office; it will disable them by editing the inetd.conf file and resetting the inetd process. 8: You should be aware by now if you are replacing sendmail with post.office. If not, go back to pre-installation planning and make sure that you know what you are doing. 9: This link is set up so that the post.office sendmail replacement program can be run, for example by other programs that use sendmail commands to carry out certain tasks. See Appendix F for details. 10: This is necessary so that post.office can monitor, for example, the SMTP and POP3 ports. 11: You're done! Note that any loose ends will be summarized at the end of installation.

FINISHING UP

When you're done with Install, it may tell you that some things still need to be taken care of. If so, write them down and perform the tasks when you get a chance. In any case, the system should be running so you can start exploring the variety of features of post.office.

3.B.2.2 POSTMASTER AND PERSONAL ACCOUNTS

The installation program you just ran helped you to set up postmaster and personal accounts. This section's purpose is to ensure that you understand the function of the different accounts so that you can get the most out of them.

THE POSTMASTER ACCOUNT

The purpose of the postmaster account is:

To define who is given access to post.office configuration and operation.
To define the individual or individuals who are responsible for day to day supervision of the mail system.

These two purposes are closely related. However they are not identical.

The first point asserts that when you are postmaster, you have the keys to the car (Note that you can have as many sets of keys as you like).

The reason that you and perhaps a few other postmaster cronies are given the "keys" to the system are less to create an E-mail nomenclatura then to establish strict security controls over who has access to the system. If there are too many postmasters, or the postmaster account becomes public domain, then you are short-circuiting one of the primary security mechanisms of your mail system.

You will use your position as postmaster to set up new accounts, make configuration changes to the system, and take care of any errors that occur.

You will find that in most cases, too many cooks can spoil the batter. In general, your mail system will function better if only one or a few people are entrusted with mapping out and implementing an E-mail game plan.

The algorithm for who is a postmaster is simple: Anybody who's E-mail address is listed in the postmaster account delivery field is a postmaster. You do not need to have an account on the post.office host in order to be a postmaster. (Note that you can also give an individual access to postmaster forms by giving them the postmaster password and having them log on to the web using the address "postmaster@your.host." This gives someone access only to the forms: they will not receive error messages or any other E-mail addressed to the postmaster address).

The second purpose of the postmaster account is that it identifies the responsible party or parties for all E-mail related questions.

The postmaster is responsible for dealing with any errors which crop up. For example, most frequently this will mean invalid addresses. The postmaster has to decide whether messages with such addresses should be returned to their sender or forwarded to a user on the system.

The postmaster is also the person most often turned to when folks outside your E-mail network have a question about how to contact someone in your organization, or other E-mail related questions. It is conventional that every domain support the "postmaster@domain" address, so that the outside world can have a contact on your network.

Note: the postmaster account is not a personal E-mail account. Even if you are a postmaster, you should have a personal account to which all your personal correspondence should be addressed. You should then include the address for your personal account in the delivery field of the postmaster account, so that you will have postmaster privileges on the host and be able to access both E-mail and web forms.

PERSONAL ACCOUNTS:

The purpose of a personal account is to give an individual access to E-mail. In some cases accounts can also be used to deliver mail to a program or to automatically distribute information (using the auto-reply utility).

Thus the postmaster(s) should have a personal E-mail account in order to have access to E-mail as well as to be able to have access to post.office E-mail forms.

Users who have personal accounts on a host can receive mail through that host, as well take advantage of other features such as having their addresses re-written on outgoing messages, having finger queries answered, and advising correspondents when they are on vacation (using the auto-reply utility).

3.B.2.3 WHERE TO GO NOW

If everything went OK, you can now go on to the Operations Chapters which follow to learn how to run the system. But first, please note section 3.B.3.2 below (regarding changing the Postmaster account) since you may find it useful someday.

3.B.3 COMMON INSTALLATION MISHAPS

3.B.3.1 RERUNNING INSTALL

If you quit out of the Install program before it is finished, you can simply rerun it later to complete the installation process. The post.office system will not be started until you explicitly tell Install to start it, and it will warn you if any problems need to be taken care of before the system can be started. Once the system is up and running, Install is used only to work your way out of a jam.

3.B.3.2 CHANGING THE POSTMASTER ACCOUNT

It is possible to accidentally configure post.office so that there are no valid postmasters. If this happens, the system will not allow further configuration changes, e.g. to fix the problem with the postmaster account. Because of this dead-end proposition, we give you a way out. Simply rerun Install to make the necessary changes to the Postmaster account. Install asks you to enter a new password, and to set the deliveries to each of the intended postmasters.

3.B.4 DE-INSTALLATION

Although it is believed that you will be completely satisfied with post.office, if you want to remove it from your system, this section will tell you what to do.

3.B.4.1 THINGS TO CHECK

Before removing post.office from your system, check that there is no deferred mail waiting to be delivered. The queue form can be used to check this, as well as to deliver the queued mail (see discussion of the queue form in chapter 6 for details).

Also if you have any users retrieving their mail via POP3, their mailboxes may contain unread mail. Removing post.office from your system won't delete this stored mail, but it will be hidden from the users since only the post.office POP3 server is able to access the mail.

3.B.4.2 REMOVING `POST.OFFICE`

Removing post.office is fairly simple. Once you are satisfied that no undelivered mail is still in the system (see previous section), follow these instructions:

Become the superuser

% su -

Password:

Tenon Intersystems MachTen March 1993

#

Replace sendmail in /usr/lib

# cd /usr/lib

# ls -lF sendmail*

lrwxrwxrwx 1 root sys 27 Jul 17 20:44 sendmail -> ../../opt/mail/bin/sendmail*

-r-sr-x--x 1 root bin 126832 Dec 20 1993 sendmail.bak*

# rm sendmail

# mv sendmail.bak sendmail

Edit /etc/inetd.conf

Remove the '#' in front of the services that were disabled:

telnet stream tcp nowait root /usr/sbin/in.telnetd ....

#finger stream tcp nowait root /usr/sbin/in.fingerd ....

time stream tcp nowait root internal

Reset the inetd process

# kill -HUP inetd_process_number

Remove the postoffice directory

# rm -rf postoffice_directory

Remove the mailbox directory

(You may want to save the mailbox directory to make sure POP3 users have received all their messages.)

# rm -rf mailbox_directory

Halt MachTen

# reboot -q

From the Macintosh finder open Machten Root/usr and drag post.office to the trash. Then open
MachTen Root/var/spool and drag post.office to the trash. Pull down the special menu and remove trash.

UNIX PLATFORM

3A: SETTING UP YOUR E-MAIL NETWORK 3B: INSTALLATION

3.A.0 SETTING UP YOUR E-MAIL NETWORK

3.A.1 THINGS TO CONSIDER WHEN DESIGNING YOUR NETWORK

SYSTEM LOAD

ADDRESSING

USER ACCESS TO E-MAIL

CONNECTIVITY TO THE INTERNET

FIREWALL CONFIGURATION

3.A.2 ADDRESSING AND ROUTING WITH POST.OFFICE

ACCOUNT ADDRESSES

LOCAL MAIL DOMAINS

CHANNEL ALIASES

MAIL ROUTING TABLE

MX RECORDS IN THE DNS

3.A.3 EXAMPLE SETUPS

THE BASIC SETUP

HOSTNAME HIDING

BEHIND A FIREWALL

INTERMITTENTLY CONNECTED SITE

3.B.0 INSTALLATION INSTRUCTIONS (UNIX VERSION)

3.B.1 PRE-INSTALLATION PLANNING

3.B.1.1 ESTABLISH WHAT MAIL SYSTEM YOU ALREADY HAVE

3.B.1.2 YOUR DNS DOMAIN

3.B.1.3 SETUP USER AND GROUP FOR POST.OFFICE

3.B.1.4 LOCATIONS OF PROGRAMS AND WORKING DIRECTORIES

3.B.1.5 CHANGES TO EXISTING FILES AND SERVICES

3.B.1.6 THE ROLE OF THE POSTMASTER

3.B.1.7 IMPACT OF MIGRATION FOR MAIL SYSTEM USERS

3.B.2 INSTALLING POST.OFFICE

3.B.2.1 THE INSTALLATION PROCESS

3.B.2.2 POSTMASTER AND PERSONAL ACCOUNTS

3.B.2.3 WHERE TO GO NOW

3.B.3 COMMON INSTALLATION MISHAPS

3.B.3.1 RERUNNING INSTALL

3.B.3.2 CHANGING THE POSTMASTER ACCOUNT

3.B.4 DE-INSTALLATION

3.B.4.1 THINGS TO CHECK

3.B.4.2 REMOVING POST.OFFICE

3A: SETTING UP YOUR E-MAIL NETWORK
3B: INSTALLATION

3.A.2 ADDRESSING AND ROUTING WITH `POST.OFFICE`

3.B.1.3 SETUP USER AND GROUP FOR `POST.OFFICE`

3.B.2 INSTALLING `POST.OFFICE`

3.B.4.2 REMOVING `POST.OFFICE`