Contents:
Internal Mailing Lists
:include: Mailing Lists
Defining a Mailing List Owner
Exploder Mailing Lists
Problems with Mailing Lists
Packages That Help
The User's ~/.forward File
Pitfalls
As was shown in the previous chapter, the sendmail program is
able to obtain its list of recipients from the aliases file.
It can also obtain lists of recipients from external files.
In this chapter we will examine the two forms that those
external files take: the :include:
form (accessed from the
aliases file) and the individual user's ~/.forward
file.
Since the chief use of the :include:
form of alias is to create
&mailing lists, we will first discuss mailing lists
in general, then their creation and management, and then the user's
~/.forward file.
A mailing list is the name of a single recipient that, when expanded by sendmail aliasing, becomes a list of many recipients. Mailing lists can be internal (in which all recipients are listed in the aliases file), external (in which all recipients are listed in external files), or a combination of the two. The list of recipients that forms a mailing list can include users, programs, and files.
An internal mailing list is simply an entry in the aliases file that has more than one recipient listed on the right-hand side. Consider, for example, the following aliases file entries:
admin: bob,jim,phil bob: \bob,/u/bob/admin/maillog
Here, the name admin
is actually the name of a mailing list,
because it expands to more than one recipient. Similarly, the
name bob
is a mailing list, because it expands to two
recipients. Since bob
is also included in the admin
list,
mail sent to that mailing
list will be alias-expanded
by sendmail to produce the following list
of recipients:
jim, phil, \bob, /u/bob/admin/maillog
This causes the mail message to be delivered to the local
users jim
and phil
in the normal way.
That is, each undergoes additional alias processing,
and the ~/.forward file of each is examined to
see whether either should be forwarded.
The recipient \bob
, on the other hand,
is delivered without any further aliasing because of the leading
backslash.
Finally, the message is appended to the file /u/bob/admin/maillog.
Internal mailing lists can become very complex as they strive to support the needs of large institutions. Examine the following simple, but revealing, example:
research: user1, user2 applications: user3, user4 admin: user5, user6 advertising: user7, user8 engineering: research, applications frontoffice: admin, advertising everyone: engineering, frontoffice
Only the first four aliases above expand to real usernames. The last three form mailing lists out of combinations of those four, the last being a superset that includes all users.
When the number of mailing lists is small and they don't change often, they can be effectively managed as part of the aliases file. But as their number and size grow, you should consider moving individual lists to external files. [1]
[1] Only root should be permitted to write to the aliases file. If you keep mailing lists inside that file, it may need to be writable by others. This can create a security breach (see Section 22.5.4, "Recommended Permissions").