Table of Contents for

Postfix: The Definitive Guide

If any messages cannot be delivered to one of the addresses listed, the original sender of the message receives an error message explaining that there was a delivery problem. For small or internal lists this may be perfectly acceptable; however, if you are creating a large list, or the members of the list do not necessarily know each other, it is probably more appropriate to have error messages sent to the administrator of the list. The convention is to create an additional alias for lists using a format like owner-<list_alias>@example.com, where owner- is prepended to the name of the list alias. For the previous example, we would create the alias owner-needlepoint.^[1] This owner- alias should point to an administrator, who is generally in a better position than the original sender to deal with bounced messages:

owner-needlepoint: kdent@example.com

Sending error notifications to the owner- alias is achieved by setting the envelope sender to the owner-needlepoint@example.com alias instead of the original sender’s email address. Example 10-1 shows typical headers from a mailing-list message.

Return-Path: <owner-needlepoint@example.com>
Delivered-To: rgrier@oreilly.com
Received: from cowrie.example.com (cowrie.example.com[192.168.100.7])
     by mail.oreilly.com (Postfix) with ESMTP id B712120DD5B
     for <needlepoint@example.com> Mon, 13 May 2002 11:55:40 -0400 (EDT)
Date: Mon, 13 May 2002 12:00:43 -0400 (EDT)
From: G.M. Hopper <gmhopper@onlamp.com>
X-Sender: gmhopper@cowrie
To: needlepoint@example.com
Subject: Just finished latest project
Message-ID: <Pine.GSO.4.10.10205131200230.692-100000@cowrie>

When the owner- alias exists, Postfix automatically uses it as the envelope sender address when sending out messages to list members. If, for some reason, you don’t want Postfix to use the owner- alias but rather to keep the originator’s address, you can set the parameter owner_request_special to no:

owner_request_special = no

You can also cause Postfix to use the actual administrator’s email address instead of the owner- alias by setting expand_owner_alias to yes:

expand_owner_alias = yes

If this parameter is set, the address kdent@example.com is used instead of owner-needlepoint@example.com.

Although users do not generally need to send mail directly to the list owner, you should create owner aliases even for simple lists so other postmasters can contact the correct person in case they run into any problems with your list.

Another list convention is to provide a request alias for your lists. Request aliases use the format <list_alias>-request@example.com. The request alias for the needlepoint alias looks like needlepoint-request@example.com. Request aliases are used for requests to subscribe and unsubscribe from lists or to get nontechnical information about a list.

If you have more than just a few names on a list, it is more convenient to create a text file that lists all of the email addresses for the list. The format of the alias entry that points to a file is as follows:

               email_alias: :include:/path/to/file.

Let’s take the needlepoint alias from earlier in the chapter and move the list addresses into a separate file. Your alias entry should be revised to point to the text file that contains the list of addresses:

needlepoint:        :include:/etc/postfix/needlepoint

The file /etc/postfix/needlepoint contains the email address of each member of the group. Put one address on each line. When you need to make changes to the list, simply edit the file:

rgrier@oreilly.com
gmhopper@onlamp.com
grayburn@oreilly.com
bogus@example.com

I’m adding an invalid address, bogus@example.com, for testing later in the chapter.

Recall from Chapter 4 that the alias_maps parameter allows you to specify any number of alias files to use with Postfix. For example, you might want to use a separate alias file to store your mailing lists. Simply include the separate alias filename along with the system alias to set the alias_maps parameter. You should also set the alias_database parameter, so that you can run the command newaliases to update all of your alias-mapping files:

alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/mail_lists
alias_database = hash:/etc/postfix/aliases, hash:/etc/postfix/mail_lists

It may be more convenient to assign all of your alias files to alias_database and then assign alias_database to alias_maps. If you use other map types for aliases, simply assign them to alias_maps as well:

alias_database = hash:/etc/postfix/aliases, hash:/etc/postfix/mail_lists
alias_maps = $alias_database, nis:mail.aliases

Remember to reload Postfix when you make changes to main.cf.

Let’s review everything discussed so far and consider all the pieces of our needlepoint mailing list. The alias file contains the following lines:

needlepoint:          :include:/etc/postfix/needlepoint
owner-needlepoint:    kdent@example.com
needlepoint-request:  kdent@example.com

The first line in the example causes messages sent to needlepoint@example.com to be delivered to every address listed in the /etc/postfix/needlepoint file. This file should contain a list of email addresses of all members of the list. Bounce messages and requests are forwarded to the real address kdent@example.com. If necessary, users or other postmasters can send messages to the list owner, and users can send messages to the request alias for subscription or other information.

When a message is sent to the list, the To: header contains just the address of the mail list alias and not an expansion of all the names on the list (which could be hundreds or even thousands of names). Each member of the list receives a copy of the message with headers that resemble those shown in Example 10-1. In this example, gmhopper@onlamp.com has sent a message to the list. Notice that the Return-Path: contains the owner alias rather than the actual originator of the message (gmhopper@onlamp.com).

You can test your list by sending a message to the alias you created for it. In this example, we’ll use the list alias needlepoint@example.com. Example 10-2 shows the log entries for a sample test message. Imagine that the address bogus@example.com is invalid.

postfix/local[7411]: 6C2CE20DD5B: to=<needlepoint@example.com>, 
   relay=local, delay=1, status=sent (forwarded as ACDC120DD70)
postfix/qmgr[8163]: ACDC120DD70: from=<owner-needlepoint@example.com>, 
   size=1121, nrcpt=8 (queue active)
postfix/local[0835]: ACDC120DD70: to=<bogus@example.com> relay=local,
   delay=1, status=bounced (unknown user: "bogus")
postfix/smtp[6556]: ACDC120DD70: to=<grayburn@oreilly.com>
   relay=mail.oreilly.com[10.82.6.11], delay=1, 
   status=sent (250 Mail accepted)
postfix/smtp[6556]: ACDC120DD70: to=<rgrier@oreilly.com>
   relay=mail.oreilly.com[10.82.6.11], delay=1, 
   status=sent (250 Mail accepted)
postfix/smtp[5954]: ACDC120DD70: to=<gmhopper@onlamp.com>
   relay=mail.onlamp.com[10.171.8.111], delay=1, 
   status=sent (250 Message received: GZCLUC00.E8F)

Some of the information, such as the timestamp and hostname, has been removed for clarity. Notice that at the end of the first line there is a comment saying (forwarded as ACDC120DD70) and the rest of the log entries use the new queue ID. Also notice in the first line of the example that the message enters the system addressed to needlepoint@example.com. The second line shows that Postfix uses the owner alias as the envelop sender address (from=<owner-needlepoint@example.com>) while delivering the message to all members of the list. The bogus address shows a status of “bounced.” The address kdent@example.com pointed to by the owner alias receives the bounce notification, which looks like Example 10-3. Notice in the example that the bounce notification message is delivered to owner-needlepoint@example.com. The sender of the message does not receive a notification.

From MAILER-DAEMON@mail.example.com Tue Jul 16 12:03:49 2002
Date: Tue, 16 Jul 2002 11:25:27 -0400 (EDT)
From: Mail Delivery System <MAILER-DAEMON@mail.example.com>
To: owner-needlepoint@example.com
Subject: Undelivered Mail Returned to Sender

...

<bogus@example.com>: unknown user: "bogus"

...