- A list of features
- An overview of post.office architecture
| This
chapter is an overview of post.office. It includes:
|
E-MAIL WITH POST.OFFICE |
Chapter 2 consists of first, an overview of the salient features
of post.office followed by a quick overview
of the post.office software architecture.
The information presented here is not absolutely required
for the installation and operation of post.office. Rather,
it is here for those who prefer to get started by getting an overall
view of the post.office system, as opposed to a more
hands on, trial and error approach.
If your goal is to get post.office set up as fast as you can and you don't really give a hoot about the finer details, you may want to skip ahead to chapter 3, Installation.
NOTE: The 
and 
symbols indicate
additional features that are available on UNIX platforms or Windows
NT platforms, respectively.
As you read through the post.office features you will discover that it does a lot more than just trade messages with user agents and other message transport agents(or MTAs). Although post.office is first and foremost a message transport agent, features such as the auto-reply utility do a lot to enhance your E-mail system.
post.office mail accounts are more versatile and easier to use than what you're likely to find with other message transport agents. While E-mail is complicated, on the whole, post.office is not.
The design of post.office places an extreme emphasis on security, an issue which has not historically been adequately addressed by other MTAs13. As always, maintaining a secure system requires that you be aware of security issues. This manual includes a chapter dedicated to outlining security issues for you (read it!), as well as periodic discussions of security issues relevant to the topics covered in the various chapters. post.office provides you with powerful tools to empower you to protect your mail system and the rest of your computer from unscrupulous folk.
Open standards conformance allows greater flexibility than closed proprietary systems. You will be able to exchange E-mail with millions of users around the world.
The remote configuration of post.office (configuration by E-mail or web) is unique, and is independent of the host operating system, so that you can operate post.office on the platform you like from the computer you want to use.
Features such as the auto-reply utility and the finger query server which are not usually included with MTAs make E-mail more useful than ever.
Every mail recipient has a post.office account. Account information determines:
UNIX delivery
places messages directly into user's maildrop file in their UNIX
account, and is limited to users on the host where post.office
is installed.
Program delivery
delivers messages to a program at the same time as it activates
the program. This option is popular with users who receive a large
volume of mail and like to have a program sort through them.
Mail accounts contain the bulk of post.office configuration information. Accordingly, the postmaster's bread and butter work is to create and maintain mail accounts. Users have the option of changing certain aspects of their accounts, such as directory information and how they collect their mail. Users do not need to have a login account for the host computer in order to have an E-mail account (which saves you a lot of hassle while also enhancing system security).
Security has been a major consideration throughout the design of post.office. There are four basic security mechanisms:
For more detailed information, see Chapter 8 on Security.
post.office can support specific "open standards" protocols and is also designed to accommodate mail transfer between non-compatible protocols. post.office incorporates the Simple Mail Transfer Protocol (SMTP), which allows message transfer around the world via the Internet.
Additional message channel modules will allow messaging using non-SMTP networks as well as switching messages between these networks and SMTP (for more information on Protocols see section 1.5 or the manual which accompanies your additional channel).
You can also use post.office to route non-SMTP messages to a gateway (i.e. to route UUCP messages to a UUCP gateway -- see the discussion of the SMTP channel form for details).
All interaction with post.office is carried out using E-mail or World Wide Web (WWW) forms: you request a fill-in-the-blank form, fill it out, and send it in to make changes to an account or the system configuration. There is no complicated syntax. You don't need to learn any programming languages to install or operate the system. You don't even need to do your configuration and management from the host where post.office is installed. Remote configuration and management are discussed in detail in chapters 4, 5 and 6.
All forms include instructions on how to fill them out, so you are often able to complete them without even referring to the manual.
post.office allows users to make certain changes to their E-mail accounts using special forms of limited scope. While unable to make changes which would jeopardize the mail system, they do not have to disturb the postmaster to make changes which affect only their account, such as how messages are delivered and what the password is.
Since post.office is designed to be a wide-area network messaging system, you aren't tied to a single local network. When your organization expands, so does post.office.
In fact, post.office is Internet-ready so your messages can travel easily around the planet. If you are already on the Internet, post.office will easily handle mail for any number of Internet domains on the same machine.
From the perspective of the postmaster, operating post.office on a Sun computer running the Solaris 2 version of UNIX is no different than operating post.office on a Windows NT machine. Since configuration is handled via universal E-mail forms, system administrators are free to work from their favorite platform. You can commit to post.office without committing to any specific operating system or brand of computer.
Auto-reply allows you to have post.office automatically reply to messages sent to a given address. The three operating modes, which are discussed in more detail in chapter 7, are:
The finger server allows people to find limited information about one another if they know each other's E-mail address. Usually finger servers are not incorporated with message transport agents; rather, they are a program that users and administrators can install if they have the time and inclination.
With post.office, the finger information is configured every time an E-mail account is created to answer finger queries addressed to that account. Users can modify their finger information without assistance from the system administrator. The principle advantage of having post.office answer finger queries is that it makes at least a little bit of directory information available for every user who has an E-mail account with post.office.
sendmail Emulation In addition to fully supporting SMTP, post.office supports features offered by the sendmail program (on UNIX platforms) which has achieved widespread use among UNIX users. In most cases post.office acts as a drop-in replacement for sendmail (although there are differences). System administrators who have customized sendmail extensively should refer to the sendmail appendix to ensure a smooth transition to post.office.
post.office functions are distributed among a number of software modules which work together to carry out message handling and other activities. This design makes it easy to add additional modules if you need new features and to easily re-configure a specific module when the need arises. New modules are added without re-configuring post.office or disrupting operations.
This section gives you a bird's eye view of this architecture. If this is the kind of thing you really dig, you can wallow in the nitty-gritty of the software organization in the appendix which is exclusively devoted to post.office system software architecture.
If you just want to know how the stuff works, and don't care much why, this is probably not your thing, and you may want to skip forwards to installation and operations.
Figure 2.2 below shows post.office broken down into five functional chunks: an MTA, some managers, utilities, directory services and configuration databases. These are all discussed in turn, along with the omnipotent dispatcher which tells them when to run.
|
Figure 2.2: An illustration of the five components of post.office which run under the control of the dispatcher. The message transport agent exchanges messages with user agents and other MTAs. The Directory Service answers finger queries initiated by user agents.
All modules are coordinated by the post.office dispatcher (on Windows NT this is a service and on UNIX platforms, a daemon) component of post.office. The dispatcher monitors all network ports related to E-mail and starts up 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.
The message transport agent or MTA (as described in chapter 1) performs two functions: it exchanges messages with other MTAs, and accepts messages from and delivers messages to user agents. It is the foundation of post.office.
When the postmaster submits forms to post.office, these are accepted by the MTA and delivered to the post.office managers for processing.
Similarly, certain messages are forwarded to the auto-reply utility.
post.office managers are the modules that process the forms you send in. They carry out instructions and maintain the databases that the rest of the modules rely on to carry out their tasks.
Together with the WWW and E-mail forms described in more detail in chapters 5 and 6, post.office managers are the interface between the postmaster and the E-mail system.
Technically there are three managers: a WWW-server, which handles all of the web forms, and two managers which handle E-mail forms: the account manager and the configuration manger.
Every post.office module has a database which contains all the configuration information for that module. For most modules, this database is fairly small, containing a few configuration options and a list of error messages.
The account database 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. By keeping all user information in one place, a single configuration change updates all modules at once.
post.office utilities include the auto-reply module. The auto-reply feature enables post.office to automatically reply to incoming messages with pre-defined responses of your choice. Chapter 7 gives you the whole scoop.
The finger server answers finger queries, a widely used feature which allows users to find out information about someone whose address they know. For example, if you query "Jane.Doe@Software.com", you'll get her phone number and address (illustrated in figure 1,7.1).
The brief descriptions given above should provide most people with a more comprehensive outline of the post.office design than they will ever need in order to operate the system. However, if you're one of those people who needs or wants to know the polarity of the coil, the size of the plug gap and the required torque on the bell housing before driving the car, further details are available in the appendix which is devoted solely and exhaustively to post.office architecture.