<!-- \segment{zinstall}{chapter}{Build and Install}			-->
<!-- %begin{latexonly}							-->
<!-- \cleardoublepage							-->
<!-- %end{latexonly}							-->
<!-- 									-->

<PART ID="ZINSTALL"><?dbhtml filename="zinstall.html">
<TITLE>Build and Install</TITLE>

<PARTINTRO>
<PARA>
This section describes how to build and install ZMailer.
</PARA>

<TIP><PARA>Consider joining the ZMailer user-community email list.
It is the place to meet the Gurus, in case you have problems.
See the ``<FILENAME>Overview</>'' file in the source distribution
for more information.</PARA></TIP>

</PARTINTRO>

<CHAPTER><?dbhtml filename="zins-buildinstall.html">
<TITLE>Build and Install</TITLE>
<SECT1 ID="build.environment"><TITLE>Environment Issues</>

<PARA>
The cornerstone of everything in busy Internet email routing
is a well-working DNS server, and modern resolver library.
If you use the BIND nameserver, you should be using (or install)
a recent version, at least BIND 4.8. In this package there is also 
a bundled resolver from  bind-4.9.4, however it is a bit difficult
at BSD systems (because those developers use BSD themselves, and
make an assumption that verybody has their version of things&hellip;

On the other hand, those systems have reasonably modern resolvers,
so no need to worry about it &mdash; I hope.) 
</PARA>

<PARA>
For performance reasons you should have <EMPHASIS>local</> instance of
nameserver. <EMPHASIS>Even when you don't have any DNS zone data to
originate yourself, an instance of nameserver is able to cache
replies it receives from the network, and thus be able to faster
yield replies for repeated questions.</EMPHASIS>
</PARA>

<PARA>
You may also choose to use ``<APPLICATION>whoson</>'' services provided by
a utility package at ``<FILENAME CLASS="DIRECTORY">contrib/</>'' subdirectory.
If you do, then do install that before configuring and installing the ZMailer.
</PARA>
</SECT1>

<SECT1 ID="build.autoconfiguration"><TITLE>Autoconfiguration</TITLE>

<PARA>
<!-- <INDEXTERM><primary>build</><secondary>disk partitions</></> -->

This system uses several preferably separate partitions for
different things:

<ITEMIZEDLIST>
<LISTITEM><PARA>Software binaries, and databases:
  <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILVAR</>/</> (node local db's),
  <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILSHARE</>/</> (site shared),
  <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILBIN</>/</> (read-only, site shared)
</PARA></LISTITEM>
<LISTITEM><PARA>The mailbox spool:
  <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILBOX</>/</>
  (<FILENAME CLASS="DIRECTORY">/var/mail</>)</></>
<LISTITEM><PARA>The postoffice spool:
  <FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</>/</>
  (<FILENAME CLASS="DIRECTORY">/var/spool/postoffice/</>)</></>
<LISTITEM><PARA>The log directory:
  <FILENAME CLASS="DIRECTORY">$<VARNAME>LOGDIR</>/</>
  (<FILENAME>/var/log/mail</>)</></>
</ITEMIZEDLIST>
</PARA>

<PARA>
The <APPLICATION>GNU autoconfig</> mechanism is used, however, you
still may need to touch on some files after that system has run through:
You MUST define <OPTION>--prefix=</> so that ZMailer components end up
in reasonable places.  The <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILBIN</>/</>
(and <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILSHARE</>/</>, and
 <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILVAR</>/</>)
variable values are derived from the <OPTION>--prefix=</>, which can
cause surprises if you do <COMMAND>make install</> with
<APPLICATION>GNU autoconfig</> defaults.
</PARA>

<PARA>
When choosing your prefix, do try to keep is fairly short, as
there are a few scripts which catenate string-components of:%
<SCREEN>
  "#! "+prefix+"/bin/router -f"
</SCREEN>
and usually systems have a limit of 32 characters for that,
which gives at most 15 characters for your prefix!
</PARA>

<PARA>
Also, if the <FILENAME>/etc/zmailer.conf</> file
exists<FOOTNOTE><PARA>Default location is <FILENAME>/etc/zmailer.conf</>,
and it can be changed with <OPTION>--with-zconfig=</> option.
</PARA></FOOTNOTE>,
it is read to initialize several different environment paths (including
<FILENAME CLASS="DIRECTORY">$<VARNAME>MAILBIN</>/</>, et.al.!)

<SCREEN>
<PROMPT>#</> <USERINPUT>./configure                             \
  --prefix=/opt/mail                      \
  --with-postoffice=/var/spool/postoffice \
  --with-mailbox=/var/mail                \
  --with-logdir=/var/log/mail             \
  --with-zconfig=/etc/zmailer.conf</USERINPUT></SCREEN></PARA>

<PARA>
Or an example from my development machine:
<SCREEN>
  <PROMPT>$ </><USERINPUT>./configure --prefix=/opt/mail</>
  creating cache ./config.cache
  ***
  *** You can set  ZCONFIG  environment variable to define
  *** the location of the (default) /etc/zmailer.conf -file
  *** (You can use also   --with-zconfig=  -parameter)
  ***
  *** Consider also setting following parameters:
  ***   --mandir=DIR     -- for man-pages
  ***   --libdir=DIR     -- for libzmailer(3)
  ***   --includedir=DIR -- for libzmailer(3)
  *** (They can be outside the --prefix=DIR -tree)
  ***
  *** You can set CC, and CFLAGS  environment variables to
  *** choose the C-compiler, and its options, especially at
  *** systems where there are multiple choices to use...
  ***
</SCREEN>
</PARA>

<PARA>
You can also go into a subdirectory, and configure and
compile there: (But it may need <APPLICATION>GNU make</>
as system ``<COMMAND>make</>''!)
<SCREEN>
  <PROMPT>$ </><USERINPUT>mkdir myhost ; cd myhost</>
  <PROMPT>$ </><USERINPUT>../configure ...</>
  <PROMPT>$ </><USERINPUT>make </>...
</SCREEN>
</PARA>

<PARA>
See if <FILENAME>SiteConfig</> makes sense now, if not, you can tune
most of the values with various <OPTION>--with-*=</> keywords:
<SCREEN>
  <PROMPT>$ </><USERINPUT>./configure --help</>
</SCREEN>
Explanations about these configuration options are listed
at chapter <XREF LINKEND="zins.configure-options-list">.
</PARA>

<PARA>
Those options that you can't tune, you can edit at
the ``<FILENAME>SiteConfig.in</>'' file.
(Redo the configure with new parameters, if that looks
 to be necessary approach.)
</PARA>

<PARA>
Additional examples:
<ITEMIZEDLIST>
<LISTITEM><PARA>DEC OSF/1 at nic.funet.fi with DECs best compiler&hellip;
<SCREEN>
  <PROMPT>$ </><USERINPUT>CFLAGS="-O -g3 -std1" CC="cc -migrate" \</>
    <USERINPUT>./configure --prefix=/l/mail</>
</SCREEN></PARA></LISTITEM>

<LISTITEM><PARA>Sun Solaris 2.5  at mailhost.utu.fi, SunSoft CC
<SCREEN>
  <PROMPT>$ </><USERINPUT>CC="cc -O" ./configure --prefix=/opt/mail</>
</SCREEN></PARA></LISTITEM>

<LISTITEM><PARA>Sun Solaris 2.5  at mailhost.utu.fi, gcc-2.7.2
<SCREEN>
  <PROMPT>$ </><USERINPUT>./configure --prefix=/opt/mail --with-gcc</>
</SCREEN></PARA></LISTITEM>

<LISTITEM><PARA>Linux-2.0.x/libc-5.4.2 at mea.cc.utu.fi, gcc-2.7.2
<SCREEN>
  <PROMPT>$ </><USERINPUT>./configure --prefix=/l/mail</>
</SCREEN></PARA></LISTITEM>
</ITEMIZEDLIST>
</PARA>
</SECT1>

<SECT1><TITLE>Compilation</>

<PARA>
At the toplevel, run
<SCREEN>
  <PROMPT>$ </><USERINPUT>make</>
</SCREEN>
or perhaps:
<SCREEN>
  <PROMPT>$ </><USERINPUT>make clean all</>
</SCREEN>
which at first cleans everything, and then makes &mdash; great if you
changed some configuration parameters.
</PARA>

<PARA>
This should compile everything, and leave a <FILENAME>zmailer.Config</>
file in the toplevel directory.  Nothing outside the source area will be
touched at this point.
</PARA>

<PARA>
(If your system ``<COMMAND>make</>'' lets your shell ``<VARNAME>SHELL</>''
 environment affect its own execution environment, it may be that
 non-<COMMAND>sh</>/<COMMAND>ksh</>/<COMMAND>zsh</> users detect
 weird phenomena, and failures. Beware!)
</PARA>

</SECT1>

<SECT1><TITLE>Installing and Upgrading</TITLE>

<PARA>
This section describes how to install or upgrade ZMailer.
</PARA>

<SECT2><TITLE>Install Preparation</TITLE>
<!-- <INDEXTERM><PRIMARY>build</><secondary>upgrade preparation</></>
     <INDEXTERM><PRIMARY>installation</><secondary>preparations</></> -->

<PARA>
If you are currently running a zmailer, kill off all mailer processes
using
<SCREEN>
  <PROMPT>$ </><USERINPUT>zmailer kill</>
</SCREEN>
and save the state of your system.  This includes any active contents
of the <FILENAME CLASS="DIRECTORY">$<VARNAME>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
``<FILENAME CLASS="DIRECTORY">bak/</>'' subdirectories.
</PARA>

<PARA>
The interface in between the commonly used sendmail, and ZMailer
is a ``compability program'', which is to replace the
<FILENAME>/usr/lib/sendmail</FILENAME>
(aka <FILENAME>/usr/sbin/sendmail</> on some systems).
The system attempts to automate the replacement, but it <EMPHASIS>may</>
present a cry for help if your system does not have functioning symlinks.
Also if ``<COMMAND>test -h $<VARNAME>SENDMAILPATH</></>'' does fault in mysterious ways,
the reason may be that your system does not have symlinks.
</PARA>

<PARA>
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 <FILENAME>/usr/lib/sendmail.bak</>,
for example) binary back to <FILENAME>/usr/lib/sendmail</>.
</PARA>

<PARA>
(You may also need to do some magics with system startup scripts
in case you are running SysV-style init. BSD <FILENAME>/etc/rc.local</>
does need its own gymnastics too.
Sample SysV-init script is at file: ``<FILENAME>proto/zmailer.init.sh</>'')
</PARA>

<PARA>
A sort of method to quickly handle your sendmail queue is to
start ZMailer's SMTP server, reconfigure the old sendmail to
use smarthost, which happens to be at the same machine.
(Or at an adjacent machine if you moved the queue, or ...)
Anyway the point is to get the sendmail to send its queue
via SMTP to the ZMailer.
An equally valid option is to drain the sendmail's queue by running
sendmail in queue drain mode only, although <FILENAME>/usr/lib/sendmail</>
points to ZMailer's ``<COMMAND>sendmail</>.''
</PARA>

</SECT2>

<SECT2><TITLE>Installation</>
<!-- <INDEXTERM><PRIMARY>build</><secondary>installation</></>
     <INDEXTERM><PRIMARY>installation</><secondary>entire ZMailer</></> -->

<PARA>
Once you are safe, run either:
<SCREEN>
  <PROMPT># </><USERINPUT>make install</>
</SCREEN>
(this installs all binaries and the default database files, which
still need editing! See below.)
or if you just want to have the new <EMPHASIS>binaries</> without touching
at your configurations:
<SCREEN>
  <PROMPT># </><USERINPUT>make install-bin</>
</SCREEN>
however this method might not be a complete success in case boilerplate
configurations need to be updated as well to match the programs.
</PARA>

<PARA>
There exists also a way to do the installation into a ``parallel universe''
by means of install-time ``prefix'' environment variable:
<SCREEN>
  <PROMPT># </><USERINPUT>prefix=/var/tmp/build make install-bin</>
</SCREEN>
which of course expects to have ``<FILENAME>/var/tmp/build/</>'' directory in existence,
and possibly some others under it, but you will soon see, what it needs.
</PARA>


<IMPORTANT>
<PARA>FIXME! FIXME! (Update with POST-INSTALL.SH program!)</PARA>
<PARA>
All programs are stored into
<FILENAME CLASS="DIRECTORY">$<VARNAME>MAILBIN</>/</>, and
<FILENAME CLASS="DIRECTORY">$<VARNAME>MAILBIN</>/ta/</>, and
possible older binaries are saved into ``<FILENAME CLASS="DIRECTORY">bak/</>''
subdirectories.
This step should be non-destructive (anything replaced will be
saved in a ``<FILENAME CLASS="DIRECTORY">bak/</>'' directory,
and <EMPHASIS>for some customizable files, if they exist, new versions
won't replace them</EMPHASIS>).
</PARA>

<PARA>
If this is not a from-scratch installation, be aware that the install
procedure will <EMPHASIS>not</> replace some of the files in
<FILENAME CLASS="DIRECTORY">$<VARNAME>MAILSHARE</>/</> with the equivalents
from the distribution.
Specifically, the <FILENAME>$<VARNAME>MAILSHARE</>/cf/*</>,
<FILENAME>$<VARNAME>MAILVAR</>/db/aliases</>,
<FILENAME>$<VARNAME>MAILVAR</>/db/routes</>, and
<FILENAME>$<VARNAME>MAILVAR</>/db/localnames</>
files are never replaced if they already exist.
The <FILENAME>$<VARNAME>MAILSHARE</>/forms/*</> files are always replaced,
but the old files will be saved in a ``<FILENAME CLASS="DIRECTORY">bak/</>''
directory.
</PARA>
</IMPORTANT>
</SECT2>

<SECT2><TITLE>Installing the Manual Pages.</TITLE>
<!-- <INDEXTERM><PRIMARY>build</><secondary>man-page install</></>
     <INDEXTERM><PRIMARY>installation</><secondary>man-pages</></> -->

<PARA>
Because for a long time the installation location of ZMailer's man-pages
has not had an obvious destination location, normal ``make install''
does <EMPHASIS>not</> install them!
</PARA>

<PARA>
Go into the <FILENAME CLASS="DIRECTORY">man/</> directory,
and install the manual pages by hand:
<SCREEN>
  <PROMPT># </><USERINPUT>cd man ; make install</>
</SCREEN>
or in case the default guessing didn't get it right:
<SCREEN>
  <PROMPT># </><USERINPUT>cd man ; make install MANDIR=/our/manpages</>
</SCREEN>
</PARA>

</SECT2>

<SECT2><TITLE>The Router Configuration File (<FILENAME>$<VARNAME>MAILSHARE</>/router.cf</>).</>
<!-- <INDEXTERM><PRIMARY>build</><SECONDARY>config</><TERTIARY>router configuration; <FILENAME>router.cf</></></>
     <INDEXTERM><PRIMARY><FILENAME>router.cf</>; router configuration</><SECONDARY>config</></> -->

<PARA>
You must now pick a toplevel router configuration file.
The default is provided in <FILENAME>proto/cf/SMTP+UUCP.cf</>
(by now copied to <FILENAME>$<VARNAME>MAILSHARE</>/cf/SMTP+UUCP.cf</>).
</PARA>

<PARA>
You need to create <FILENAME>$<VARNAME>MAILSHARE</>/router.cf</>.
</PARA>

<PARA>
The simplest method is to make it symbolic link to, or copy of,
the <FILENAME>cf/SMTP+UUCP.cf</> file.
</PARA>

<PARA>
Some real-life samples of <FILENAME>router.cf</> are at
the <FILENAME>proto/</> directory in the source tree.
</PARA>

</SECT2>
</SECT1>
</CHAPTER>

<CHAPTER><?dbhtml filename="zins-sysconfig.html">
<TITLE>System Configuring</>
<!-- <INDEXTERM><PRIMARY>build</><SECONDARY>config</></>
     <INDEXTERM><PRIMARY>configuration</><SECONDARY>basic ZMailer installation</></> -->

<SECT1><TITLE>Runtime files</TITLE>
<PARA>
This section describes the configuration in short. More detailed information 
can be found in section FIXME! FIXME! xxxxx....
</PARA>

<SECT2><TITLE><FILENAME>/etc/group</></>
<!-- <INDEXTERM><PRIMARY>build</><SECONDARY><FILENAME>/etc/group</> entries</></>
     <INDEXTERM><PRIMARY>build</><SECONDARY>security note: <FILENAME>/etc/group</> entries</></> -->

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

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

<WARNING><PARA>
<EMPHASIS>SECURITY ITEM</>: Those users at <LITERAL>zmailer</> group
<EMPHASIS>must not</> contain <LITERAL>nobody</>!
</PARA><PARA>
The <LITERAL>nobody</> is used to prevent externally given inputs from being
able to execute arbitary programs at the system, or from writing to
arbitary files.</PARA></WARNING>

</SECT2>

<SECT2><TITLE><FILENAME>/etc/services</></>

<PARA>
Add the following line to <FILENAME>/etc/services</> in the section for
host-specific services:
<SCREEN>
mailq   174/tcp  # Mailer transport queue
</SCREEN>
Indeed this isn't <EMPHASIS>quite</> mandatory, as the <COMMAND>scheduler</>
subsystem can be configured to use different ipc socket.
FIXME: Reference to scheduler.conf:PARAM entries!
</PARA>

</SECT2>

<SECT2><TITLE><FILENAME>/etc/mail.conf</></>
<!-- <INDEXTERM><PRIMARY>build</><SECONDARY>config</><TERTIARY><FILENAME>/etc/mail.conf</></></>
     <INDEXTERM><PRIMARY><FILENAME>/etc/mail.conf</>-file</></> -->

<PARA>
If you are using the default configuration setup, the <FILENAME>router.cf</>
file expects to find a <FILENAME>/etc/mail.conf</> file containing three
variable definitions:
<SCREEN>
  # Where am I?
  orgdomain=domain
  # Who am I?
  hostname=host.subdomain.$orgdomain
  # Who do I claim to be?
  mydomain=subdomain.$orgdomain
</SCREEN>
</PARA>

<PARA>
For example:
<SCREEN>
  orgdomain=toronto.edu
  hostname=relay.cs.$orgdomain
  mydomain=cs.$orgdomain
</SCREEN>
</PARA>

<PARA>
Create <FILENAME>/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
(<FILENAME>UT*.cf</>) for examples of this.
</PARA>

<PARA>
Location of this file is written in
<FILENAME>$<VARNAME>MAILSHARE</>/router.cf</>.
By editing that entry you can alter it &mdash; into
<FILENAME>$<VARNAME>MAILSHARE</>/mail.conf</>,
for example.
</PARA>

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

</SECT2>
</SECT1>

<SECT1><TITLE>Verifying That the Router Starts</>
<!-- <INDEXTERM><PRIMARY>build</><SECONDARY>router start verify</></>
     <INDEXTERM><PRIMARY>installation</><SECONDARY>router start verify</></> -->

<PARA>
At this point, you should be able to start the router process in
interactive mode.  Run:
<SCREEN>
  <PROMPT># </><USERINPUT>$MAILBIN/router -i</>
</SCREEN>
or
<SCREEN>
  <PROMPT># </><USERINPUT>/usr/lib/sendmail -bt</>
</SCREEN>
</PARA>

<PARA>
You should see something like:
<SCREEN>
  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#
</SCREEN>
</PARA>

<PARA>
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 <USERINPUT>exit</>.
</PARA>

</SECT1>

<SECT1><TITLE>The Database Files</>
<!-- \index{build!config!databases}    \index{build!config!forms files}%
     \index{configuration!forms files} \index{configuration!databases}    -->

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

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

<SECT2><TITLE><FILENAME>$MAILBIN/zmailer</> script</>

<PARA>
You may want to add a symbolic link from some directory in your path
to <FILENAME>$<VARNAME>MAILBIN</>/zmailer</>, if you don't already have this.
I put this link in <FILENAME CLASS="DIRECTORY">/usr/local/sbin</>.
</PARA>
</SECT2>

<SECT2><TITLE><FILENAME>$MAILVAR/db/aliases</> file</>

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

<PARA>
Choose one of the following methods to rebuild the database:
<SCREEN>
  <PROMPT># </><USERINPUT>$MAILBIN/newaliases</>
  <PROMPT># </><USERINPUT>$MAILBIN/zmailer newaliases</>
  <PROMPT># </><USERINPUT>/usr/lib/sendmail -bi</>
  <PROMPT># </><USERINPUT>/usr/bin/newaliases</>
  <PROMPT># </><USERINPUT>$MAILBIN/zmailer newdb</>
</SCREEN>
</PARA>

<PARA>
If there are errors, correct them in the ``<FILENAME>aliases</>'' file,
and repeat the command until the alias database has been initialized.
The final message should look something like:
<SCREEN>
 319 aliases, longest 209 bytes, 16695 bytes total
</SCREEN>
exact numbers vary, of course...
</PARA>

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

</SECT2>

<SECT2 ID="configure-localnames-file">
<TITLE><FILENAME>$MAILVAR/db/localnames</> file</>

<!-- <INDEXTERM><PRIMARY>build</><SECONDARY><FILENAME>$<VARNAME>MAILVAR</>/db/localnames</></></> -->

<PARA>
Add the hostnames you want ZMailer to do local delivery for, to the
<FILENAME>$<VARNAME>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 ``<EMPHASIS ROLE="BOLD">.domain</>'' names
in this file, to indicate everything under some subdomain.
</PARA>

<PARA>
With the sample config files for Zmailer-2.98, and latter,
this <FILENAME>localnames</> is actually a mapping of those various
names to the desired forms of the canonic name, thus an example as seen
in figure <XREF LINKEND="fig.inst.localnames">.
</PARA>

<FIGURE ID="fig.inst.localnames" PGWIDE="1" FLOAT="1">
<TITLE>Sample of ``<FILENAME>localnames</>'' file</TITLE>
<SCREEN>
#
# Left:  input name
# Right: what is wanted to be shown out
#
# List here <EMPHASIS ROLE="BOLD">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
</SCREEN>
</FIGURE>

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

<PARA>
<EMPHASIS ROLE="BOLD">THUS: All names that the host may ever have are
 best listed in here!</EMPHASIS>
It reminds you of them, and makes sure a message destined into the host
really is accepted.
</PARA>

<PARA>
Compile this into runtime binary database with command:
<SCREEN>
  <PROMPT># </><USERINPUT>zmailer newdb</>
</SCREEN>
(fall-back method is sequential rescan of the text file)
</PARA>

</SECT2>

<SECT2><TITLE><FILENAME>$<VARNAME>MAILVAR</>/db/routes</> file</>

<PARA>
Add any UUCP neighbours or other special cases to this file.
For an example see <XREF LINKEND="fig.inst.routes">.
</PARA>

<PARA>
You can compile the file into binary database with command:
<SCREEN>
  <PROMPT># </><USERINPUT>zmailer newdb</>
</SCREEN>
</PARA>

<FIGURE ID="fig.inst.routes" PGWIDE="1" FLOAT="1">
<TITLE>Sample of ``<FILENAME>routes</>'' file</TITLE>
<SCREEN>
  #
  # ``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
</SCREEN>
</FIGURE>
</SECT2>

<SECT2><TITLE><FILENAME>$<VARNAME>MAILVAR</>/db/fqdnaliases</> file</>

<PARA>
The <FILENAME>fqdnaliases</> database is for mapping fully-qualified
user addresses to others &mdash; 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
<XREF LINKEND="fig.inst.fqdnaliases">.
</PARA>

<FIGURE ID="fig.inst.fqdnaliases" PGWIDE="1" FLOAT="1">
<TITLE>Sample of ``<FILENAME>fqdnaliases</>'' file</TITLE>
<SCREEN>
  postmaster@domain1: person1
  postmaster@domain2: person2
  postmaster@domain3: person3, person4
</SCREEN>
</FIGURE>

<PARA>
It is also possible to shunt all recipient addresses for given domain to
some arbitary addresses as shown at <XREF LINKEND="fig.inst.fqdnaliases-2">.
</PARA>

<FIGURE ID="fig.inst.fqdnaliases-2" PGWIDE="1" FLOAT="1">
<TITLE>Second sample of ``<FILENAME>fqdnaliases</>'' file</TITLE>
<SCREEN>
  @domain4:  person4
</SCREEN>
</FIGURE>

<PARA>
This facility is always in stand-by &mdash; just add the file, and
you have it at the next router startup.
</PARA>

<PARA>
You may even handle just a few users for each of those domains, and then
have the ``<FILENAME>routes</>'' entry (see above at
<XREF LINKEND="fig.inst.routes">) to declare something
suitable:
<SCREEN>
  .domain1  error!nosuchuser
</SCREEN>
which combined with the ``<FILENAME>fqdnalias</>'' method will let
``<FILENAME>postmaster@domain1</>'' to exist, and report error on all others.
</PARA>

<PARA>
Choose one of the following methods to rebuild the database:
<SCREEN>
  <PROMPT># </><USERINPUT>$<VARNAME>MAILBIN</>/newfqdnaliases</>
</SCREEN>
or either of:
<SCREEN>
  <PROMPT># </><USERINPUT>$<VARNAME>MAILBIN</>/zmailer newfqdnaliases</>
  <PROMPT># </><USERINPUT>$<VARNAME>MAILBIN</>/zmailer newdb</>
</SCREEN>
</PARA>

<PARA>
If there are errors, correct them in the ``<FILENAME>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.
</PARA>

</SECT2>

<SECT2><TITLE>UUCP Node Names</>

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

</SECT2>
</SECT1>

<SECT1><TITLE>Checking the Routing</>

<PARA>
At this point, you should be able to start the router again in
interactive mode, and ask it to route addresses.  Try:
<SCREEN>
  <PROMPT># </><USERINPUT>/usr/lib/sendmail -bt</>
</SCREEN>
at the prompt:
<SCREEN>
  <PROMPT>z# </><USERINPUT>router you</>
</SCREEN>
should print out:
<SCREEN>
  (((local you you default_attributes)))
</SCREEN>
</PARA>

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

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

<SECT1><TITLE>Checking the Scheduler</>

<PARA>
The location of the <FILENAME>scheduler.conf</> on running system is
<FILENAME>$<VARNAME>MAILSHARE</>/scheduler.conf</>
</PARA>

<PARA>
For normal operations of the system the current sample
of ``<FILENAME>scheduler.conf</>''
<!-- <INDEXTERM><PRIMARY><FILENAME>scheduler.conf</></></> -->
file is quite sufficient, but in case you want to do something
unusual, like using <APPLICATION>procmail</> for local delivery,
do read on.
</PARA>

<PARA>
In <XREF LINKEND="fig.inst.scheduler1"> there are some salient points
about tuning the ``<FILENAME>local</>'' channel behaviour.
</PARA>

<FIGURE ID="fig.inst.scheduler1" FLOAT="1" PGWIDE="1">
<TITLE>Sample of ``<FILENAME>scheduler.conf</>'' passage
for ``<FILENAME>local/*</>'' selector</TITLE>
<SCREEN>
  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"
</SCREEN>
</FIGURE>

<PARA>
There are three variants of the ``command='' entry:
<VARIABLELIST TERMLENGTH="99">
<VARLISTENTRY>
<TERM>command="mailbox -8"</TERM>
<LISTITEM><PARA>
The normal ZMailer <COMMAND>mailbox</>(8) channel program.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM>command="sm -8c $channel procm"</TERM>
<LISTITEM><PARA>
Variant for running <APPLICATION>procmail</>.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM>command="sm -8c $channel cyrus"</TERM>
<LISTITEM><PARA>
Variant for using <APPLICATION>CMU Cyrus</> message store server.
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST>
</PARA>

<PARA>
For more information regarding <EMPHASIS>scheduler</> configuration language,
see <XREF LINKEND="zref.schedulerconfig">.
</PARA>

<SECT2 ID="sm.conf"><TITLE>Checking <FILENAME>sm.conf</> file</>
<!-- <INDEXTERM><PRIMARY><FILENAME>sm.conf</>-file</></> -->

<PARA>
For some uses the scheduler runs <COMMAND>sm</>(8) program &mdash; called
``sendmail-like mailer''.
</PARA>

<PARA>
This supports <EMPHASIS>most</> of <APPLICATION>sendmail</>'s
<FILENAME>M</>-entry flags, at least flags with versions previous to 8.x
</PARA>

<PARA>
The ZMailer <COMMAND>sm</>(8) channel program is used to create support
for things like:
<ITEMIZEDLIST>
<LISTITEM><PARA><EMPHASIS>uucp</> transmits
</PARA></LISTITEM>
<LISTITEM><PARA><APPLICATION>procmail</> as local delivery agent
</PARA></LISTITEM>
<LISTITEM><PARA>supporting <APPLICATION>CMU Cyrus message store</>
as local delivery agent </PARA></LISTITEM>
</ITEMIZEDLIST>
</PARA>

<PARA>
For more information, see <XREF LINKEND="ref.ta.smconfig">.
</PARA>

</SECT2>

<SECT2><TITLE>The ``<FILENAME>smtpserver.conf</>'', and smtp-policy databases</>
<!-- <INDEXTERM><PRIMARY>smtpserver</><SECONDARY><FILENAME>smtpserver.conf</>-file</></> -->

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

<PARA>
Basically you want to install the boilerplates and the tool scripts,
edit them a bit, and run <COMMAND>policy-builder.sh</> script.
For further details on this, see chapter
<XREF LINKEND="adm.smtp-policy-filtering">.
</PARA>

<PARA>
In <COMMAND>smtpserver</> front you may need to lower the strict standards
of the basic RFC-821 SMTP protocol and allow acceptance of non-qualified
addresses &mdash; ones without any sort of domain name in them.
</PARA>

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

<PARA>
Both of these things are handled by ``EHLO-style options'' described
at chapter <XREF LINKEND="adm.smtpserver.ehlostyle">.
</PARA>

</SECT2>
</SECT1>


<SECT1><TITLE>Bootup Scripts</TITLE>

<PARA>
Add something like the following lines to bootup scripts
(<FILENAME>/etc/rc.local</> or <FILENAME>/etc/rc2.d/S99local</> or similar):
<SCREEN>
  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
</SCREEN>
</PARA>

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

</SECT1>

<SECT1><TITLE>Checking the Log Files</>

<PARA>
Start ZMailer:
<SCREEN>
 $MAILBIN/zmailer
</SCREEN>
</PARA>

<PARA>
Keep an eye on the log files (<FILENAME>$<VARNAME>LOGDIR</>/router</>,
<FILENAME>$<VARNAME>LOGDIR</>/scheduler</>), the
<FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</>/postman/</> directory
for malformed message files, and
<FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</>/deferred/</> in case
of resource problems.
</PARA>

</SECT1>

<SECT1><TITLE>Crontab</TITLE>


<FIGURE ID="fig.inst.crontab" PGWIDE="1" FLOAT="1">
<TITLE>ZMailer related crontab entries for root user</>
<SCREEN>
  # 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
</SCREEN>
</FIGURE>

<PARA>
See figure <XREF LINKEND="fig.inst.crontab"> for two crontab entires for
the root to run.  There are three entries:
<ORDEREDLIST NUMERATION="ARABIC">
<LISTITEM><PARA>
This will ``<COMMAND>resubmit</>'' messages that have been deferred
with no useful processing possible at time of deferral.
Adjust the resubmission interval to suit your environment.
<EMPHASIS>Having files in ``deferred'' state is a sign of troubles!
Always investigate!</>
</PARA></LISTITEM>

<LISTITEM><PARA>
This ``<COMMAND>cleanup</>'' is to regularly clean out
the ``<FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</>/public/</>'', and
``<FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</>/postman/</>''
directories.
</PARA></LISTITEM>

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

<PARA>
You may want to hardwire the location of the zmailer script.
</PARA>
</SECT1>

<SECT1><TITLE>Customizing ZMailer Messages</TITLE>

<PARA>
Edit several of the canned error messages and programs (scripts)
to reflect your local configuration:
<FILENAME CLASS="DIRECTORY">$<VARNAME>MAILSHARE</>/forms/</> files and
<FILENAME>$<VARNAME>MAILBIN</>/ta/usenet</> (injected message).
</PARA>

<PARA>
Normally the boilerplate messages looks something like these:
<SCREEN>
HDR From:    The Post Office &lt;postmaster&gt;
HDR Sender:  mailer-daemon
SUB Subject: Errors: No such user(s)
ADR Bcc:     &lt;postmaster&gt;

This is a collection of reports about email delivery
process concerning a message you originated:
</SCREEN>
In these, ``ADR'' lines define header lines which are to be analyzed
for <EMPHASIS>recipient</> addresses, while ``HDR'' lines can carry
anything which doesn't get output as <EMPHASIS>envelope</> address.
The ``ADR'' line contained addresses <EMPHASIS ROLE="BOLD">must</> be in
brackets, and there can be only one address per such header.  If there
are more, only the first one is picked.
</PARA>

<PARA>
<EMPHASIS>FIXME: FIXME: XREF to Scheduler</>
</PARA>

</SECT1>

<SECT1><TITLE>Alias expansion</TITLE>

<PARA>
Read the notes on alias expansion in the file <FILENAME>doc/guides/aliases</>
and on mailing list maintenance in <XREF LINKEND="mailing-list-maintenance">, 
<EMPHASIS>Mailing Lists and <FILENAME>~/.forward</>.</EMPHASIS>
</PARA>

</SECT1>


<SECT1><TITLE>Trimdown of Logging</TITLE>

<PARA>
Once satisfied that things appear to work, you may want to trim down
logging: there are four kinds of logging to deal with:
<ITEMIZEDLIST>
<LISTITEM><PARA>Router logs:</PARA>
<PARA>
FIXME! FIXME!
Usually kept in <FILENAME>$<VARNAME>LOGDIR</>/router</>.
his is the stdout and stderr output of the router daemon.
If you wish to turn it off,
see <FILENAME>$<VARNAME>MAILSHARE</>/cf/standard.cf</> for routine
dribble()},
and especially its invocations!
</PARA></LISTITEM>

<LISTITEM><PARA>Scheduler logs:</PARA>
<PARA>
Usually kept in <FILENAME>$<VARNAME>LOGDIR</>/scheduler</>.  Same as router.
</PARA></LISTITEM>

<LISTITEM><PARA>General Mail Logs:</PARA>
<PARA>
Usually kept in syslog files, depending on how you have configured
the syslog utility (<FILENAME>/etc/syslog.conf</FILENAME>).
All ZMailer programs log using the <FILENAME>LOG_MAIL</> facility code
for normal messages.  You can deal with this specifically in your
<COMMAND>syslog</> configuration file on systems with a 4.3bsd-based syslog.
The following reflects the recommended configuration on SunOS 4.0:
<SCREEN>
  mail.crit   /var/log/syslog
  mail.debug  /var/log/mail/mail.syslog
</SCREEN>
</PARA>

<PARA>
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).
</PARA></LISTITEM>

<LISTITEM><PARA>
By default, the postmaster will <EMPHASIS>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 <VARNAME>FORMSDIR</>
(<FILENAME CLASS="DIRECTORY">proto/forms</> in the distribution,
or <FILENAME CLASS="DIRECTORY">$<VARNAME>MAILSHARE</>/forms</> when installed).
You should review these in any case to make sure the text is
appropriate for your site.
</PARA></LISTITEM>
</ITEMIZEDLIST>
</PARA>

</SECT1>
</CHAPTER>

<CHAPTER><?dbhtml filename="zins-clientinst.html">
<TITLE>Installation to Clients</>

<PARA>
This section describes the installation at clients.
</PARA>

<SECT1><TITLE>Required Files</TITLE>

<VARIABLELIST TERMLENGTH="99">
<TITLE>The following files/programs are needed on clients:</TITLE>
<VARLISTENTRY><TERM><FILENAME>/etc/zmailer.conf</></>
<LISTITEM><PARA>
The <VARNAME>$MAILSERVER</> variable may be set to the mail server host's name.
This is not required as <COMMAND>mailq</> will usually be able to discover this
by itself.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM><FILENAME>/usr/lib/sendmail</></>
<LISTITEM><PARA>
to submit mail
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM><COMMAND>mailq</></>
<LISTITEM><PARA>
should be installed in the site's local <FILENAME CLASS="DIRECTORY">bin</>
so people can query the mail server.
(Remember to update <FILENAME>/etc/services</>)
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM><FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</></></>
<LISTITEM><PARA>
This directory from the server should be mounted and writable.
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST>

</SECT1>

<SECT1><TITLE>Mounting <FILENAME>$MAILBOX</>es and/or
<FILENAME>$POSTOFFICE/</> Hierarchies via NFS</>

<PARA>
This is mostly for client machines,
but the NFS may plaque you also at servers.
</PARA>

<PARA>
If you for some obscure reason are mounting
<FILENAME CLASS="DIRECTORY">$<VARNAME>MAILBOX</></>es
and/or <FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</></>
hierarchies via NFS, do it with options to disable various attribute caches:
<SCREEN>
              actimeo=0
    alias:    noac
</SCREEN>
</PARA>

<PARA>
<EMPHASIS>The best advice is to NOT to mount anything over NFS</>,
but some people can't be persuaded...
</PARA>

<PARA>
Lots of things are done where file attributes play important
role, and they are extremely important to be in sync!
(Sure, the ``<OPTION>noac</>' slows down the system, but avoids errors
caused by bad attribute caches.)
</PARA>

<PARA>
If you are mounting people's home directories (<FILENAME>~/.forward</> et al.)
via NFS, consider the same rule!
</PARA>

<PARA>
Often if the mail folder directory is shared, also
one of following (depending upon the system):
<SCREEN>
   /usr/mail
   /usr/spool/mail
   /var/mail
   /var/spool/mail
</SCREEN>
</PARA>

</SECT1>
</CHAPTER>

<CHAPTER ID="ZINS.CONFIGURE-OPTIONS-LIST">
<?dbhtml filename="zins-configure-options.html">
<TITLE><FILENAME>./configure</> options</>
<!-- <INDEXTERM><PRIMARY>build</><SECONDARY>configure</><TERTIARY>options</></>
     <INDEXTERM><PRIMARY>configure</><SECONDARY>options</></>  -->

<PARA>
configure  options of ZMailer package, per version 2.99.50.
</PARA>

<PARA>
The  configure  script has three kinds of parameters for it:
</PARA>
<ITEMIZEDLIST>
<LISTITEM><PARA>(optional) environment variables for CC="..." et.al.</></>
<LISTITEM><PARA>ZENV data pulled in from <FILENAME>$<VARNAME>ZCONFIG</></>
 file (if it exists)</></>
<LISTITEM><PARA>various  <OPTION>--with-*</>  et.al. options</></>
</ITEMIZEDLIST>

<SECT1><TITLE>Used environment variables</TITLE>

<VARIABLELIST TERMLENGTH="99">
<TITLE>User environment variables</TITLE>
<VARLISTENTRY><TERM><VARNAME>ZCONFIG</>="/file/path"</TERM>
<LISTITEM><PARA>
Using this is alternate for using ``<OPTION>--with-zconfig=../</>'' option.
Not needed if the default of <FILENAME>/etc/zmailer.conf</> is used.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><VARNAME>CC</>="command"</>
<TERM><VARNAME>CFLAGS</>="options"</>
<LISTITEM><PARA>
Obvious ones, compiler, and possible "-g -O" flags...
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><VARNAME>CPPDEP</>="command"</>
<LISTITEM><PARA>
Not normally needed &mdash; builds dependencies
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><VARNAME>INEWSBIN</>=/file/path</>
<LISTITEM><PARA>
If you want to pre-define where your `inews' program
is &mdash; for possible use of `usenet' channel.
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST>

<PARA>
Recycled ZENV variables (from $<VARNAME>ZCONFIG</> file):
<SCREEN>
  For these see  SiteConfig(.in)  file

  ZCONFIG=
  MAILBOX=
  POSTOFFICE=
  MAILSHARE=
  MAILVAR=
  MAILBIN=
  LOGDIR=
  NNTPSERVER=
  SCHEDULEROPTIONS=
  ROUTEROPTIONS=
  SMTPOPTIONS=
  LOGDIR=
  SENDMAILPATH=
  RMAILPATH=
  SELFADDRESSES=
</SCREEN>
</PARA>

</SECT1>

<SECT1><TITLE>Options for various facilities</TITLE>

<VARIABLELIST TERMLENGTH="99">
<TITLE>Options for various facilities</TITLE>
<VARLISTENTRY>
<TERM><OPTION>--prefix=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>
The only really mandatory option, gives actually
defaults for <FILENAME>$<VARNAME>MAILSHARE</>/$<VARNAME>MAILVAR</>/$<VARNAME>MAILBIN</></FILENAME>:.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-gcc</OPTION></TERM>
<LISTITEM><PARA>
Compile with GCC even when you have "cc" around.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-zconfig=/FILE/PATH</OPTION></TERM>
<LISTITEM><PARA>
Where the runtime  <FILENAME>zmailer.conf</>   file is located
at (and with what name).  This is <EMPHASIS>the only</>
hard-coded info within libraries and thus programs using them.
Everything else is runtime relocatable by means of using
"variables" listed in this file.
</PARA>

<PARA>
Default: <FILENAME>/etc/zmailer.conf</>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-mailbox=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>
Overrides system-dependent location of the user mail-boxes.
Defaults are looked up thru list of directories:
<SCREEN>
 /var/mail
 /var/spool/mail
 /usr/mail
 /usr/spool/mail
</SCREEN>
First found directory will be the default &mdash; or then
system yields  <FILENAME CLASS="DIRECTORY">/usr/spool/mail</>.
</PARA></LISTITEM></VARLISTENTRY>


<VARLISTENTRY>
<TERM><OPTION>--with-postoffice=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>
Overrides system-dependent location of
the ``<FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</></>'' directory
under which system stores queued email.
Will try directories
<FILENAME CLASS="DIRECTORY">/{usr,var}/spool/postoffice/</> to
see, if previously installed directory tree exists.
Default will be  <FILENAME CLASS="DIRECTORY">/var/spool/postoffice/</>
in case there is no previously created postoffice directory.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-mailshare=/DIR/PATH</OPTION></TERM>
<!-- <LISTITEM></LISTITEM></VARLISTENTRY><VARLISTENTRY> -->
<TERM><OPTION>--with-mailvar=/DIR/PATH</OPTION></TERM>
<!-- <LISTITEM></LISTITEM></VARLISTENTRY><VARLISTENTRY> -->
<TERM><OPTION>--with-mailbin=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>
These are overrides for values derived from  <OPTION>--prefix=/DIR</>
option.</PARA>
<PARA><VARNAME>MAILSHARE</> = "$PREFIX", <VARNAME>MAILVAR</> = "$PREFIX",
but the last is <FILENAME>MAILBIN</> = "$PREFIX/bin".
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-logdir=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>
Explicite value to replace $<VARNAME>LOGDIR</> ZENV value and/or to
override default value of:  <FILENAME CLASS="DIRECTORY">/var/log/mail/</>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-nntpserver=HOST</OPTION></TERM>
<LISTITEM><PARA>
If you want to use ``<COMMAND>usenet</>'' channel, you need to name
NNTP server into which you feed news with NNTP.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-sendmailpath=/FILE/PATH</OPTION></TERM>
<LISTITEM><PARA>
Overrider for default location(s) of sendmail program.
ZENV variable $<VARNAME>SENDMAILPATH</> can be overridden with this.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-rmailpath=/FILE/PATH</OPTION></TERM>
<LISTITEM><PARA>
Overrider for default location(s) of rmail program.
ZENV variable $<VARNAME>RMAILPATH</> can be overridden with this.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-selfaddresses="NAME,NAME"</OPTION></TERM>
<LISTITEM><PARA>
Obsolete option regarding providing into in ZENV variable
to yield system internal names automagically for the SMTP
transport channel uses, and also for the router to see,
if destination IP address is local at the system.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-system-malloc</OPTION></TERM>
<LISTITEM><PARA>
Use system malloc() library, don't compile own:
Alternate for using: <OPTION>--with-libmalloc=system</>
This is default.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-libmalloc=LIBNAME</OPTION></TERM>
<LISTITEM><PARA>
Where ``LIBNAME'' is one of:
</PARA>
<VARIABLELIST TERMLENGTH="99">
<VARLISTENTRY>
<TERM><OPTION>system</OPTION></TERM>
<LISTITEM><PARA>
System malloc() as is.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>malloc</OPTION></TERM>
<LISTITEM><PARA>
Bundled "libmalloc" without debugging things.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>malloc_d</OPTION></TERM>
<LISTITEM><PARA>
Bundled "libmalloc" <EMPHASIS>with</> debugging things.
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST>

</LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-yp</OPTION></TERM>
<LISTITEM><PARA>
Want to use YP, and has it at default locations
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-yp-lib='-L... -lyp'</OPTION></TERM>
<LISTITEM><PARA>
If needed to define linking-time options to find the YP-library.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-ldap-prefix=DIRPREFIX</OPTION></TERM>
<LISTITEM><PARA>
If UMich/NetScape <APPLICATION>LDAP</> are available thru
<FILENAME CLASS="DIRECTORY">DIRPREFIX/include/</>
and <FILENAME CLASS="DIRECTORY">DIRPREFIX/lib/</>
locations, this is a short-hand to find the interface &mdash; with files
in the system primary include and lib locations,
``<FILENAME CLASS="DIRECTORY">/usr</>'' is a special value which
will be ignored.  There is no default value for
<FILENAME CLASS="DIRECTORY">DIRPREFIX</>.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-ldap-include-dir=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>
Special overrider for compilation include directory of LDAP
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-ldap-library-dir=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>
Special overrider for linkage library directory of LDAP
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--without-fsync</OPTION></TERM>
<LISTITEM><PARA>
At systems where the local filesystem is log-based/journaling,
doing   fsync()  is wastefull.  This disables fsync() in
cases where it is not needed.    (In others it may boost
your system performance by about 20% &mdash; with dangers..
On the other hand, recently a system disk(?) fault which
hang mailer at spool directory access did cause severe
damage all over, and propably use of this option would
not have made any difference..  fsck was mighty unhappy..)
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-bundled-libresolv</OPTION></TERM>
<LISTITEM><PARA>
If your system is not very modern, you may consider using
this option to compile in a resolver from bind-4.9.4-REL.
On the other hand, if your system is modern, it may have
even newer resolver in it.  At such time, don't use this!
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-ipv6</OPTION></TERM>
<LISTITEM><PARA>
Use IPv6 at things where it is supported.  This is often
highly experimental, although many subsystems in ZMailer
are built with   getnameinfo()  et.al. interfaces, which
works both on IPv4 and IPv6.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-ipv6-replacement-libc</OPTION></TERM>
<LISTITEM><PARA>
If the system needs more support for user-space IPv6
things, this generates those.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--without-rfc822-tabs</OPTION></TERM>
<LISTITEM><PARA>
Some systems dislike getting RFC-822 headers with form of:
<SCREEN>
   "Headername: &lt;TAB&gt; value"
</SCREEN>
With this option, no TABs are used and instead "ordinary"
space character is used.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-tcp-wrappers</OPTION></TERM>
<!-- <LISTITEM></LISTITEM></VARLISTENTRY><VARLISTENTRY> -->
<TERM><OPTION>--with-tcp-wrappers=/DIR/PATH</OPTION></TERM>
<LISTITEM><PARA>

Optional  <OPTION>=/DIR/PATH</>  value gives directory where there are
<FILENAME>tcpd.h</>  and  <FILENAME>libwrap.a</>  files.
Without value this option looks for several common locations
for those files, and if finds them, yields compile and linking
hooks,
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-ta-mmap</OPTION></TERM>
<LISTITEM><PARA>
On some systems with good <FUNCTION>mmap</>(2) with
``<CONSTANT>MAP_FILE|MAP_SHARED</>,'' and well behaving
<FUNCTION>munmap</>()  it does make sense to replace
<FUNCTION>read</>()/<FUNCTION>write</>() thru a file-descriptor to
the file with <FUNCTION>mmap</>() &mdash; however that requires
<FUNCTION>munmap</>() not to scrub away in-mapped blocks any more actively,
than the buffer-cache works at <FUNCTION>read</>()/<FUNCTION>write</>() blocks.
</PARA>

<PARA>
This was default for a while, however most systems don't
have really well-behaved munmap()s :-/
(Perhaps IBM AIX is the only exception ?)
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-getpwnam-library="-L... -l..."</OPTION></TERM>
<LISTITEM><PARA>
Certain sites have expressed wishes to use their own libraries
to replace the standard getpwnam() (and possibly getpwuid())
routines.
These are used in router, scheduler, mailbox, hold, and vacation
programs.
</PARA>

<PARA>
These programs use getpwnam() libary call to look up various customer
usernames to whatever the system needs them for.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-generic-include="-I/..."</OPTION></TERM>
<LISTITEM><PARA>
This parameter allows ubiquitous ``<OPTION>-I/...</>'' options to be used
in all program compilations throughout the package.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY>
<TERM><OPTION>--with-whoson</OPTION></TERM>
<!-- <LISTITEM></LISTITEM></VARLISTENTRY><VARLISTENTRY> -->
<TERM><OPTION>--with-whoson="/dir/prefix"</OPTION></TERM>
<LISTITEM><PARA>
This does explicite integration with ``<APPLICATION>whoson</>'' server; see
the ``<FILENAME>whoson-*.tar.gz</>'' file in
the ``<FILENAME CLASS="DIRECTORY">contrib/</>'' subdirectory.
</PARA><PARA>
For ZMailer needs the library must support userids:
<ITEMIZEDLIST>
<LISTITEM><PARA>root</></>
<LISTITEM><PARA>daemon, or daemons</></>
<LISTITEM><PARA>nobody</></>
</ITEMIZEDLIST>
and whatever others your local system magic needs.
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST>

</SECT1>
</CHAPTER>

<CHAPTER><?dbhtml filename="zins-verification.html">
<TITLE>Verifying the System</TITLE>

<PARA>
FIXME! FIXME! <EMPHASIS> TO BE WRITTEN !</>
</PARA>

</CHAPTER>
</PART>
