and
symbols indicate additional features that are available on UNIX platforms or Windows NT platforms, respectively.
• A list of Post.Office features
• An overview of Post.Office system architecture.
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 MTAs. 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 that enable 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 ability to configure Post.Office remotely (by E-mail message or web form) is unique and is independent of the host operating system, so 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:
• The recipient's addresses (as many variations as desired). Post.Office is extremely flexible regarding addresses allowing any of several standard methods, such as First-Name.Last-Name@address. (Of course you're still free to use meaningless strings of numbers and letters if you choose).
• Security features used to protect messages (discussed below).
• Delivery information: how recipients collects their messages. Standard delivery options are POP3 and UNIX delivery (for users) as well as program delivery (which delivers messages to other programs).
• POP3 delivery allows users to make remote mail pick-up from any computer. Post.Office will hold onto incoming messages until a user checks her mail. After she correctly enters her password, Post.Office will send her mail.
• Directory information provided in response to finger queries.
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:
• Limited Permissions: Permission for Post.Office to run as root or administrator (super-user) is strictly limited to start-up. Once Post.Office is running, the program has no root or administrator privileges.
• Passwords: Any configuration change requires that the Postmaster supply a password. Users have their own passwords to retrieve their mail as well as to make changes to their accounts.
• General Access Restrictions: Post.Office operations can be limited to specific locations so that configuration changes and mail retrieval can be made only from a specific host or from within broader boundaries (i.e. within a partially specified DNS address which does not include a host) set by the administrator.
• Warnings: Post.Office warns the system administrator in the event that it detects attempts made to break into the E-mail system and documents any such attempts.
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 Chapter 1, 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 via 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:
• Vacation - use this to let people know you're out of town. Anybody who sends you a message while you're gone gets a reminder (which you write) that you won't be able to check your mail until you get back. Nobody gets more than one notice, regardless of how many messages they send to you.
• 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, we don't know where he is!" -- or something more civil.
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.
In addition to fully supporting SMTP, Post.Office supports features offered by the sendmail program 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. This functionality is duplicated on NT with the postmail feature.
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 the Post.Office 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 forward to installation and operations.
Figure 2-1that follows 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-1 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 (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 Manager.
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 Accounts
Post.Office accounts are opened, modified, and closed by the Postmaster using WWW or E-mail forms (discussed in Chapters 4, 5 and 6). Users also have the option of making limited changes to their accounts via the Web or E-mail. Post.Office uses the information on the account forms to enter, modify, or delete entries in the account database.
Once Post.Office is up and running, maintaining user accounts is one of the Postmaster's chief tasks, as she must add, change, or remove accounts whenever new people want
E-mail, change their computer set-up, or stop getting their E-mail at the Post.Office host in question. Chapter 5 describes the specific information kept in the account database as well as how and why to use it.
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.10).
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.
