| This appendix provides a rough map of post.office architecture. | |
post.office SOFTWARE ARCHITECTURE | ||
This appendix contains a comprehensive discussion about the conceptual architecture employed in the design of the post.office software . Most people don't need or have much interest in this information. This is information which is dry, detail which is unbearable, even according the unbelievably stultifying standards of the manual-aficionado community
Unless you are the type of person who looks under the hood before renting a car, asks for the ingredients list when dining at a restaurant, and wish you knew how your favorite word processing program was designed rather than just how to use it, you don't need to read this. If you happen to be one of the few people who need to assess the software architecture to alleviate security concerns or are just so plain curious you read the dictionary for fun, this one's for you!
As mentioned briefly in Chapter 2, post.office functions are distributed among a number of software modules which work together to carry out message handling and other activities.
This appendix begins with the basic architecture discussed in Section 2.2 which is reproduced in figure C, below. From there, each component is broken down and picked at in further detail in Sections C.1 through C.6. Finally, the Architecture "Big Picture" including all the detail is shown in Section C.7.
Figure C (below) shows post.office broken down into five major functional pieces which run under the supervision of the dispatcher (not shown). We will refer back to this top-level architecture several times as we fill out the details of the lower-level components and the deep, dark truths about post.office.
 |
Figure C: The bird's eye view: the five components of post.office running under the control of the Dispatcher.
These five major functional pieces and the dispatcher were discussed in Section 2.2. Briefly they are:
A Dispatcher, the daemon or service component of post.office which coordinates the activities of all other modules (the dispatcher is not shown in figure C).
Account and module configuration databases which contain E-mail account information and general configuration information for the other modules.
A message transport agent which handles all message accepting, routing, and delivery tasks.
post.office managers, the computerized versions of middle management facilitate remote configuration and operation of the system and make sure that the modules are doing their job and following the rules.
The Auto-Reply Utility enables post.office to automatically reply to incoming messages with pre-defined responses of your choice (see Chapter 7 for details).
Directory services are the phone books of E-mail. The finger query server allows users to make information about themselves available to the public.
Each of these components of the post.office system are discussed individually in more detail in Sections C.1 through C.6
The dispatcher's job is simple. The dispatcher monitors all network ports related to E-mail and launches the appropriate modules to handle incoming connections. The dispatcher also controls the number of simultaneous processes which can be operating in order to limit the amount of computer resources used to process E-mail.
For example, when the dispatcher notices an incoming E-mail message, it starts up the message transport agent, which takes the message in and decides what to do with it.
In terms of figure D, the dispatcher can be thought of as an all-encompassing envelope containing and initiating the processes of all items shown within the box labeled "post.office".
Every post.office module has a database which contains all the configuration information for that module (figure C.2).
 |
Figure C.2: The Account and Module Configuration Databases have more stripes. They also contain user's account information and post.office configuration information.
For most modules, this database is fairly small, containing a few configuration options which allow you to customize the module's operation and a list of error messages.
The account database, however, holds all user account information so it can be quite large. All modules refer to the account database whenever they need account information in order to process a message or otherwise carry out a task. Since all user information is in one place, a single configuration change updates all modules at once.
post.office is first and foremost a message transport agent, or MTA (see figure C.3). Since the MTA represents the primary functionality of the entire post.office system, we will take a look at its role in much greater detail.
 |
Figure C.3: The Message Transport Agent. Don't be fooled by it's size in this figure. the MTA is a powerful and complicated set of modules that is the foundation of post.office.
A Message Transport Agent (MTA) can be used to simply coordinate message transfer between a small number of computers on a local network or to orchestrate the transfer of thousands of messages beyond the local network to the millions of on-line users around the world hooked up to such networks as the Internet.
The post.office MTA is divided into three components: message channels, the local delivery channel, and handlers (which help route messages).
Messages leaving the local host computer are sent to other MTAs through a message channel. Each message channel uses a specific protocol, such as SMTP, to format messages. post.office's primary message channel is the SMTP channel which formats messages according to the open-standard employed on the Internet (the Simple Mail Transfer Protocol).
Local mail and incoming messages for people with local accounts are delivered by the local delivery channel.
Handlers help route messages. Usually, incoming messages are sent to the account handler, which decides to whom the message should be delivered. If there is some insurmountable problem (such as a bad address), the account handler may route the message to the error handler.
These basic components of the post.office MTA are depicted in figure C.3a and will be discussed in greater detail in the following sections.
 |
Figure C.3a: The components of the post.office Message Transport Agent: message channels, the local delivery channel, and handlers.
post.office message channels exchange messages with other message transport agents and accept new messages from user agents. Message channels can relay messages to and from other modules of post.office and, in some cases, accept and dispatch messages without consulting other modules. One of the principle message channel tasks is to accept messages addressed to local recipients (users with post.office accounts) and forward them to the local delivery channel.
A message channel is a group of post.office modules which transfers messages using a single protocol such as SMTP or X400. Each channel consists of an accept agent, a routing agent, and a deliver agent, as shown in figure C.3b (which depicts the SMTP Channel).
 |
Figure C.3b: The SMTP Channel
Accept agents are modules which accept incoming messages detected by the post.office dispatcher. The accept agent can be configured to accept messages only for recipients that it recognizes (those who have post.office accounts). Also, post.office can accept messages and forward them to other message transport agents. Once a message comes in, it is immediately transferred to the message channel routing agent.
The routing agents examine the message headers and make sure that the instructions they contain are compatible with the way the message is being handled. Then they forward the message to the deliver agent (if the message is to be relayed on to another MTA), the Account Handler (for delivery to a local user), or the Error Handler (if there is some confusion with what to do with the message). Messages can also enter the message channel at the routing agent if they originated in another module of post.office (such as the auto-reply handler) or from another message channel (i.e., a different protocol).
The deliver agent sends messages to other remote MTAs which speak the same protocol (such as SMTP). It takes a message from the routing agent, contacts the remote MTA that accepts mail for the recipient of that message, and delivers the message to that MTA. Part of the deliver agent's task is to determine which remote MTA the message should be sent to.
An example of a message channel is the Simple Mail Transfer Protocol (SMTP) channel (figure C.3b above) which comes standard with post.office. Most MTAs on the Internet use SMTP to accept and relay messages.
In some cases a message is transferred solely by the SMTP channel, so that it is accepted, routed, and delivered (to another MTA) through this channel. This would be the case if the message is simply being sorted and forwarded to another MTA on the Internet or your local network. In other cases a message might be accepted by the SMTP accept agent, passed through the SMTP routing agent, to the account handler, and then delivered by the local delivery channel to a user on this particular post.office host (see next section for more information on the local delivery channel).
Another example is when a message is accepted by one message channel and must be delivered by another channel. In this case it is accepted according to one protocol and delivered according to another, so that post.office acts as a switch (or gateway) between different mail protocols.
When a message channel routing agent examines a message envelope, it may determine that the message should not be forwarded to the deliver agent. This is because the address indicates either that the message should be delivered locally or that it should be delivered according to another protocol. If this happens the message is forwarded to the account handler (discussed further in the next section), which decides what to do with the message.
When a message is transferred to another message channel, the account handler forwards it to the appropriate message channel routing agent, so for example, a message might go from the SMTP routing agent to the account handler and finally to the routing agent of the X.400 channel.
When a message is transferred to the account handler because it is addressed to a local recipient, the account handler forwards the message to the local delivery channel.
Incorporating the details of a message channel (from figure C.3b) into figure C.3a provides a more comprehensive picture of the message transport agent as shown below in figure C.3c:
 |
Figure C.3c: The Message Channels' role in itsy bitsy detail.
The local delivery channel carries out the final delivery of an E-mail message. There are several possible methods for this final delivery and they are described below.
When post.office accepts a message (with one of the message channels) that it recognizes as addressed to a local recipient (that is, someone with an E-mail account), the message is routed to the local delivery channel.
The Local Delivery Channel consists of those post.office modules which transfer messages to user agents: POP3 remote delivery, UNIX maildrop delivery, and program delivery. Only users who have post.office accounts can receive messages through the local delivery channel. (See Chapter 1 if you have any doubts about what a user agent is.)
The path (POP3, UNIX, or Program delivery) which a message takes to reach a recipient is determined by the choices made when completing the account form for a particular user (see chapter 5). If a user wishes to change how he receives his mail, he can do so using the information form without having to ask the postmaster for help.
The POP3 delivery module takes incoming mail for users and files it in the POP3 "user's mailbox" directory (Figure C.3d). The mail is then retrieved later by a user agent running on a remote computer.
Note: If you currently run an Internet Message Access Protocol or IMAP server (an enhanced protocol similar to POP3), you should continue to retrieve your messages from your UNIX maildrop file.
 |
Figure C.3d: POP3 Delivery: the message is placed in the users mailbox by the POP3 deliver program. The POP3 server retrieves any stored messages and passes them to the user agent when the user checks her E-mail.
A user who would like an E-mail account need only have a means of establishing temporary contact with the host machine, which is the computer on which post.office is running. Thus any computer that can connect to the host machine (generally via a network such as an ethernet or the Internet but a modem will do the trick in a pinch) can be part of the E-mail system that post.office coordinates.
UNIX delivery is
available on UNIX machines. UNIX delivery adds new messages to
the user's mail drop file (Figure C.3e). The user agent then looks
to this file for any new messages. UNIX delivery can only be used
by people who have a system account on the post.office
host (in addition to the post.office mail account).
 |
Figure C.3e: UNIX Delivery: the message is appended to the user's mail drop file by the UNIX deliver program. The user retrieves the message from that file with a user agent, such as Elm or Pine.
When post.office is installed on a system running UNIX, all the existing users on that machine are automatically given post.office E-mail accounts and are initially assigned UNIX delivery.
Program delivery
allows users to have their messages delivered to a program (figure
C.3f).
 |
Figure C.3f: Program Delivery: the message is delivered to a program which is activated at the same time.
Users who receive a high volume of messages sometimes opt to have a program sort their messages as soon as they arrive. Mail sorting programs can warn users of urgent messages or place different kinds of messages in different folders. For example, messages from mailing lists can go in one folder, professional-related mail in another, and personal mail in yet a third. As with UNIX deliver, Program Delivery requires that the user also have a system account. Note: some user agents perform mail sorting via normal Mailbox or UNIX delivery and do not require the use of Program Delivery.
The three components of the local delivery channel are depicted in figure C.3g
 |
Figure C.3g: The Local Delivery Channel -- POP3, UNIX and Program delivery.
Incorporating the local delivery channel details (from figure C.3g) into figure C.3c provides a more comprehensive picture of the message transport agent as shown below in figure C.3h:
 |
Figure C.3h: The Local Delivery Channel's role detailed in the MTA.
Handlers are the brains in post.office that decide what to do with messages and supervise the transport of E-mail between modules. The account handler routes messages between the channels and modules under normal circumstances. Weird messages that the account handler cannot understand are forwarded to the error handler.
Figure C.3h above hints at the central role the account handler plays in coordinating message transport between message channels. The account handler makes its decisions based on information located in the databases maintained by post.office managers. It also shuttles messages to and from the auto-reply utility.
Like all computer programs the account handler is limited by its startling insensitivity, utter and complete lack of intuition, and implacable lack of creativity. Since humans sometimes make mistakes in addressing and sending E-mail, occasionally messages are consigned to the error handler, most often due to a faulty address.
Any time post.office receives a message it does not understand it gives it to the error handler. In some cases these messages are returned to the sender. Alternatively, post.office can be configured to hold on to these messages, until the postmaster decides what to do with them.
If the error handler receives a message post.office cannot handle, it advises the postmaster via E-mail. The postmaster will get a message explaining what happened. The postmaster will have to decide how to deal with the error. The error handler provides the postmaster with a form offering options for resolving the error. Completing and submitting the form resolves the error. Alternatively, the postmaster is simply advised that the error occurred (for information only) and no action is necessary.
Details of what types of error occur and the postmaster's role in resolving them are discussed in the operations chapters.
Keep in mind the role the MTA plays in the total post.office system. Replacing the shaded MTA box of figure C.3 with the details of figure C.3h from above shows the Big Picture of how the MTA fits into the total system in detail (see figure C.3i):
 |
Figure C.3i: The Message Transport Agent's role in the post.office system. Now you know the whole sick truth.
All configuration and operation of post.office is carried out using E-mail or Web forms. Those forms are issued and processed by two modules which handle E-mail forms and one which handles Web forms. The modules are called the configuration manager, the account manager, and the WWW Server, respectively (see figure C.4).
 |
figure C.4: The Managers' role in the scheme of things.
Every post.office module includes a configuration database. The configuration manager supervises configuration for all post.office modules via E-mail. In addition, there is also an account database (by far the largest database in the system since it includes all user account information) which the account manager oversees when using the E-mail interface to post.office. The Web Server module is the manager which handles both system configuration and account management when using the post.office WWW interface.
Every module includes a few configuration options which can be set by the postmaster using E-mail forms (see Chapter 6 for details). These forms are handled by the configuration manager.
The minimum required configuration is taken care of during installation (see chapter 3), and usually no additional configuration is necessary. In most cases post.office will do it's job "straight out of the box," and the postmaster doesn't need to worry about configuration until the next major overhaul of the network. However, if the need or desire to change module configurations options arises, the configuration manager can take care of it via simple E-mail forms.
Aside from dealing with the occasional error message, much of a postmaster's work, especially when supervising a large E-mail system, consists of maintaining the account database: adding, changing, and removing E-mail accounts. Maintaining accounts can be done via E-mail using the account form which is discussed in detail in chapter 5. The account manager processes these E-mail account forms and manages the account database.
The WWW Server is basically equivalent to the account manager and configuration manger combined. It serves an equivalent role to those two modules, but handles this job for the Web interface rather than the E-mail interface. All the account management and system configuration options available via E-mail forms are also available via Web forms thanks to the WWW Server.
The auto-reply allows you to have post.office automatically reply to messages received by an account (see figure C.5). Discussed in more detail in its own chapter (Chapter 7), this section is here to provide a general idea of how Auto-reply works.
 |
Figure C.5: The Auto-Reply Utility.
When an incoming message for a local account is processed by the account handler, it is determined if the account invokes the auto-reply feature. If so, the auto-reply module takes the auto-reply message (which is specific for that account), formats an automated outbound message in response to the one received, and passes this reply back to the post.office Message Transport Agent for delivery.
There are three auto-reply operating modes. They are:
Vacation - use this to let people know you're out of town. Anybody who sends you a message while you're gone gets a notice (which you write) that you won't be able to check your mail until whenever. Nobody gets more than one notice, regardless of how many messages they send to you, nor are replies sent to any mailing lists you're subscribed to.
Reply will send an informational E-mail message to anybody who sends mail to a particular address. For example, you can use this feature to send a virtual brochure to anyone who contacts your company at the address "sales@your.company".
Echo is the same as reply but it returns the original message along with whatever you want to say. You can use this to let people know that "so-and-so is no longer at this address, so stop mailing him stuff here, and no I don't know where he is!" -- or something more civil.
post.office includes a finger directory service (figure C.6). Finger is the most common directory service on the Internet, and provides a means to obtain some basic information about someone using their E-mail address.
 |
Figure C.6: The Directory Service.
The finger server receives inquiries directly from the network according to the finger protocol. Referring to the appropriate information in the account database, it responds directly to the query over the network. This server operates independently of the post.office Message Transport Agent, except for the fact that they refer to a common database (the account database). This, coupled with the fact that the finger service can be automated, facilitates easy management and consistency of information, and greatly reduces the workload of the administrator. Additionally, it provides the added security benefit of employing one coordinated set of services (to which access can be limited as desired) rather than a haphazard array of individual servers.
For maximum security, access to the finger service can be limited to specific domains or hosts (or eliminated completely) at the discretion of the administrator. The individual information provided on the finger server can be modified by the users, but this activity is made secure through the use of passwords and access domain restrictions for modifying individual account information.
By now you should have a pretty good understanding of the various post.office software modules and how they interact to handle mail, and finger queries, configure the system, add accounts, etc. On the next page is one final copy of the Architecture "Big Picture" (figure C.7). It shows all the major post.office modules (except the dispatcher daemon which queues the other modules to run). You can log the activities of some or all of the modules as desired (see Chapter 6 for more detail).
 |
figure C.7: The Whole post.office Tamale.
Thank you for your interest in the post.office system.