The sendmail program offers over 70 options to choose from. We will cover a few here and the rest in Chapter 34. Recall that the purpose of our configuration file is to forward all mail to a central mail hub. In keeping with the simplicity of this task, you need to declare only those options shown in Table 13.1 (abstracted from Table 34.4 in Section 34.4, "Alphabetical Table of All Options").[2]
[2] For a description of the Type, leap ahead to Section 34.5, "Option Argument Types".
Option Name | Type | Description | |
---|---|---|---|
QueueDirectory (Q ) | String | Section 34.8.48, QueueDirectory (Q) | Location of queue directory |
Timeout (r ) | String | Section 34.8.70, Timeout (r) | Set timeouts |
DeliveryMode (d ) | Character | Section 34.8.16, DeliveryMode (d) | Set delivery mode |
TempFileMode (F ) | Octal | Section 34.8.68, TempFileMode (F) | Permissions for temporary files |
DefaultUser (u ) | String | Section 34.8.15, DefaultUser (g)(u) | Default delivery agent identity |
LogLevel (L ) | Numeric | Section 34.8.33, LogLevel (L) | Set (increase) logging level |
OldStyleHeaders(o ) | Boolean | Section 34.8.44, OldStyleHeaders (o) | Allow spaces in recipient lists |
BlankSub(B ) | Character | Section 34.8.5, BlankSub (B) | Unquoted space replacement |
We'll describe each of these required options briefly, add them to the client.cf file, and then test them.
We have already described queue directories (in Section 3.1.2, "The Queue Directory"). Queued mail always looks like authentic mail to sendmail. That is, the sendmail program trusts the mail it finds there, believing that only root placed it there. If the queue directory were world-writable (as /tmp is), anyone could create queued mail and thereby create forged mail messages. To help prevent forged mail, the queue directory should be writable only by root. Unfortunately, for the purpose of our exercises, this would prevent you from sending mail using the client.cf file. You would need to be root, which isn't desirable and may not be possible.
Instead, we will temporarily declare the location of the queue directory to be /tmp. To help you to remember to change the client.cf file later, add a comment now showing the need to make the change and the correct path to use:
O QueueDirectory=/tmp # BEWARE: use /var/spool/mqueue upon release
Note that on some systems, /var
needs to be replaced with /usr
.
Mail is usually placed into the queue because it could not be transmitted
immediately. Periodically, sendmail attempts to retransmit
each queued message. If the message has not been delivered
after a reasonable interval, sendmail sends a warning to the sender,
informing the sender that the message has not yet been delivered
but that sendmail will continue
to try. After a longer interval in the queue,
messages that have not been successfully transmitted are bounced.
The Timeout
(r
) option is used to specify both intervals:
O Timeout.queuewarn=4h O Timeout.queuereturn=5d
The Timeout
(r
) option is special in that it takes a dot and a keyword
to tell it what to time out.
In the first case the keyword queuewarn
sets the warning interval.
In the second, the keyword queuereturn
sets the return (bounce) interval.
(The complete list of keywords that apply to the Timeout
option
is in Section 34.8.70.)
The Timeout
option is one that takes a time interval as its argument.
Here, 4h
represents four hours (if the message is undelivered
after four hours, warn the sender and continue to try) and
5d
represents five days (return the message to the
sender as bounced mail).
The letter
following the number in each specifies the units.
The queuereturn
, for example,
could have been represented like this:
O Timeout.queuereturn=120h
This tells sendmail to bounce queued mail after 120 hours, which is the same as five days.
Five days may seem like a long time. After all, the mail hub should always be up and always be accepting mail. But suppose the hub crashed on Friday evening and replacement parts weren't available until Thursday morning. In this situation, queued mail on all the clients would start bouncing before the hub was repaired.
In choosing a value for the Timeout
(r
) option's
queuereturn
keyword, take into account
the worst-case scenario you can imagine. If the hub has
same-day service, a value of 1d
might be enough. If the hub
has to be shipped out for repair, you may want to consider a value
such as 14d
(two weeks).
[3]
[3] You should also consider including MX records for the hub (see Section 21.3, "Set Up MX Records") so that mail will be sent to another server if the hub is down.
There are several modes in which the sendmail program can run. Each determines how sendmail interacts with the program that invoked it. For the client.cf file, you want the user's MUA to execute sendmail for message transmission but to give the appearance that the message was sent almost instantaneously. This prevents users from waiting for their prompt to return whenever the mail hub is busy.
The delivery mode to use is called background because
it causes sendmail to accept a message and then run
in the background (thus allowing the MUA to continue on).
The delivery mode is set with the DeliveryMode
(d
) option:
O DeliveryMode=background
Note that sendmail recognizes only the b
of background
.
So you will sometimes find this same declaration in other configuration files more succinctly
expressed like this:
O DeliveryMode=b
Other possible values for the DeliveryMode
(d
) option are documented in
Section 34.8.16.
The sendmail program frequently needs to create new files
(such as files in its queue).
The file permissions that are given to each created file are determined by
the value of the TempFileMode
(F
) option.
That value can range from 0600 (readable
and writable only by sendmail) to 0666 (readable and writable
by anyone in the world). For security, we'll select
the first value - the most restrictive:
O TempFileMode=0600
Note that the value must be expressed in octal notation. (See chmod(1)
for details.)
The TempFileMode
(F
) option is further documented in Section 34.8.68.
Again, for security, sendmail tries to avoid running as root
whenever possible. When delivering failed mail to your ~/dead.letter
file, for example, it runs as you. If it finds itself in a situation
in which it must not be root but cannot otherwise decide on a real
user's identity, sendmail assumes the identity of the user
defined by the DefaultUser
(u
) option:
O DefaultUser=1:1
The uid under which to run (the number to the left of the colon) is here defined to be 1 (for the user daemon). The gid under which to run (the number to the right of the colon) is here defined as 1 (for the group daemon).
The values given to these options may also be names:
O DefaultUser=daemon:daemon
At security-conscious sites these are often set to
the user nobody and the group nogroup.
The DefaultUser
(u
) option is further documented in Section 34.8.15.
Recall that the DeliveryMode
(d
) option
told sendmail to run in the background.
Because it is running in the background,
sendmail should not print information about its
activities to your screen. On the other hand, you do want to
record information about its activities to help solve future
problems.
The method used by sendmail to record its activities is called logging.
[4]
The setting of the LogLevel
(L
) option allows you to turn logging
completely off or to specify a logging level. The higher the
logging level, the more detailed the information that is logged. That is,
low levels
log only serious problems, middle levels also log statistical
information, and high levels include debugging information.
[4] The actual mechanism used is called syslog(3) and is described in Chapter 26, Logging and Statistics.
O LogLevel=9
Here, we've chosen a level of 9. This is a middle level, which, in addition to causing serious problems to be logged, also causes statistics such as message size to be logged.
Typically, logged information is written by the system into
a file called syslog by a means documented in Section 26.1, "Logging with syslog".
The LogLevel
(L
) option is further documented in Section 34.8.33.
The current standard for specifying multiple recipients is to separate each address from the others with commas. Unfortunately, this has not always been the standard; old software may still exist that separates addresses with spaces:
abe,george,andrew new style abe george andrew old style
To prevent old software from breaking, you need to tell sendmail
that the use of spaces is acceptable and that if it finds such old-style lists,
it should replace the
spaces with commas. You tell sendmail
this by specifying the OldStyleHeaders
(o
) option:
O OldStyleHeaders=True
The value is either
true (accept and convert) or false (don't accept). The True
makes it true. In actual practice, only the first letter is recognized, and
either T
or t
will work. To turn it off,
use F
or f
(for false) or omit the entire
declaration. If you omit the true or false but include the option,
it defaults to true.
The OldStyleHeaders
(o
) option is further documented in Section 34.8.44.
Recall from Chapter 8, Addresses and Rules, that any address can be split up into tokens in the workspace. The address is then rewritten according to rules specified in rule sets. After all the tokens have been (possibly) rewritten, they are rejoined to form an address again.
The BlankSub
(B
) option exists for those times when two adjoining
tokens are just words (rather than a word and a separating character).
For example, suppose the workspace began by containing the
following tokens:
a @ b . c
Then suppose some rule always changed the last two tokens into
the single word LOCAL
. The result of rewriting would
look like this:
a @ b LOCAL
Here we have four tokens, the last two of which are text. The question becomes: What do we insert between them? Unless you tell sendmail to do otherwise, it always sticks a space between them. Therefore the default is to join these tokens together into this:
a@b LOCAL
Because we set the OldStyleHeaders
(o
) option above to true,
this single (but odd) address wrongly becomes two:
a@b, LOCAL
To prevent this kind of mishap, we use the BlankSub
(B
) option to
change the replacement character from a space to a dot:
O BlankSub=. # Replace unquoted spaces with a dot.
With this declaration in the configuration file the previous tokens are joined together like this:
a@b.LOCAL
This forms a single address, which is what is wanted. But what does the "unquoted" in the comment mean?
When parts of an address are surrounded in full quotation marks, those parts are viewed by sendmail as a single token. Therefore an address like this:
"abe lincoln"@wash.dc.gov
is tokenized like this:
"abe lincoln" @ wash . dc . gov
When these tokens are joined back together, the quoted words
abe
and lincoln
are viewed by sendmail as one
token (with a space included), rather than two (with need
of a space replacement character).
[5]
The BlankSub
(B
) option is further documented in Section 34.8.5.
[5] Actually, the address is sent as is to another site. The
BlankSub
(B
) option at the other site causes the confusion, because the address arrives there unquoted.