README.SENDMAIL

Information for Sendmail users

Overview:

Majordomo2 can generate the necessary Sendmail aliases required to run a
list by itself.  It can also maintain alias files for each domain run at
your site and generate the necessary virtusertable files required to run
the lists in separate virtual domains.  It will not, however, modify your
master alias file, nor will it make the necessary changes to your
sendmail.cf or sendmail.mc files to enable the additional alias and virtuser
files required.

When Makefile.PL is run, you will be prompted for what MTA you are running
and (assuming it's Sendmail) whether or not you want Majordomo to maintain
the alias files for you and whether or not you want virtusertable entries
maintained as well.

If you don't want Mj2 maintaining the files itself then it will simply
suggest aliases and do nothing to collect them.  Otherwise they will be
accumulated in a directory called 'ALIASES' in files named after the domain
being served.  Appropriate permissions will be used to satisfy the picky
nature of recent versions of Sendmail, but some Sendmail versions are so
picky that this is not sufficient, so Mj2 can make root-owned symbolic links
on an appropriate place of your choosing to get around this.

Note that you can use the generated alias and virtuser files as guides;
they are perfectly useful as cut-and-paste material even if you do not make
the necessary sendmail.cf changes to enable them.


Makefile.PL Questions Explained:

Should Majordomo maintain your aliases automatically?

Answering 'no' will cause Mj2 to suggest aliases but not do anything with
them.  You will be responsible for pasting these aliases into the
appropriate file and rebuilding the alias database.

Answering 'yes' will cause Mj2 to accumulate the aliases in a directory
called ALIASES under the list directory.


Should Majordomo maintain VirtUserTable files as well?

If you are using the VirtUserTable function of sendmail to support virtual
domains, Majordomo can generate special aliases and the necessary VUT
entries to go with them.  Answer 'yes' to this question if you are running
virtual domains and want VUT support; otherwise answer 'no' and Mj2 will
generate aliases appropriate for a single domain.

If you answer 'yes', Majordomo will generate aliases that include the
domain name in each address, like so:

majordomo-your.site.com: "|/path/to/mj_email -options"

The corresponding virtusertable entry will map majordomo@your.site.com to
this address appropriately:

majordomo@your.site.com		majordomo-your.site.com

Note that there will be one virtusertable file per domain.


Should Majordomo make links to alias and virtuser files?

Sendmail can be very picky about permissions.  Some versions of sendmail on
some systems will not allow alias files or virtuser files to be located in
a directory owned by the majordomo user.  Unfortunately this prevents
Majordomo from actually manipulating the files.  One workaround is to make
links from a root-owned directory (usually /etc/mail) to the
majordomo-owned directory.  Answering 'yes' to this question will cause the
installer to set up symbolic links from a directory of your choice to the
majordomo-maintained files.

You only need to answer 'yes' if you have found that rebuilding the
Majordomo-created alias databases fails with some form of permission
problem.  Even answering 'yes' may not solve the problem; this is only a
hack that is known to work in some circumstances.

Where should Majordomo place the symbolic links to alias and virtuser files?

Choose the directory in which to place the symbolic links you requested in
the previous question.  This should probably be /etc/mail if it exists, or
/etc or some other pre-existing root-owned directory that Sendmail is happy
with.



Configuring Sendmail:

There are two basic ways these sendmail.cf changes are made: through the M4
configuration files or by editing sendmail.cf directly.


Alias files:

If you use the M4 files, add a line like the following:

define(`ALIAS_FILE',`/etc/mail/aliases,/path/to/lists/ALIASES/domain1,/path/to/lists/ALIASES/domain2')

Substituting "/path/to/lists", "domain1" and "domain2" with the appropriate
path to the ALIASES directory or the place where you requested that
appropriate symlinks be made, and the appropriate domain names,
respectively.  Then rebuild and install the resulting cf file.

If you modify sendmail.cf directly, look for a line like:

O AliasFile=/etc/mail/aliases

And add the appropriate paths on the end:

O AliasFile=/etc/mail/aliases,/path/to/lists/ALIASES/mj-alias-domain1,/path/to/lists/ALIASES/mj-alias-domain2

again making the appropriate substitutions.

Note that currently you must rebuild these using newaliases yourself;
Newer versions of Sendmail have no facility to automatically rebuild these
files, due to security concerns.  You may want to do it from cron.
Eventually some way of having Majordomo call newaliases may be
incorporated.



VirtUser (VUT) files:

You should already have a line in sendmail.cf like

Kvirtuser dbm -o /etc/virtusertable

or if you use M4 files, something like

FEATURE(virtusertable, dbm -o /etc/mail/virtusers)

in your .mc file.  What you want to do is add various other virtuser maps
that are searched in addition to this.  In sendmail.cf, you want something like:

Kvirtuser0 dbm -o /etc/virtusertable
Kvirtuser1 dbm -o /path/to/lists/ALIASES/mj-vut-domain1
Kvirtuser2 dbm -o /path/to/lists/ALIASES/mj-vut-domain2
Kvirtuser sequence virtuser0 virtuser1 virtuser2

which creates three separate maps, then chains them together to form the
final virtuser map.

To do this with the M4 config, you need a line like:

FEATURE(virtusertable)

and then, at the very end of the .mc file, use a LOCAL_CONFIG section to
add some code verbatim into the .mc file:

LOCAL_CONFIG
#
# Add additional virtusertable files
#
Kvirtuser0 dbm -o /etc/virtusertable
Kvirtuser1 dbm -o /path/to/lists/ALIASES/mj-vut-domain1
Kvirtuser2 dbm -o /path/to/lists/ALIASES/mj-vut-domain2
Kvirtuser sequence virtuser0 virtuser1 virtuser2

Note that currently you must rebuild these using makemap yourself; Sendmail
has no facility to automatically rebuild these files.  You may want to do
it from cron.  Eventually some way of having Majordomo call makemap may be
incorporated.


Finally, a note about locking.  There is no locking between Sendmail and
Majordomo when it comes to modifying the alias and VUT files.  This means
that it is possible for Sendmail to rebuild the databases while Majordomo
is modifying one of the files.  These files change rarely and info is added
in a single write call so the changes are slim but still nonzero that an
incomplete build of the alias and VUT databases will result.  It may be
worthwhile to call newaliases from crontab occasionally to make sure that
things can't stay in an inconsistent state for long.


Performance tuning:

For large lists you may find that the connection between Majordomo
and sendmail appears to hang.  In this case you will see entries
like the following in the mail log:

    Jan  4 16:53:19 snagglepuss sm-mta[22238]: g04NpIjX015520: timeout
    waiting for input from local during Draining Input

The reason for this is that sendmail will attempt to canonify the
hostnames of each address Majordomo submits to it, and this requires a
DNS lookup.  If the DNS server for a particular hostname is not
responding, Sendmail will stall the entire transaction until the DNS
lookup times out.  This can take five minutes or more, during which
nothing gets done.  Majordomo may even time out the transaction and log
a delivery failure for the address.

The simplest way to solve this is to have Majordomo send its messages
to sendmail over a different port with hostname canonification
disabled.  Port 24 is reserved for private mail systems so that is
a good choice.  In sendmail 8.12 and higher you can include the
following in your .mc file.

    DAEMON_OPTIONS(`Name=MTA')
    DAEMON_OPTIONS(`address=localhost, Port=24, Name=NCMSA, M=EC')

This will cause sendmail to accept messages to the localhost address
on port 24 with canonification disabled in addition to accepting
messages normally on port 25.

To make Majordomo use the new port we need to modify the delivery_rules
setting.  The following example injects messages to port 24 on the
local host enables the esmtp and dsn options (since modern versions
of sendmail support these), and increases the default timeout.

configset DEFAULT delivery_rules <<ENDAAB
ALL
hosts=(localhost=(port=24, timeout=600, esmtp, dsn))
ENDAAB

You probably will want to do the same for the GLOBAL pseudo-list.

Both majordomo and sendmail (versions 8.12 and higher) have the
capability to split up messages with a large number of recipients
into multiple messages with a configurable maximum number of
recipients.  It is probably best to let sendmail do the splitting
if the version of sendmail you run supports this.  The following
line in a .mc file specifies up to 10 simultaneous queue runners
and splits messages into batches of up to 20 recipients.

QUEUE_GROUP(`mqueue', `P=/var/spool/mqueue, R=10, r=20, F=f')

If you are using multiple queue groups each group has its own 
options.


Other performance tweaks:

The HostStatusDirectory option can be used to keep host status
information in the queue so that the information is shared between
different sendmail processes.  To enable this, add the following to
your .mc file:

    define(`confHOST_STATUS_DIRECTORY', `.hoststat')dnl

and create a .hoststat directory in /var/spool/mqueue.  The default
timeout for the information in this directory is 30 minutes (which
should be reasonable for most installations).  You can change the
timeout with the Timeout.hoststatus variable.  In the .mc file this
is set like so:

    define(`confTO_HOSTSTATUS', `1h')dnl

If you have a very large backlog of messages in the mail queue, you
may wish to split things up a bit since most Unix filesystems perform
poorly when there are thousands of files in a single directory.
The simplest way to do that is to create df, qf, and xf directories
in /var/spool/mqueue.  You must do this while sendmail is not running
and you should move the existing df, qf, and xf files to the
corresponding directories.  It is also possible to use multiple
queues.  See the sendmail operator's guide for information.

Normally, sendmail starts a queue runner periodically (usually every
half hour or every hour) to process queued messages.  For very large
queues it can be useful to have persistent queue runners that are
always processing the queue, independent of the mail sendmail
process.  The following example starts 3 additional queue runners
that continuously processes the mail queue.  These do not interfere
with each other (or with other sendmail processes) since sendmail
locks each message before processing it.

    sendmail -OPidFile=/var/run/sendmail-q1.pid -L sm-queue -qp
    sendmail -OPidFile=/var/run/sendmail-q2.pid -L sm-queue -qp
    sendmail -OPidFile=/var/run/sendmail-q3.pid -L sm-queue -qp

Note that it is important to specify a different pid file for each one.

If your operating system has System V shared memory support and you
have compiled sendmail with SM_CONF_SHM defined you can use the
SharedMemoryKey option to keep free space information in a shared
memory segment so that each sendmail process does not have to check
for free disk space.  The following in the .mc file enables this:

    define(`confSHARED_MEMORY_KEY', `252525')dnl

The key is arbitrary (though it does need to be unique).
Note that the sendmail build process does not define SM_CONF_SHM by default.