By Paul Dunne
Read on to learn how to use Linux to serve the mail
transport needs of your organization.
Questions regarding this article should be directed to the
author at
paul@tiny1.demon.co.uk
This article builds on my two earlier articles on installing
Linux and configuring Linux for Internet access, listed
here:
In this article, we will cover setting up a Linux machine to
act as a mail hub for the local network, allowing workstations to
send and receive Internet mail without themselves being directly
connected to the outside world. You should already know how to
install Linux and connect a Linux machine to the Internet: previous
articles in this series have examined these issues.
Although Sendmail comes ready built with almost any Linux
distribution you care to name, there are advantages to knowing how to
``roll your own.'' A widely-used, important program such as Sendmail
inevitably attracts a lot of attention from crackers. Updates to
the program incorporating fixes for the latest security holes are
regularly being made available. These updates are available as
patches against the source code, so you need the source if you
want to keep up. To provide the optimum degree of security for
your site, down-load the Sendmail source from a reputab
le site,
then configure, compile and install Sendmail yourself,
There is a
Sendmail
Web page
(<URL:http://www.sendmail.org/>), and many sites
mirror the source code from there.
Extract the source into a directory -- /usr/src/sendmail-x.x.xx
-- and change into the
/src
directory therein. In
there is a
makesendmail
shell script that will do
all the work for you. It is easiest to do the configuration in
the source directory, before actually installing the binary and
configuration files.
Tackling the Sendmail configuration process from scratch is
tough, no two ways about it. The main configuration file,
sendmail.cf
, is designed to be easy for the Sendmail
program to read and parse; therefore, it appears somewhat
inscrutable to humans. Fortunately, it is a task that rarely has
to be done from
the beginning.
The Sendmail distribution includes several sample
sendmail.cf
files, one or other of which can be
adapted to most configurations with a few changes; and any modern
Linux distribution will also include these in its Sendmail
installation.
Version 8 Sendmail has introduced an important simplification into
the configuration process, by shifting the user intervention from
direct editing of the Sendmail configuration file to making changes
to files of
m4(1)
macros, which is easier
and more intuitive. I consider use of the m4 macros in this section,
whereas the section on configuring a Sendmail client that connects
to our mail hub will deal with the
/etc/sendmail.cf
file directly, as that process is sufficiently simple to be easily
accomplished without the aid of the m4 macros.
The Sendmail configuration apparatus is in the
cf/
subdirectory. T
he structure of this
subdirectory is as follows:
[
Editor's note:
Thus, the first subdirectory listed
below is
cf/m4
, the second
cf/cf
,
and so forth.]
m4/
- This contains support routines, which should not be changed.
cf/
- The configuration files themselves. They have ``.mc''
suffixes, and must be run through the Unix
m4
program to become usable. The resulting output should have a
``.cf'' suffix.
ostype/
- Definitions describing a particular operating system type.
These should always be referenced using the OSTYPE macro in the
``.mc'' file.
domain/
- Definitions describing a particular domain, referenced using
the DOMAIN macro in the ``.mc'' file.
mailer/
- Descriptions of mailers, referenced using the MAILER macro in
the ``.mc'' file.
sh/
- Shell files used when building
the ``.cf'' file from the
``.mc'' file in the
cf/
subdirectory.
feature/
- These hold special features that you might want to include.
They should be referenced using the FEATURE macro.
hack/
- Local hacks from Berkeley (the home of Sendmail), of no more
than voyeuristic interest, if that.
siteconfig/
- Site configuration -- for instance, tables of locally
connected UUCP sites.
The base ``.mc'' file forms the starting point for m4
directives that invoke other macro files. All of the definitions
in our base ``.mc'' file in turn reference other ``.mc files.
Thus, order is important: follow that given here.
VERSIONID(`@(#)unixworld-online.mc 8.5 (Virtual Reality, Maan) 19/8/97')
OSTYPE(linux)
FEATURE(nouucp)
MAILER(local)
MAILER(smtp)
In what follows, I shall simply explicate what I have done
here. For the full in
formation, see the README file in the
cf/
subdirectory. There is also a good explanation
in a previous
UnixWorld Online Sendmail tutorial
.
The first line is for housekeeping, and puts the version line
into the output file so you can keep track of changes.
OSTYPE
The first macro defines our operating system. You
must
define an operating system environment, or the
configuration file build will not work. For us, the OS is Linux,
so we use the file in the
ostype
directory named
linux.mc
. This contains such things as default file
locations and other OS-specific material. You shouldn't need to
change it.
FEATURE
- nouucp
- The only feature we use is nouucp, which says, don't do
anything special with UUCP addresses at all.
- nullclient
- This feature could be used to do what we will do later on by
hand, that is, generate a stripped-do
wn configuration file that
does noting but forward all mail to a central hub via a local
SMTP-based network. The argument is the name of that hub.
MAILER
The MAILER macros use macro files to specify rules to handle
one or more mailers. Here, we invoke definitions for a local
mailer and an SMTP mailer. As a general rule, put the MAILER
definitions last in your
.mc
file, and always put
MAILER(smtp) before MAILER(uucp) -- several features and
definitions will modify the definition of mailers, and the SMTP
mailer modifies the UUCP mailer.
- local
- The local and prog mailers. You will almost always need these;
the only exception is if you relay ALL your mail to another site.
This mailer is included automatically.
- smtp
- The Simple Mail Transport Protocol mailer. This does not hide
hosts behind a gateway or another other such hack; it assumes a
world where everyone is running a name server. This file
actually defines four
mailers:
smtp
for regular (old-style)
SMTP to other servers,
esmtp
for extended SMTP to other
servers,
smtp8
to do SMTP to other servers without convertin
g
8-bit data to MIME (essentially, you are saying here that you
know the other end is 8-bit clean even if it doesn't say so), and
relay
for transmission to our RELAY_HOST, LUSER_RELAY, or
MAILER_HUB.
The final Sendmail configuration file is produced by invoking
m4 with the
.mc
file specified above as its argument.
The command line looks like this:
m4 ../m4/cf.m4 config.mc > config.cf
Where
cf.m4
-- in
../m4
relative to
the current directory -- is a general set of macro definitions
that is always required,
config.mc
is the macro file
we've developed above, and
config.cf
the output, the
Sendmail configur
ation file, which will be installed as
/etc/sendmail.cf
.
After you complete the configuration, as root type ``pmake
install'' to install the new Sendmail program. (Note: that's pmake,
to use the 4.4BSD make,
not
the GNU make which Linux uses).
Of course, you should back up your old program first in case you need
to ``back off'' and return to it. The files installed include:
/usr/sbin/sendmail
- This is the actual Sendmail program binary. There may be a
symbolic link in Sendmail's historic location,
/usr/lib
, pointing here, but
/usr/sbin/
is now the actual directory location.
/etc/sendmail.cf
- This is the configuration file that we generated.
/usr/bin/newaliases
- This is another symbolic link to
/usr/sbin/sendmail
. When invoked by this name,
Sendmail will rebuild the aliases database.
/var/spool/mqueue
- This is the directory, where incoming and outgoing mail
is kept awaiting delivery. It should have mode 700, to prevent
inquisitive users from peeking at other users' mail.
/etc/aliases
- This is the systemwide aliases file.
/usr/lib/sendmail.hf
- This is the help file for Sendmail.
/etc/sendmail.st
- This optional file can be used by Sendmail to record statistics.
/usr/bin/mailq
- This is also a symbolic link to
/usr/sbin/sendmail
. When invoked under this name,
Sendmail prints the contents of the mail queue.
You will most likely want to have the Sendmail daemon started
every time the machine boots up. In Slackware, this is done by
adding a line to the appropriate ``rc'' file in the
/etc/rc.d
directory. The Slackware insta
ll
procedure puts this in
/etc/rc.d/rc.M
.
The code should look like this:
if [ -x /usr/sbin/sendmail ]
echo "sendmail "
/usr/sbin/sendmail -bd -q1h
fi
This checks to see if the file is executable, then tells the
system console that it's about to invoke Sendmail, invokes
Sendmail in daemon mode (
-bd
), and sets it to
process the mail queue every hour (
-q1h
).
The mail queue lives in the
/var/spool/mqueue
directory, by default. All mail messages are held as two files,
one named
df
XXXnnnnn
, the other
qf
XXXnnnnn
, where
XXX
is a
three-letter sequence,
nnnnn
a five-digit sequence,
both used simply to give every message a unique identifier. The
``qf'' or queue control file contains the e-mail message header
and various processing information, whereas the ``df'' or data
file contains the body of
the e-mail message. There are other
files, but they are transient and usually of interest only to
Sendmail.
Sendmail uses the Unix
syslogd(8)
facility. Usually, this is set up to
log all Sendmail transactions to
/var/log/maillog
,
by default.
Sendmail has a reputation as a security nightmare, but this is
largely undeserved, particularly with Version 8, which has solved
a lot of the problems that plagued previous versions. Actually,
the degree of Sendmail security is largely the responsibility of
the system administrator (you!). Some specific points to watch
for:
- Make sure the
aliases
file isn't writable except by
trusted system personnel. This includes both the text and
database version.
- Make sure that other files that Sendmail reads, such as the
mailertable, are only writable by trusted system personnel.
- The queue directory sh
ould definitely not be world writable.
In fact, opinions vary on the correct permissions for the mail queue.
One school of thought holds that 700 is the safest way; the other
that 711 is permissible, allowing the queue to be searched by a
Sendmail process that has relinquised its root privileges. Use 700
to be on the safe side; it will always be possible to relax this
slightly should it cause problems.
Providing e-mail service to other machines in the network can
be done in two ways. The first is to use SMTP to act as a ``mail
hub'' that sends and receives internal network (and optionally local)
mail on behalf of the other machines. Secondly, a POP service can
be set up, where local users use client software on their computers
to collect their mail via the POP3 protocol, and send mail via SMTP
to the server.
Users on the local network must be identifiable by the Sendmail
process running on
the server machine. In the case of POP mailboxes,
this is done by creating a normal user account. In the case of Linux
clients collecting mail through Sendmail themselves, this is done
by adding the appropriate alias to
/etc/aliases
. For
example, on my local network, any mail arriving at my mail server
(tiny1.demon.co.uk) destined for user
bob
is sent on to
bob@donner.example.com on my internal network by the following line
in
/etc/aliases
:
bob: bob@donner.example.com
The simplest way to make sure that mail comes back to the
right place is to set the
Reply-To
header in all
outgoing mail to point to the account on the mail-hub system, not
the originating machine. This can be done in the options
settings of your POP3 mailer, or will be handled for you by
Sendmail on a Linux client.
It's recommended to have the mail-hub use the Sendmail
``masquerade'' feature, so that the headers of mail messages
originating from your priv
ate network are rewritten to look as
though they came from the hub.
First, we turn on masquerading:
MASQUERADE_AS(mailhub.example.com)
where
mailhub.example.com
is the name by which
your mail-hub is known on the Internet.
Normally, the only addresses that are masqueraded are those
that come from this host. In our situation, that doesn't do a
lot of good, as it's mail from other local hosts we want altered
by the mail-hub
to make it look as though the mail-hub
sent it. We do this with the line:
MASQUERADE_DOMAIN(otherhost.example.com)
which has the effect that any mail from
otherhost.example.com
will, when relayed, be
rewritten to have the MASQUERADE_AS address. This can be a
space-separated list of names, or you can keep the list in a
file, in which case the line to use in the ``.mc'' file is:
MASQUERADE_DOMAIN_FILE(filename)
There are two ways o
f handling the configuration for a Sendmail
client that merely routes all outbound mail to a mail-hub.
One can use the m4 configuration process, as described above for
the mail-hub, and I'll run through that here.
The ``.mc'' file is simple, just:
divert(0)dnl
VERSIONID(`@(#)dumbclient.mc 28/10/97')
OSTYPE(linux)
FEATURE(nullclient, mailhost)
Where
mailhost
is the fully qualified domain
name of the mail-hub to which all mail is to be forwarded.
This case is simple enough that the
/etc/sendmail.cf
file is not so arcane as it can be, so it is worth taking the
opportunity to examine it in detail.
There isn't the space for a full run-down on the syntax of the
file. For the full story, consult the irreplaceable
Sendmail
book, published by
O'Reilly & Associates
,
available at a discount from
Amazon books
.
The file is divided into sections, not for
Sendmail, but to make it easier for humans to maintain (and
explain).
Sendmail ``commands'' are usually one-letter in length, and
must be at the beginning of a line. Generally, there is no
whitespace between a command letter and its arguments.
The first part, Macros, shows variables (known as ``macros''
in Sendmail parlance) defined by use of the ``D'' (Define Macro),
command. All the macros defined here are explained by comments
on the line preceding them -- a wise practice that should not be
confined to example files!
### Defined Macros (1)
# The name of the mail hub
DRwotan.example.com
# The hub as it is known to the outside world
DHtiny1.demon.co.uk
# The local official domain name
Dj$w
# Our domain name
DDexample.com
# Identity of the error message sender
DnMailer-Daemon
# Look of the Unix From line
DlFrom $g $d
# The characters that separate address components
Do.:%@!^=/[]
# Default form for the sender's a
ddress
Dq<$g>
The second section, Classes, is for a special type of
variable, a class, which can hold multiple values. The command
letter here is ``C''. The class we define in this example is
w
, which holds a list of alternative host names for
the machine (that is, other than the fully-qualified domain name,
or FQDN).
### Defined Classes (2)
# All possible names for local machine
Cw localhost donner
The third section specifies Sendmail options. These can be
provided on the command line used to invoke Sendmail, but because
they are so numerous, it makes more sense to specify them in the
configuration file.
# default delivery mode (in background)
Odbackground
# temporary file permissions---0600 for secure mail
OF0600
# default UID & GID
Ou1
Og1
# level at which to syslog errors
OL9
# Wait for SMTP replies.
Or1h
# default messages to old style
OoTrue
# Replace unquoted spaces with a dot
OB.
The fourth part specifies the headers that must
appear in
every mail message. These are the headers that Sendmail will add
if the mail user agent (MUA) has not already done so.
### Header Declarations (4)
HFrom: $q
HReceived: by $j id $i; $b
H?x?Full-Name: $?x$x$.
H?D?Date: $a
H?M?Message-Id: <$t.$i@$j>
The fifth section is a set of priority settings. Sendmail
will process the mail in its queue in order of decreasing
priority, beginning with ``special-delivery''. The level of
priority is set by the MUA with the Precedence: header line.
### Priorities (5)
Pspecial-delivery=100
Pfirst-class=0
Plist=-30
Pbulk=-60
Pjunk=-100
The sixth section defines a set of mailers that Sendmail will
use to actually deliver mail. Sendmail is a
mail transport
agent
, it doesn't deliver the message itself. These lines
all begin with a capital ``M''. The ``local'' and ``prog''
mailers are mandatory. The real work here is done by the special
mailer [IPC], which invokes internal Sendmail routines rather
than an exter
nal mailer program, to send all mail to a ``smart
host'' using SMTP.
### Mailer Delivery Agent Definitions (6)
# Mailer to forward all mail to the hub machine
Mhub, P=[IPC], S=10, R=0, F=xmDFMuCX, A=IPC $h
# Sendmail requires these, but we won't use them
Mlocal, P=/bin/mail, S=0, R=0, F=lsDFMShP, A=deliver $u
Mprog, P=/bin/sh, S=0, R=0, F=lsDFMeu, A=sh -c $u
The seventh and last section is the heart of Sendmail, the
rule sets. These define the re-writing of addresses. The basic
idea here is that there are two sides, a left-hand side (LHS) and a
right-hand side (RHS). The LHS represents a pattern to match against
input, and the RHS is the transformation to effect upon the input
if a match is made. LHS and RHS are separated by tabs; comments
are in the third column. You can learn more about these rules from
this
tutorial
article
.
### The Rules Sets (7)
S0 select delivery agent
R@$+ $#error $: Missing user name
R$+ $#
hub $@$R $:$1 forward to hub
<p>
S3 preprocessing for all rule sets
R$*<>$* $n handle <> error addresses
R$*<$*<$*>$*>$* $2<$3>$4 de-nest brackets
R$*<$*>$* $2 basic RFC822 parsing
S10 rewrite the sender for the hub
R$- $@$1@$H user -> user@hub
R$-@$w $@$1@$H user@local -> user@hub
R$-@$=w $@$1@$H user@othernames -> user@hub
R$-@$=w.$D $@$1@$H user@domain -> user@hub
S1 dummy ruleset 1 (unused)
For more information on the Sendmail
configuration files and their customization see our
Sendmail
tutorial article
.
Collecting e-mail from the mail-hub from a Windows box is a
simple matter of using the POP3 protocol to collect the mail from
a POP3 server, which grabs mail from the standard Unix mail spool,
/var/spool/mail
. A POP service should be installed
as part of your standard Linux set-up. If its not, then use
pkgtool
or whatever to install it from the CD.
The entry in
/etc/services
should be as follows:
pop-2 109/tcp # PostOffice V.2
pop-3 110/tcp # PostOffice V.3
The service will be started automatically by
inetd
when a service request is received. This
behavior is set up by the following lines in
/etc/inetd.conf
:
pop-2 stream tcp nowait root /sbin/tcpd /usr/sbin/in.pop3d
pop-3 stream tcp nowait root /sbin/tcpd /usr/sbin/in.pop3d
To use this approach, each mail account must be a ``real''
Unix account on the mail hub, not just an entry in
/etc/aliases
. It's best to make the account unusable
for log in by entering a
*
in the password field of
/etc/passwd
and specifying a bogus shell -- like
/bin/false
-- in the last field of the password file
entry.
I use Eudora Lite, which is a freeware, stripped-down version
of Eudora Pro. It is a fine e-mail client in its own ri
ght,
available from
Qualcomm
. Setting it up is
simply a matter of pointing it at the mail hub, telling it the
POP user name and password. One glitch I found was that not all
options are saved to the
EUDORA.INI
file.
Specifically, I had to set ``UseWinSock=1'' and ``UseDialup=0''
by editing the ``ini'' file, as changing these options from the
menu had no effect.
Thus, we now have a working mail hub, providing Internet e-mail
services to the local network.
Let's say you have an existing Sendmail installation, one that
``came free'' when you installed Linux. You don't want to go to
the bother of fussing about with getting the Sendmail source,
figuring out m4, and the rest. Well, while I can't hope to cover
all the details of the Sendmail configuration file syntax here, I
can tell you the minimum changes yo
u need to make to transform a
generic
sendmail.cf
into one you can use. Because
of the complexity of this file, I will list here only the things
one
has
to change.
In the section above on
configuring a
Linux client for the local network
, I have gone into more
detail, which should suffice to give you a general understanding
of the file syntax. Here, I will presume that there is already a
suitable
sendmail.cf
on the machine (provided either
by the Linux distribution, or from the Sendmail sources).
The ``w'' macro contains any other names that this host is
known by, besides the FQDN. So, if the machine is known to your
ISP as example1.com, say, but to your local network as
example2.com, you need to put example2.com here. You might as
well put ``localhost'' here, too.
Cwlocalhost example2.com
The ``S'' macro can contain the name of a smart relay host, to
which all non-local mail is forwarded without further ado.
Some
sites can deliver mail to the local network, but cannot look up
hosts on the Internet with DNS. To ensure delivery of all mail,
such sites need to forward all non-local mail to a smart (or
well-connected) host. For example, a customers of Demon, a UK
ISP, would use post.demon.co.uk here.
DSpost.demon.co.uk
If you are on the end of a SLIP or PPP link,
and you use a dial-on-demand system (controlled
by
diald(8)
, for example), you won't want Sendmail
to try to deliver mail straight-away, because that would keep the
link going up and down all the time, with a phenomenal inflationary
effect on your phone bill. To make Sendmail only attempt to deliver
mail when actually processing the queue, set the Delivery Mode
option to `deferred,'' as in:
O DeliveryMode=deferred
Those are all the changes you should need to make. The other
parameters changes how Sendmail behaves, but should wo
rk on your
site without modification.
Paul Dunne is a writer and consultant who specializes in
Linux. He has a
home page
that describes
in more detail what he does.
|
