Sendmail
From Software By Jeff
Setting up a new server and even upgrading an old one can be a little tough. The documentation is a little short on how to make a thorough installation that allows easy post-installation modification.
| Table of contents |
Downloading
Downloading is simple enough. Visit the sendmail (http://sendmail.org) home page, find the current stable release and download it.
Sendmail is also available on many LINUX distributions as a package that can easily be installed by point-and-click. We prefer getting software straight from the horse's mouth, if you please. As it happens, at this time, sendmail.com has v8.13.5 available, but the latest in SuSe's YaST is v8.13.3. Not a big difference, but they're two versions out; it'd be fair to expect them to upgrade to the next version, which would only make them one version out, but it may be the case that more would be released by sendmail.com.
Additionally, for the adventerous, there is the next version of sendmail available in beta from from sendmail.com. Use at your own risk.
Building
The archive from sendmail.com breaks out all of the tools that accompany sendmail into directories within their distribution. Unpack the archive you've downloaded using the appropriate tool. We chose the gzipped tar, so we simply do tar -xzf sendmail.8.13.5.tar.gz in the directory in which we want the archive unpacked. Of course, your version and path may vary.
In the uncompressed sendmail-8.13.5 directory is everything you need. The INSTALL document outlines the simple steps, but we feel there are a couple missing, so we'll outline it here.
There's a simple Build shell script that will compile everything for you. Of course, this assumes you've got your machine set up with a compiler (we use gcc). The Build script will go into each subdirectory and build the required libraries and executables for both sendmail and its helper tools. Simply run that with sh Build in that directory.
Then you need to configure the rules file. In the cf/cf subdirectory is a list of simple default .mc files. Find the one that matches your system, copy it to sendmail.mc in the cf/cf directory. Edit the file to match your desired bits of help.
This is the tricky part. Here's where you tell sendmail what features you want to use, what paramters to use for certain functions, and generally how to act. Your needs may vary, but here's how we configure ours, mostly:
OSTYPE(`solaris2')dnl
DOMAIN(`generic')dnl
define(`LOCAL_MAILER_FLAGS', LOCAL_MAILER_FLAGS`'P)dnl
define(`confCW_FILE', `-o /etc/mail/sendmail.cw')dnl
define(`confNO_RCPT_ACTION', `add-to-undisclosed')dnl
define(`confMAX_MIME_HEADER_LENGTH', `256/128')dnl
define(`confPID_FILE',`/etc/mail/sendmail.pid')dnl
FEATURE(`access_db',`dbm -T<TMPF> /etc/mail/access')
FEATURE(`always_add_domain')dnl
FEATURE(`dnsbl',`list.dsbl.org',`"550 Rejected " $&{client_addr} " found in list.dsbl.org"')dnl
FEATURE(`dnsbl',`sbl-xbl.spamhaus.org',`"550 Rejected " $&{client_addr} " found in sbl-xbl.spamhaus.org"')dnl
FEATURE(`dnsbl', `dnsbl.sorbs.net', `"550 Rejected " $&{client_addr} " found in dnsbl.sorbs.net"')dnl
FEATURE(`dnsbl', `relays.ordb.org', `"550 Rejected " $&{client_addr} " found in relays.ordb.org -- Due to sending server misconfiguration - see http://www.ordb.org/faq/\#why_rejected"')dnl
FEATURE(`dnsbl', `bl.spamcop.net', `"550 Rejected " $&{client_addr} " found in b1.spamcop.net -- Spam blocked see: http://spamcop.net/bl.shtml?"$&{client_addr}')dnl
FEATURE(`nouucp', `reject')dnl
FEATURE(`mailertable',`dbm /etc/mail/mailertable')dnl
FEATURE(`redirect')dnl
FEATURE(`virtusertable',`dbm /etc/mail/virtusers')dnl
FEATURE(`smrsh')
MAILER(`local')dnl
MAILER(`smtp')dnl
dnl
Some bits are kind of self-explanitory. The define lines simply set up some parameters that sendmail will use when executing. The FEATURE lines tell the configuration file to add some predefined scripts to the final configuration
We're not going to outline what these do; read the README in the cf directory for details. Read these details with each install, as some of the feature and definitions change, both in the name and paramters, and even in function.
The configuratin we use offers some protection from abuse, allows us to accept and send mail from multiple domains on one server, and allows us some facility to rename (alias) users and redirect mail (virtusers).
Our favorites are the dnsbl lines, which help set up the anti-spam. There are lists out there, and we may update this to include some details about it. We run every mail through five filters before giving up. These filters don't check the content of mail, simply the sending servers; if a server's been reported as allowing spam through it to one of these lists, our check will find out and not allow us to receive mail from those servers.
One line left out of this installation configuration allows the use of procmail (http://procmail.org), a strong mail processing program that allows users to configure some of their own post-acceptance mail handling, including the use of content-based anti-spam mechanisms such as SpamAssassin (http://spamassassin.apache.org). We've left it out of this discussion in order to streamline the sendmail topic.
In the cf directory (the parent to cf/cf) is another Build script. Run that by sh Build sendmail.cf.
After building the libraries and executables, and making the base configuration, you're ready to go.
Installing
The installation is where the process differs from the INSTALL file.
Upgrade Installation
If you're replacing an old installation of sendmail, back-up the information before you start. This is just common sense. It has been our fortune to have never needed to back out of an installation, but it's always good practice.
Something simple like the following should cover the bases. Either look at the previous installation's directories, or this installations directories to see what needs archiving. That is, because we are going to replace vacation we should archive the old one.
tar -cf sendmail.tar \
/etc/mail/* /usr/lib/mail/* \
/usr/lib/sendmail /usr/lib/smrsh \
/usr/sbin/makemap /usr/bin/mailstats \
/usr/bin/praliases /usr/bin/rmail \
/usr/bin/test /usr/bin/vacation
Your file locations may vary, but these are the defaults from the Build scripts.
Additionally, after you complete the installation below, remember to update any of the /etc/mail databases like aliases and virtusers with the new tools, to ensure they're compatible.
New Installation
If this is the first time you're installing sendmail on a server, there's just a few things you need to do to get set up. Most critically is to ensure that sendmail doesn't get the ability to run amok on your system.
Crete a new user and group named smmsp by whatever method makes sense for your system. The user smmsp should have its primary and only group be smmsp. Likewise, the group smmsp should have only one member, the smmsp user. It is recommended the group ID be 25, although it is unclear why; since it's easy to do, just do it.
Create a few directories for the mail to exist. For the most part, access can be limited to the root user and the super-user group appropriate for your system. Create the following directories if they don't exist.
/var/spool/clientmqueue
/var/spool/mqueue
/etc/mail
/var/mail
The /var/spool/clientmqueue should belong to the smmsp user and group, so give it a quick chown -R smmsp:smmsp /var/spool/clientmqueue. If you don't change these permissions, sendmail may complain or even fail to start.
Install
Then you can install by simply doing sh Build install in the sendmail source root directory to install the executables, and sh Build install-cf in the cf directory to install the configuration file.
The cf directory should also be copied to /usr/lib/mail to facilitate recreating the configuration files. If you don't do this, make sure to hold onto the sendmail source directory so you have access to the cf/cf directory. Simply cp -Rp cf /usr/lib/mail and you'll have all of the goods for later.
If you've done a new installation, create the following files.
cd /etc/mail
touch aliases
touch access
touch mailertable
touch virtusers
These are needed as they're named in our sendmail.mc file. Note even in an upgrade, the touch won't hurt anything.
Whether you're doing a new or updated installation, you need to make the databases that sendmail will use, even if the files are empty (as in after the creation above). The files named above are plain-text, but they need to be made into databases with the new version of makemap.
cd /etc/mail
newaliases
makemap dbm access < access
makemap dbm mailertable < mailertable
makemap dbm virtusers < virtusers
Note the newaliases is used to regenerate the aliases instead of makemap.
Startup Script
Curiously, a start-up script doesn't come with sendmail. The various documents in the sendmail source directories spread out the bits needed to start sendmail, including the various command line options. This script can be inserted in your /etc/init.d directory, and symlinked to start in your /etc/rc2.d directory, or whatever the directory name or structure your installation requires.
#!/sbin/sh
#
# Copyright (c) 1992 - 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)sendmail 1.19 01/12/05 SMI"
ERRMSG1='WARNING: /var/mail is NFS-mounted without setting actimeo=0,'
ERRMSG2='this can cause mailbox locking and access problems.'
SERVER_PID_FILE="/etc/mail/sendmail.pid"
CLIENT_PID_FILE="/var/spool/clientmqueue/sm-client.pid"
DEFAULT_FILE="/etc/default/sendmail"
ALIASES_FILE="/etc/mail/aliases"
check_queue_interval_syntax()
{
default="15m"
if [ $# -lt 1 ]; then
answer=$default
return
fi
if echo $1 | egrep '^([0-9]*[1-9][0-9]*[smhdw])+$' >/dev/null 2>&1; then
answer=$1
else
answer=$default
fi
}
case "$1" in
'restart')
[ -f $SERVER_PID_FILE ] && kill -1 `head -1 $SERVER_PID_FILE`
[ -f $CLIENT_PID_FILE ] && kill -1 `head -1 $CLIENT_PID_FILE`
;;
'start')
if [ -f /usr/lib/sendmail -a -f /etc/mail/sendmail.cf ]; then
if [ ! -d /var/spool/mqueue ]; then
/usr/bin/mkdir -m 0750 /var/spool/mqueue
/usr/bin/chown root:bin /var/spool/mqueue
fi
if [ ! -f $ALIASES_FILE.db ] && [ ! -f $ALIASES_FILE.dir ] \
&& [ ! -f $ALIASES_FILE.pag ]; then
/usr/sbin/newaliases
fi
MODE="-bd"
[ -f $DEFAULT_FILE ] && . $DEFAULT_FILE
#
# * MODE should be "-bd" or null (MODE= or MODE="") or
# left alone. Anything else and you're on your own.
# * QUEUEOPTION should be "p" or null (as above).
# * [CLIENT]QUEUEINTERVAL should be set to some legal value;
# sanity checks are done below.
# * [CLIENT]OPTIONS are catch-alls; set with care.
#
if [ -n "$QUEUEOPTION" -a "$QUEUEOPTION" != "p" ]; then
QUEUEOPTION=""
fi
if [ -z "$QUEUEOPTION" -o -n "$QUEUEINTERVAL" ]; then
check_queue_interval_syntax $QUEUEINTERVAL
QUEUEINTERVAL=$answer
fi
check_queue_interval_syntax $CLIENTQUEUEINTERVAL
CLIENTQUEUEINTERVAL=$answer
/usr/lib/sendmail $MODE -q$QUEUEOPTION$QUEUEINTERVAL $OPTIONS &
/usr/lib/sendmail -Ac -q$CLIENTQUEUEINTERVAL $CLIENTOPTIONS &
#
# ETRN_HOSTS should be of the form
# "s1:c1.1,c1.2 s2:c2.1 s3:c3.1,c3.2,c3.3"
# i.e., white-space separated groups of server:client where
# client can be one or more comma-separated names; N.B. that
# the :client part is optional; see etrn(1M) for details.
# server is the name of the server to prod; a mail queue run
# is requested for each client name. This is comparable to
# running "/usr/lib/sendmail -qRclient" on the host server.
#
# See RFC 1985 for more information.
#
for i in $ETRN_HOSTS; do
SERVER=`echo $i | /usr/bin/sed -e 's/:.*$//'`
CLIENTS=`echo $i | /usr/bin/sed -n -e 's/,/ /g' \
-e '/:/s/^.*://p'`
/usr/sbin/etrn $SERVER $CLIENTS >/dev/null 2>&1 &
done
fi
if /usr/bin/nawk 'BEGIN{s = 1}
$2 == "/var/mail" && $3 == "nfs" && $4 !~ /actimeo=0/ &&
$4 !~ /noac/{s = 0} END{exit s}' /etc/mnttab; then
/usr/bin/logger -p mail.crit "$ERRMSG1"
/usr/bin/logger -p mail.crit "$ERRMSG2"
fi
;;
'stop')
[ -f $SERVER_PID_FILE ] && kill `head -1 $SERVER_PID_FILE`
if [ -f $CLIENT_PID_FILE ]; then
kill `head -1 $CLIENT_PID_FILE`
rm -f $CLIENT_PID_FILE
fi
/usr/bin/pkill -x -u 0 sendmail
;;
*)
echo "Usage: $0 { start | stop | restart }"
exit 1
;;
esac
exit 0
This is the file from our server. We had to change the SERVER_PID_FILE variable to match the one outlined in our sendmail.cf file, but otherwise it's untouched.
Later we might replace this with our own.
Maintaining
The degree of difficulty in the maintenance of sendmail installations varies with the initial configuration, the options used, and the skill level of the maintainer.
Simply, the configuration file above requires very little in terms of maintenance. As new users are added to the machine, sendmail will automatically handle them. If the database files aliases or virtusers and the like are modified, simply rebuild the databases as above, and sendmail will recongize them.
If you replace sendmail with a new version, simply repeat the above.