This section describes the configuration in short. More detailed information can be found in section FIXME! FIXME! xxxxx....
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. |
Add the following line to /etc/services in the section for host-specific services:
mailq 174/tcp # Mailer transport queue |
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.} |
At this point, you should be able to start the router process in interactive mode. Run:
# $MAILBIN/router -i |
# /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.
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)
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.
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 |
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.
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 |
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 |
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.
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 |
Choose one of the following methods to rebuild the database:
# $MAILBIN/newfqdnaliases |
# $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.
If your hostname and UUCP node name are not identical, put your UUCP node name in the file /etc/name.uucp (or /etc/uucpname).
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 |
z# router you |
(((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.''
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:
The normal ZMailer mailbox(8) channel program.
Variant for running procmail.
Variant for using CMU Cyrus message store server.
For more information regarding scheduler configuration language, see Section 22.1.
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.
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.
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.
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.
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:
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!
This ``cleanup'' is to regularly clean out the ``$POSTOFFICE/public/'', and ``$POSTOFFICE/postman/'' directories.
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.
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: |
FIXME: FIXME: XREF to Scheduler
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.
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.