Creating Mailing Lists

Add an entry to the aliases text file for each mailing list, where the alias field contains the name of the mailing list, and the recipient field contains a comma-separated list of all of the recipients of the mailing list.

Add the special alias that sendmail uses to deliver error messages concerning the mailing list. This special alias must have a name in the format of owner-list, where owner- is a required string and list is the name of the list for which this owner alias is being declared. For example, if the list is named admin, this alias must be named owner-admin. The recipient field of the special alias should contain the address where the errors are to be sent.

For the convenience of users, add an alias that can be used to reach the person who maintains the mailing list. The format of the alias field should be list-request, where list is the name of the list for which this request alias is being declared, and -request is a required string. For example, if the list is named admin, this alias should be named admin-request.

Run newaliases to rebuild the aliases database file:

# newaliases  /etc/mail/aliases: 43 aliases, longest 30 bytes, 592 bytes total

To illustrate how to create mailing lists, let’s assume we have been asked to create three different mailing lists:

  • Mail addressed to root is to be sent to the normal login accounts of the three people who administer the mail server.
  • The boss wants to have a mailing list for the management council, which is composed of the four department chiefs and their scientific advisor, and he wants an archive kept of all the mail sent to that mailing list.
  • The boss wants a mailing list for all mail users.

To do this, create an admin mailing list for the system administrators, a chiefs list for the department heads, and an employees mailing list for all mail users, similar to the following:

# Mailing lists
admin:          alana, logan, pat
owner-admin:    admin-request
admin-request:  alana
chiefs:         reba, sara,,, kathy,
owner-chiefs:   chiefs-request
chiefs-request: alana
employees:           :include:/etc/mail/allusers
owner-employees:     employees-request
employees-request:   alana

Next, edit any aliases in the file that need to reference the newly created aliases. In this example, we want mail addressed to root to be sent to the newly created admin alias so we make the following change:

# Person who should get root's mail  root:           admin

The first mailing list is the simplest. It defines three local recipients (alana, logan, and pat) who will receive copies of mail addressed to admin. The address admin can be used directly to reach these three users, as the following sendmail -bv command shows:

# sendmail -bv admin
pat... deliverable: mailer local, user pat
logan... deliverable: mailer local, user logan
alana... deliverable: mailer local, user alana

We also want mail addressed to root to be sent to the three administrators. To that end, we edited the aliases text file to point the root alias to the admin mailing list. Another sendmail -bv command illustrates the impact of that edit:

# sendmail -bv bin
pat... deliverable: mailer local, user pat
logan... deliverable: mailer local, user logan
alana... deliverable: mailer local, user alana

In this case, sendmail looks up the bin alias and finds that it points to root. It then looks up the root alias and finds that it points to admin. When it looks up admin, it finds that it points to alana, logan, and pat. Each of these are looked up and discovered to be delivery addresses that are deliverable through the local mailer.

Immediately following the admin alias is an alias with the name owner-admin. This is a special alias that sendmail expects to find. sendmail uses it to deliver error messages if it encounters any errors delivering mail to the admin mailing list.

The next alias, admin-request, is required only because it is referenced by the owner-admin alias; however, using aliases in this format is common with mailing lists because they provide two benefits. First, many users expect to be able to reach the person who maintains the list at an alias in the format of list-request—providing this alias meets these user expectations. A second benefit comes from the recipient field of the owner-list alias, which is used to construct the Unix From line and the Return-Path: header. Refer back to our example. If the owner-admin alias pointed directly to alana, the Return-Path: and the Unix From line for mail from the admin mailing list would appear to come from alana. End users who poke around in the headers and see the Unix From information may assume the mail was sent to them directly by alana instead of coming from the mailing list. Pointing the owner-admin alias to admin-request means that those users see admin-request as the source of the mail, which most users find less confusing. Since admin-request resolves to alana before final delivery is made, errors still get back to alana for analysis. Users are happy, and the purpose of the owner-admin alias is fulfilled.

Like most formal mailing lists, the chiefs mailing list also has the owner-list and list-request aliases described above. The chiefs mailing list delivers mail to the four department heads and their advisor. Three of the recipients (reba, sara, and kathy) are local email accounts. Two (tyler and jane) are aliases that point to user accounts on other hosts.

The sixth recipient on the chiefs mailing list is not a person—it’s a file. Defining the full pathname of a file on the right hand side of an alias causes sendmail to append a copy of the mail to that file. This is a simple way of creating an archive for a mailing list, and it is adequate for the small chiefs mailing list. However, the overhead associated with having sendmail copy mail to a file makes this a less than ideal solution for large, busy mailing lists. A better solution for high-volume mailing lists is to have sendmail pipe the mail to an external program that writes the archive.

Notice that the six recipients of the chiefs mailing list are defined on three different lines. When a line in the aliases file begins with whitespace (space or tab characters), the line is treated as a continuation of the previous line. Thus, the recipient list for an alias can span multiple lines.

The employees mailing list sends mail to all users. It has the same supporting owner-list and list-request aliases as the other mailing lists. The most interesting thing about this mailing list is the :include: syntax used on the recipient side of the alias. The :include: syntax causes sendmail to read a list of recipients from an external file. In the example, sendmail reads a file named /etc/mail/allusers, which contains the delivery address of everyone served by our sample mail server.

On our small sample system, the alluser file contains ten local users and three external users. sendmail includes that file into the aliases database as the recipients of the employees mailing list. Again, a sendmail -bv command demonstrates this:

# sendmail -bv employees
craig... deliverable: mailer local, user craig
kathy... deliverable: mailer local, user kathy
pat... deliverable: mailer local, user pat
logan... deliverable: mailer local, user logan
alana... deliverable: mailer local, user alana
payton... deliverable: mailer local, user payton
david... deliverable: mailer local, user david
reba... deliverable: mailer local, user reba
sara... deliverable: mailer local, user sara
jay... deliverable: mailer local, user jay deliverable: mailer esmtp, host,
user deliverable: mailer esmtp, host rodent.wrotethebook.  com.,
user deliverable: mailer esmtp, host rodent.wrotethebook.  com.,

Ten of the recipients are local users who get mail delivered through the local mailer. Three are external users whose mail is forwarded through the esmtp mailer to other hosts in the local domain.

In each of our sample mailing lists, there were no duplicate recipients. For example, the admin list resolved to alana, logan, and pat—three unique user addresses. However, as we saw earlier, multiple aliases can point to the same recipient. In particular, all of the nonlogin system user accounts on our sample system point to root. What would happen if we had a mailing list that included several of these accounts? For example:

sysusers:         daemon, bin, ftp, root, alana
owner-sysusers:   sysusers-request
sysusers-request: alana

In this sample mailing list, daemon, bin, ftp, and root all resolve to root. sendmail recognizes this problem and deletes the duplicate recipients. When mail is addressed to this sample mailing list, root receives only one copy of the mail. If sendmail did not delete duplicates, root would recieve four copies of exactly the same message.