System Configuring

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

# Chapter 5. System Configuring

# 5.1. Runtime files

This section describes the configuration in short. More detailed information can be found in section FIXME! FIXME! xxxxx....

## 5.1.1. `/etc/group`

The default configuration also expects to find names of trusted users listed at `/etc/group` entry `zmailer`. Users (unames) listed there will be able to claim any addresses at the message headers, etc. (See `$MAILSHARE/cf/trusted.cf` for its usage there.)

The usual minimal set is: `root,daemon,uucp`. (Note: At some machines ``daemon'' is called ``daemons''; It must be on that group for the smtpserver to be able to work properly!)

Warning
SECURITY ITEM: Those users at `zmailer` group must not contain `nobody`! The `nobody` is used to prevent externally given inputs from being able to execute arbitary programs at the system, or from writing to arbitary files.

## 5.1.2. `/etc/services`

Add the following line to `/etc/services` in the section for host-specific services:

    mailq   174/tcp  # Mailer transport queue

Indeed this isn't quite mandatory, as the scheduler subsystem can be configured to use different ipc socket. FIXME: Reference to scheduler.conf:PARAM entries!

## 5.1.3. `/etc/mail.conf`

If you are using the default configuration setup, the `router.cf` file expects to find a `/etc/mail.conf` file containing three variable definitions:

      # Where am I?
      orgdomain=domain
      # Who am I?
      hostname=host.subdomain.$orgdomain
      # Who do I claim to be?
      mydomain=subdomain.$orgdomain

For example:

      orgdomain=toronto.edu
      hostname=relay.cs.$orgdomain
      mydomain=cs.$orgdomain

Create `/etc/mail.conf` with appropriate contents. If you are a multi-host site, determining these things can be automated according to your local policies and conventions. See the files specific to the University of Toronto (`UT*.cf`) for examples of this.

Location of this file is written in `$`MAILSHARE`/router.cf`. By editing that entry you can alter it — into `$`MAILSHARE`/mail.conf`, for example.

Caution
Note that ``hostname='' entry above is not alone sufficient for getting the system to know all of the domains it should consider as local. See below about `localnames` database.}

# 5.2. Verifying That the Router Starts

At this point, you should be able to start the router process in interactive mode. Run:

      # $MAILBIN/router -i

or

      # /usr/lib/sendmail -bt

You should see something like:

      ZMailer router (2.99.50 #4: Sun May 10 15:24:09 EEST 1998)
      you@hostname:/some/path/to/src/zmailer/router
      Copyright 1992 Rayan S. Zachariassen
      Copyright 1992-1998 Matti Aarnio

      z#

If there are errors in the configuration file, you will be told here. The ``z#'' is the interactive prompt for root. It is unlikely you can do anything useful before setting up the data files, so get out of this by hitting EOF, or type `exit`.

# 5.3. The Database Files

Now you should merge, replace, and very least check the default database and forms files against your previous setup.

Pay particular attention to the following items: FIXME! FIXME! (changed somewhen from itemized list to subsections, I think)

## 5.3.1. `$MAILBIN/zmailer` script

You may want to add a symbolic link from some directory in your path to `$`MAILBIN`/zmailer`, if you don't already have this. I put this link in `/usr/local/sbin`.

## 5.3.2. `$MAILVAR/db/aliases` file

The provided skeleton aliases file on purpose contains syntax errors, so you are reminded to change the contents.

Choose one of the following methods to rebuild the database:

      # $MAILBIN/newaliases
      # $MAILBIN/zmailer newaliases
      # /usr/lib/sendmail -bi
      # /usr/bin/newaliases
      # $MAILBIN/zmailer newdb

If there are errors, correct them in the ```aliases`'' file, and repeat the command until the alias database has been initialized. The final message should look something like:

     319 aliases, longest 209 bytes, 16695 bytes total

exact numbers vary, of course...

See also IETF's RFC 2142: ``Mailbox Names for Common Services, Roles and Functions'' (file `doc/rfc/rfc2142.txt`) for other suggested aliases you may need.

## 5.3.3. `$MAILVAR/db/localnames` file

Add the hostnames you want ZMailer to do local delivery for, to the `$`MAILVAR`/db/localnames` file. Due to my own belief in Murphy, I usually add partially qualified domain names and nicknames in addition to canonicalized names. If you want to do local delivery for mail clients, put their names in here too. You may use pathalias style ``.domain'' names in this file, to indicate everything under some subdomain.

With the sample config files for Zmailer-2.98, and latter, this `localnames` is actually a mapping of those various names to the desired forms of the canonic name, thus an example as seen in figure Figure 5-1.

Figure 5-1. Sample of ```localnames`'' file

    #
    # Left:  input name
    # Right: what is wanted to be shown out
    #
    # List here all names for the system
    #
    astro.utu.fi         astro.utu.fi
    oj287                astro.utu.fi
    oj287.astro.utu.fi   oj287.astro.utu.fi
    oj287.utu.fi         astro.utu.fi
    sirius               sirius.utu.fi
    sirius.astro.utu.fi  sirius.utu.fi
    sirius.utu.fi        sirius.utu.fi

In certain cases the router is able to deduce some of the names, however smtpserver anti-relay policy compiler will not be able to do so, and needs this data!

THUS: All names that the host may ever have are best listed in here! It reminds you of them, and makes sure a message destined into the host really is accepted.

Compile this into runtime binary database with command:

      # zmailer newdb

(fall-back method is sequential rescan of the text file)

## 5.3.4. `$`MAILVAR`/db/routes` file

Add any UUCP neighbours or other special cases to this file. For an example see Figure 5-2.

You can compile the file into binary database with command:

      # zmailer newdb

Figure 5-2. Sample of ```routes`'' file

      #
      # ``routes'' mapping file
      #
      .toronto.ca      error!err.wrongname
      .toronto.cdn     error!err.wrongname
      alberta          uucp!alberta
      atina            smtp![140.191.2.2]
      calgary          smtp!cs-sun-fsa.cpsc.ucalgary.ca
      icnucevm.bitnet  smtp!icnucevm.cnuce.cnr.it

## 5.3.5. `$`MAILVAR`/db/fqdnaliases` file

The `fqdnaliases` database is for mapping fully-qualified user addresses to others — for example you machine has a set of domain-names for it to consider local, but you want to have separate people to be postmasters for each of them as shown at Figure 5-3.

Figure 5-3. Sample of ```fqdnaliases`'' file

      postmaster@domain1: person1
      postmaster@domain2: person2
      postmaster@domain3: person3, person4

It is also possible to shunt all recipient addresses for given domain to some arbitary addresses as shown at Figure 5-4.

Figure 5-4. Second sample of ```fqdnaliases`'' file

      @domain4:  person4

This facility is always in stand-by — just add the file, and you have it at the next router startup.

You may even handle just a few users for each of those domains, and then have the ```routes`'' entry (see above at Figure 5-2) to declare something suitable:

      .domain1  error!nosuchuser

which combined with the ```fqdnalias`'' method will let ```postmaster@domain1`'' to exist, and report error on all others.

Choose one of the following methods to rebuild the database:

      # $MAILBIN/newfqdnaliases

or either of:

      # $MAILBIN/zmailer newfqdnaliases
      # $MAILBIN/zmailer newdb

If there are errors, correct them in the ```fqdnaliases`'' file, and repeat the command until the alias database has been initialized. The final message looks similar to that of the ordinary aliases case.

## 5.3.6. UUCP Node Names

If your hostname and UUCP node name are not identical, put your UUCP node name in the file `/etc/name.uucp` (or `/etc/uucpname`).

# 5.4. Checking the Routing

At this point, you should be able to start the router again in interactive mode, and ask it to route addresses. Try:

      # /usr/lib/sendmail -bt

at the prompt:

      z# router you

should print out:

      (((local you you default_attributes)))

Keep playing around with various addresses until you get a feel for it. Modify the configuration file if your setup requires it.

To give more feeling of what goes on during the ``route''-command, you can give command ``rtrace'' before trying to use ``route.''

# 5.5. Checking the Scheduler

The location of the `scheduler.conf` on running system is `$`MAILSHARE`/scheduler.conf`

For normal operations of the system the current sample of ```scheduler.conf`'' file is quite sufficient, but in case you want to do something unusual, like using procmail for local delivery, do read on.

In Figure 5-5 there are some salient points about tuning the ```local`'' channel behaviour.

Figure 5-5. Sample of ```scheduler.conf`'' passage for ```local/*`'' selector

      local/*
        interval=5m
        idlemax=9m
        expiry=3d
        # want 20 channel slots, but only one HOST
        maxchannel=15
        maxring=5
        # Do MIME text/plain; Quoted-Printable -> text/plain; 8BIT
        # conversion on flight!
        command="mailbox -8"
        # Or with PROCMAIL as the local delivery agent:
        #command="sm -8c $channel procm"
        # Or with CYRUS server the following might do:
        #command="sm -8c $channel cyrus"

There are three variants of the ``command='' entry:

command="mailbox -8"

  The normal ZMailer mailbox(8) channel program.

command="sm -8c $channel procm"

  Variant for running procmail.

command="sm -8c $channel cyrus"

  Variant for using CMU Cyrus message store server.

For more information regarding scheduler configuration language, see Section 22.1.

## 5.5.1. Checking `sm.conf` file

For some uses the scheduler runs sm(8) program — called ``sendmail-like mailer''.

This supports most of sendmail's `M`-entry flags, at least flags with versions previous to 8.x

The ZMailer sm(8) channel program is used to create support for things like:

- uucp transmits

- procmail as local delivery agent

- supporting CMU Cyrus message store as local delivery agent

For more information, see Section 23.4.1.

## 5.5.2. The ```smtpserver.conf`'', and smtp-policy databases

These take care of such a things as preventing relay-hijack type of abuse of your system.

Basically you want to install the boilerplates and the tool scripts, edit them a bit, and run policy-builder.sh script. For further details on this, see chapter Section 12.2.

In smtpserver front you may need to lower the strict standards of the basic RFC-821 SMTP protocol and allow acceptance of non-qualified addresses — ones without any sort of domain name in them.

Another thing to allow is (sigh) MS-Windows-CE 1.0/2.0 gadgets with their totally broken SMTP sending system.

Both of these things are handled by ``EHLO-style options'' described at chapter Section 12.1.2.

# 5.6. Bootup Scripts

Add something like the following lines to bootup scripts (`/etc/rc.local` or `/etc/rc2.d/S99local` or similar):

      if [ -r /etc/zmailer.conf ]; then
        . /etc/zmailer.conf
        if [ ${MAILSERVER-NONE} = NONE -a
             -x $MAILBIN/zmailer ]; then
          $MAILBIN/zmailer bootclean
          $MAILBIN/zmailer && (echo -n ' zmailer') >/dev/console
        fi
      fi

For SysV-init environments, see source-tree file: `utils/zmailer.init.sh`. You may want to comment out startup of the Sendmail daemon, if you have it to begin with.

# 5.7. Checking the Log Files

Start ZMailer:

     $MAILBIN/zmailer

Keep an eye on the log files (`$`LOGDIR`/router`, `$`LOGDIR`/scheduler`), the `$`POSTOFFICE`/postman/` directory for malformed message files, and `$`POSTOFFICE`/deferred/` in case of resource problems.

# 5.8. Crontab

Figure 5-6. ZMailer related crontab entries for root user

      # Two ZMailer related root's CRONTAB entries:
      28 0,8,16 * * * . /etc/zmailer.conf ; $MAILBIN/zmailer resubmit
      7  4      * * * . /etc/zmailer.conf ; $MAILBIN/zmailer cleanup
    FIXME!FIXME!
      # This third one will not per default be installed into your system
      0  0      * * * . /etc/zmailer.conf ; $MAILBIN/rotate-logs.sh

See figure Figure 5-6 for two crontab entires for the root to run. There are three entries:

1. This will ``resubmit'' messages that have been deferred with no useful processing possible at time of deferral. Adjust the resubmission interval to suit your environment. Having files in ``deferred'' state is a sign of troubles! Always investigate!

2. This ``cleanup'' is to regularly clean out the ```$`POSTOFFICE`/public/`'', and ```$`POSTOFFICE`/postman/`'' directories.

3. The automatic logfile trimmer/rotater is a good idea to have, but you need to customize it for your environment. More of that below.

You may want to hardwire the location of the zmailer script.

# 5.9. Customizing ZMailer Messages

Edit several of the canned error messages and programs (scripts) to reflect your local configuration: `$`MAILSHARE`/forms/` files and `$`MAILBIN`/ta/usenet` (injected message).

Normally the boilerplate messages looks something like these:

    HDR From:    The Post Office <postmaster>
    HDR Sender:  mailer-daemon
    SUB Subject: Errors: No such user(s)
    ADR Bcc:     <postmaster>

    This is a collection of reports about email delivery
    process concerning a message you originated:

In these, ``ADR'' lines define header lines which are to be analyzed for recipient addresses, while ``HDR'' lines can carry anything which doesn't get output as envelope address. The ``ADR'' line contained addresses must be in brackets, and there can be only one address per such header. If there are more, only the first one is picked.

FIXME: FIXME: XREF to Scheduler

# 5.10. Alias expansion

Read the notes on alias expansion in the file `doc/guides/aliases` and on mailing list maintenance in Section 13.2.2, Mailing Lists and `~/.forward`.

# 5.11. Trimdown of Logging

Once satisfied that things appear to work, you may want to trim down logging: there are four kinds of logging to deal with:

- Router logs:

  FIXME! FIXME! Usually kept in `$`LOGDIR`/router`. his is the stdout and stderr output of the router daemon. If you wish to turn it off, see `$`MAILSHARE`/cf/standard.cf` for routine dribble()}, and especially its invocations!

- Scheduler logs:

  Usually kept in `$`LOGDIR`/scheduler`. Same as router.

- General Mail Logs:

  Usually kept in syslog files, depending on how you have configured the syslog utility (`/etc/syslog.conf`). All ZMailer programs log using the `LOG_MAIL` facility code for normal messages. You can deal with this specifically in your syslog configuration file on systems with a 4.3bsd-based syslog. The following reflects the recommended configuration on SunOS 4.0:

        mail.crit   /var/log/syslog
        mail.debug  /var/log/mail/mail.syslog

  For pre-4.3bsd-based syslogs, you may want the syslog log file to be just for important messages (e.g. LOG_NOTICE and higher priority), and have a separate file for informational messages (LOG_DEBUG and up).

- By default, the postmaster will not receive a copy of all bounced mail; this can be turned on selectively by simply editing the various canned forms used to create the error messages. These forms are located in the `FORMSDIR` (`proto/forms` in the distribution, or `$`MAILSHARE`/forms` when installed). You should review these in any case to make sure the text is appropriate for your site.

Prev | Home | Next
Build and Install | Up | Installation to Clients