The special notation
:include:
in the right-hand side
of an alias causes
sendmail
to read its list of recipients
from an external file.
For that directive to be recognized as special, any address that
begins with
:include:
must select the
local
delivery agent.
This is automatic with most configuration files but not with others.
If your configuration file does not automatically recognize the
:include:
directive, you will need to add a new rule
near the end of your rule set 0 (see
Section 29.6, "Rule Set 0"
). For example,
R:include:$* $@ $#local $: :include:$1
Beginning with V8.7
sendmail
,
any delivery agent for which the
F=:
flag (see
Section 30.8.7, F=:
)
is set can also process
:include:
files.
(Note that eliminating the
F=:
flag for all delivery agent definitions
in your configuration file will disable this feature entirely.)
The
:include:
directive is used in
aliases
(5) files like
this:
localname: :include:
/path
The expression
:include:
is literal. It must appear exactly
as shown, colons and all,
with no space between the colons and the "include."
As with any right-hand side of an alias, there may be
space between the alias colon and the lead colon of the
:include:
.
The
/path
is the full pathname of a file
containing a list of recipients. It follows
the
:include:
with intervening space allowed.
The
/path
should be a full pathname.
If it is a relative name (such as
../file
), it is relative
to the
sendmail
queue directory. For all but V8
sendmail
,
the
/path
must not be quoted.
If it is quoted, the quotation marks are interpreted
as part of the filename.
For V8
sendmail
, the
/path
may be quoted, and the quotation
marks are automatically stripped.
If the
/path
cannot be opened for reading for any reason,
sendmail
prints the following warning and ignores any recipients that might
have been in the file:
:include:
path... Cannot open path
:
reason
Here,
reason
is "no such file or directory," "permission
denied," or something similar. If
/path
exists and can be
read,
sendmail
reads it one line at a time. Empty lines are
ignored. Beginning with V8
sendmail
, lines that begin with
a
#
character are also ignored:
addr
# a comment
empty line is ignored
addr2
Each line in the
:include:
file is treated as a list
of one or more recipient addresses. Where there is more than
one, each should be separated from the others by commas.
addr1
addr2, addr3, addr4
The addresses may themselves be
aliases that appear to the left in the
aliases
file. They
may also be user addresses, program names, or filenames.
A
:include:
file may also contain additional
:include:
lists:
engineers
to an alias
biff, bill@otherhost
to two recipients
|"/etc/local/loglists thislist"
to a program alias
/usr/local/archive/thislist.hist
to a file
:include:/yet/another/file
from another file
Beginning with V8.7
sendmail
,
the
TimeOut.fileopen
option (see
Section 34.8.70, Timeout (r)
)
controls how long
sendmail
should wait for the open to
complete. This is useful when files are remotely mounted
as with
NFS
. This timeout encompasses both this open and
the security checks described next.
Note that the
NFS
file system must be soft mounted (or mounted with
the
intr
option) for this to work.
Beginning with V8,
sendmail
checks the file for security.
If the controlling user is
root
, all components of the path
leading to the file are also checked.
[2]
If the
suid
bit of
the file is set (telling
sendmail
to run as owner of the file),
sendmail
checks to be sure that the file is writable only
by the owner. If it is group- or world-writable,
sendmail
silently
ignores that
suid
bit.
When checking components of the path,
sendmail
will print the following
warning if it is running as
root
and if any component
of the path is group- or world-writable:
WARNING: writable directory
offending component
This process is described in greater detail under the
-d44
debugging switch (see
Section 37.5.159, -d44.4
), which can also be used to
observe this process.
After
sendmail
opens the
/path
for reading but
before it reads the file, it sets the controlling user
to be the owner of the file
(if one is not already set and provided that file ownership cannot be
given away with
chown
(1)
).
The controlling
user provides the
uid
and
gid
identities of the sender when delivering
mail from the queue (see
Section 23.9.2, C line
).
The
:include:
file can neither deliver through programs nor append to files
if any of three situations is true:
if the owner of the
:include:
file has a shell that is not
listed in
/etc/shells
(see
Section 22.8.4, "The /etc/shells file"
),
if the
:include:
file is world-writable,
or if the
:include:
file is group-writable and the
UnsafeGroupWrites
option (see
Section 34.8.73, UnsafeGroupWrites
) is true.
IDA and V8
sendmail
allow comments
in
:include:
files. Comment lines begin
with a
#
character. If the
#
doesn't begin the line,
it is treated as the beginning of an address, thus allowing valid usernames
that begin with a
#
(such as
#1user
) to
appear first in a line by prefixing them with a space:
# Management
a comment
frida
george@wash.dc.gov
# Staff
a comment
ben
steve
#1user
an address
Note that since comments and empty lines are ignored by
sendmail
,
they can be used to create attractive, well-documented mailing lists.
Under older versions of
sendmail
, comments can be
emulated through the use of RFC822-style comments:
( comment )
By surrounding the
comment
in parentheses, you cause
sendmail
to view it and the parentheses as an RFC-style comment
and ignore them:
( Management )
frida
george@wash.dc.gov
( Staff )
ben
steve
This form of comment works with both the old and new
sendmail
programs.
As has been noted, the
aliases
file
should be writable only by
root
for security reasons.
Therefore, ordinary
users, such as nonprivileged department heads, cannot use the
aliases
file to create and manage mailing lists.
Fortunately,
:include:
files allow ordinary users
(or groups of users) to maintain mailing lists. This offloads
a great deal of work from the system administrator, who
would otherwise have to manage these lists, and
gives users a sense of participation in the system.
Unfortunately, reading
:include:
lists is slower than
reading an entry from the
aliases
database. At busy sites
or sites with numerous mail messages addressed to mailing lists, this
difference in speed can become significant. Note that the
-bv
command-line switch (see
Section 36.7.13, -bv
)
can be used with
sendmail
to time
and contrast the two different forms of lists.
On the other hand, sometimes rebuilding the
aliases
(5) database
can also be very slow. In such instances the
:include:
file may be faster, since it doesn't require a rebuild each time it changes.
One possible disadvantage to all types of mailing lists is that they are visible
to the outside world. This means that anyone in the world can
send mail to a local list that is intended for internal use.
Many lists are intended for
both internal and external use. One such list might be one for
discussion of the O'Reilly Nutshell Handbooks, called, say,
nuts@ora.com
. Anyone inside
ora.com
and anyone in the outside world
can send mail messages to this list, and those messages will
be forwarded to everyone on the
nuts
mailing list.