If you use the BIND nameserver, you should be using (or install) a recent version, at least BIND 4.8.
At this package there is also bundled resolver from bind-4.9.4, however it is a bit difficult at BSD systems ('cause those developers use BSD themselves, and make an assumption that everybody has their version of things... On the other hand, those systems have reasonably modern resolvers, so no need to worry about it -- I hope.)
We use GNU-autoconfig mechanism, however you still may need to touch on some files after that system has run thru:
$ ./configure --prefix=/opt/mail \ --with-postoffice=/var/spool/postoffice \ --with-mailbox=/var/mail \ --with-logdir=/var/log/mail
See if SiteConfig-file makes sense now, if not, you can tune most of the values with various "--with-*="-keywords. Get a list of those keywords by executing command:
$ ./configure --help
Those keywords that you can't tune, you can edit at the SiteConfig.in-file. (Redo the configure with new parameters, if it looks to be necessary.)
Additional examples:
CFLAGS="-O -g3 -std1" CC="cc -migrate" ./configure \ --prefix=/l/mail --with-bundled-libresolv \ --with-system-malloc
CC="cc -O" ./configure --prefix=/opt/mail \ --with-bundled-libresolv
./configure --prefix=/opt/mail --with-bundled-libresolv \ --with-gcc
./configure --prefix=/l/mail
$ makeor perhaps:
$ make clean allwhich at first cleans everything, and then makes -- great if you changed some configuration parameters.
This should compile everything, and leave a zmailer.Config file in the toplevel directory. Nothing outside the source area will be touched at this point.
(If your system ``make'' lets your shell ``SHELL''-environment affect its own execution environment, it may be that non sh/ksh/zsh users detect weird phenomena, and failures.. Beware!)
# zmailer killand save the state of your system. This includes any active contents of the postoffice, as well as database files and anything else in the installation areas you want to be sure to keep. This is just paranoia, the installation should not overwrite precious files, and will save old versions of distribution files in "bak" subdirectories.
The interface in between the commonly used sendmail, and ZMailer is a "compability program", which is to replace the /usr/lib/sendmail (aka /usr/sbin/sendmail on some systems). The system attempts to automate the replacement, but it MAY present a cry for help, if your system does not have functioning symlinks. Also if ``test -h $(SENDMAILPATH)'' does fault in mysterious ways, the reason may be that your system does not have symlinks...
If you are currently running Sendmail, kill your SMTP server and drain the Sendmail queue. There is no automatic method to requeue Sendmail messages under ZMailer. If you later want to back out to Sendmail, all you need to do is move the former version of the sendmail (on /usr/lib/sendmail.bak, for example) binary back to /usr/lib/sendmail. (You may also need to do some magics with system startup scripts in case you are running SysV-style init.. BSD /etc/rc.local does need its own gymnastics too..)
A sort of method to quickly handle your sendmail queue is to start ZMailer's smtp server, reconfigure the old sendmail to use a smarthost, which happens to be at the same machine.
The idea is to get the sendmail to send its queue via SMTP to the ZMailer.
# make install(this installs all binaries and the default database files, which still need editing! See below.) or if you just want to have the new BINARIES without touching at your configurations:
# make install-binAll programs are stored into $MAILBIN/, and $MAILBIN/ta/, and possible older binaries are saved into "bak" subdirectories.
This step should be non-destructive (anything replaced will be saved in a 'bak' directory, and for some customizable files, if they exist new versions won't replace them).
If this is not a from-scratch installation, be aware that the install procedure will NOT replace some of the files in $MAILSHARE with the equivalents from the distribution. Specifically, the $MAILSHARE/cf/*, $MAILVAR/db/aliases, $MAILVAR/db/routes, and $MAILVAR/db/localnames files are never replaced if they already exist. The $MAILSHARE/forms/* files are always replaced, but the old files will be saved in a 'bak' directory.
Go into the man directory, and install the manual pages by hand:
# cd man ; make installor in case the default guessing didn't get it right:
cd man ; make install MANDIR=/our/manpages
# Where am I? orgdomain=domain # Who am I? hostname=host.subdomain.$orgdomain # Who do I claim to be? mydomain=subdomain.$orgdomainFor example:
orgdomain=toronto.edu hostname=relay.cs.$orgdomain mydomain=cs.$orgdomainCreate /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, at which you can alter it.. to be $MAILSHARE/mail.conf; for example.
root,uucp,daemon
At this point, you should be able to start the router process in interactive mode. Run:
# $MAILBIN/router -ior
# /usr/lib/sendmail -btYou should see something like:
ZMailer router (2.99.37 #1: Sat Aug 10 14:09:22 EET DST 1996) you@hostname:/some/path/to/src/zmailer/router Copyright 1992 Rayan S. Zachariassen Copyright 1992-1996 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'.
Pay particular attention to the following items:
You may also want to add a symbolic link from some directory in your path to $MAILBIN/zmailer, if you don't already have this. We put this link in /local/etc/.
The aliases database is rebuilt using the $MAILBIN/newaliases script. This can be invoked in several ways: directly as a command if you have /usr/ucb/newaliases symlinked properly, or by command "zmailer newaliases", or "sendmail -bi" if the ZMailer sendmail replacement is installed.
Choose one of the following methods to rebuild the database:
# $MAILBIN/newaliases # $MAILBIN/zmailer newaliases # /usr/lib/sendmail -bi # ln -s /usr/lib/sendmail /usr/ucb/newaliases ; /usr/ucb/newaliasesIf there are errors, correct them in the $MAILVAR/db/aliases file and repeat the command until the alias database has been initialized.
319 aliases, longest 209 bytes, 16695 bytes total
See also IETF's Best Current Practices (BCP) documents about the ``Standard Electronic Mail Addresses For Internet Operations''. At the time of this writing (June-96) it is in draft version, which is copied into doc/drafts/-directory:
draft-vixie-ops-stdaddr-01.txt
With the sample config files for mea's 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:
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.fiREMEMBER: 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.
.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
If you are on BITNET, put your BITNET node name in /etc/name.bitnet (or /usr/lib/urep/BITNETNAME). (And if you really need BITNET stuff, have a look at: ftp://ftp.funet.fi/pub/unix/networking/bitnet/; another ''hack'' from Matti Aarnio :-) )
# /usr/lib/sendmail -btat the prompt:
z# router youshould 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.
mailq 174/tcp # Mailer transport queue
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 ) fiFor SysV-init environments, see: utils/zmailer.init.sh
You may want to comment out startup of the Sendmail daemon. (Or replace it with the zmailer startup..)
# $MAILBIN/zmailer
28 0,8,16 * * * . /etc/zmailer.conf ; $MAILBIN/zmailer resubmitThis will resubmit messages that have been deferred with no useful processing possible at time of deferral. Adjust the resubmission interval to suit your environment.
You may also want to regularly clean out the $POSTOFFICE/public/, and $POSTOFFICE/postman/ directories:
7 4 * * * . /etc/zmailer.conf ; $MAILBIN/zmailer cleanupYou may want to hardwire the location of the zmailer script.
mail.crit /var/log/syslog mail.debug /var/log/mail/mail.debugLOG_NOTICE and higher priority), and have a separate file for informational messages (LOG_DEBUG and up).
If you for some obscure reason are mounting MAILBOXes and/or POSTOFFICE hierarchies via NFS, do it with options to disable various attribute caches:
actimeo=0 alias: noacThe best advice is to NOT to mount anything over NFS, but some people can't be persuaded...
Lots of things are done where file attributes play important role, and they are extremely important to be in sync! (Sure, the 'noac' slows down the system, but avoids errors caused by bad caches..)
If you are mounting people's home directories ( .forward et.al. ) via NFS, consider the same rule!
If the mail-folder directory is shared too, it is some of following (usually):
/usr/mail /usr/spool/mail /var/mail /var/spool/mail