ZMailer's Features, and Facilities

ZMailer: The Manual; v1.99.20
Prev |  | Next

# Chapter 2. ZMailer's Features, and Facilities

# 2.1. Introduction

ZMailer is a mailer subsystem for the UNIX operating system. It is in charge of handling all mail messages that are created on a system, from their creation until final disposition locally or by transfer to another system.

As such, the mailer subsystem (the Message Transfer Agent) must interface to local mail reading and composing programs (User Agents), to the various transport methods that can be used to reach other mailers, and to a variety of databases describing the mailer's environment.

ZMailer provides this functionality in a package and with a philosophy that has benefited from experiences with earlier mailers.

ZMailer provides a capable, robust, efficient subsystem to do the job, which will excel in demanding environments, but is simple enough to fit easily everywhere.

## 2.1.1. Design Summary

Figure 2-1. ZMailer's processes.

ZMailer is a multi-process mailer, using two daemon processes to manipulate messages. One of these processes is a router, and makes all decisions about what should happen to a message. The other daemon is a message queue manager, used to schedule delivery of messages. The Router uses a configuration file that closely follows Bourne shell script syntax and semantics, with minimal magic. Message files are moved around in a series of directories, and the Scheduler and its Transport Agents run off of control files created by the Router.

The Router will process messages one at a time, as it finds them in a directory where User Agents submit their outgoing messages. Envelope and Message Header information is all kept in the same message file along with the message body, and this file is never modified by any ZMailer program. After parsing the envelope and RFC822 header information, the Router validates the information extracted, and calls functions defined in the configuration file to decide exactly how to deliver the message and how to transform the embedded addresses. The algorithms that do this are easily reconfigurable, since the control flow and address manipulation is specified by familiar shell script statements. When the Router is finished, it will produce a message control file for use by the delivery processing stage of ZMailer, and move the original message file to another location.

Once the Router has decided what to do with each of the addresses in a message, the Scheduler builds a summary of this information by reading the control file created by the Router. This knowledge is merged with a data structure it maintains that stores which messages are supposed to be sent where, and how. According to a pre-arranged agenda, the Scheduler will execute delivery programs to properly move the message envelope, header, and body, to the immediate destination. These delivery programs are called Transport Agents, and communicate with the Scheduler using a simple protocol that tells them which messages to process and returns status reports to the Scheduler. The Scheduler also manages status reports, taking appropriate action on delivery errors and when all delivery instructions for a message have been processed.

There are several standard Transport Agents included with the ZMailer distribution. The collection currently includes a local delivery program, an SMTP client implementation, and a Transport Agent that can run Sendmail-compatible delivery programs.

A separate utility allows querying the Scheduler for the state of its mail queues. For existing Sendmail installations, a replacement program is included that simulates most of the Sendmail functionality in the ZMailer environment. This allows ZMailer to replace a Sendmail installation without requiring changes in standard User Agents.

Figure 2-2. Directories that ZMailer uses for message processing.

# 2.2. Running ZMailer

ZMailer is fairly simple to run, once the setups are completed it can be left to run on its own with very little supervision.

Things that might need supervision are things like:

- Timely cycling of log files, which otherwise will grow until they fill all of the available disk space (One need not log everything possible, about the only thing this system does not allow you to log is the message body content.)

- Keeping watchful eye on `$`POSTOFFICE`/freezer/`, and `$`POSTOFFICE`/postman/` directories. Former for processing SPAM email, latter for pathological problem cases. (FIXME:: More at 3.3.4)

We look closer into these issues at latter parts of this document, but now it is sufficient to tell, that the principal tool for active monitoring of the system health is command:

    $ mailq -ss

which does tell, if router, or scheduler are up and about, or not, and also does tell about the sizes of the different sub-spools.

The general management interface for starting and stopping different subsystems is command

    # zmailer

which the system installs into `$`MAILBIN`/` directory, and which command usually needs a symlink to itself from some more common location for administrative convenience ( `/usr/sbin/zmailer` -> `$`MAILBIN`/zmailer` ) so that the administrator does not need to add `$`MAILBIN`/` directory into his or her `PATH`. On overall, it is intention that not even admin user should need to run directly the programs located at the `$`MAILBIN`/` directory.

Basically the administration is as follows:

- At system startup (to start all subsystems):

      # zmailer

- At system shutdown (to kill all subsystems):

      # zmailer kill

There is also a way to make sure the system will not let the ZMailer to start at the system startup, because you have some massive work going on, and the system is not in condition to accept email for a while:

    # zmailer freeze

and the antidote for the ``freeze'' is, naturally:

    # zmailer thaw

Normal operations can not be started at ``frozen'' system without ``thawing'' it at first.

The user-visible component of the ZMailer is (for de-facto interface)

    $ /usr/lib/sendmail

(a.k.a. `/usr/sbin/sendmail`) which is ``simple'' message submission program that mimics sendmail commands behaviour, but of course many details of sendmail are not really implemented at all, mostly because they do not have equivalents in the ZMailer system.

There are also functional equivalents (or near equivalents) of other sendmail/system utilities: mailq, newaliases, and vacation.

Prev | Home | Next
Introduction to Email | Up | Comparison With Other Popular MTA's