25.5.1 Reply Versus Bounce

The eventual recipient of a mailing-list message should be able to reply to the message and have that reply go to either the original sender or the list as a whole. Which happens is an administrative decision. In general, replies go to the address listed in the From: or Reply-To: headers. If the intention is to have replies go to the list as a whole, these headers need to be rewritten by a filter at the originating site:

list:   "|/etc/local/mailfilter list -oi -odq -flist-request list-real"

Here, the name of the filter has replaced sendmail in the aliases file entry. Writing such a filter is complex. The original addresses need to be preserved with appropriate headers before they are rewritten by the filter.

The converse problem is that not all mail-handling programs handle replies properly. Some programs (such as UUCP and certain versions of emacs-mail) insist on replying to the envelope sender as conveyed in the five-character "From " header. By setting up lists correctly (as we showed earlier), an administrator can at least guarantee that those replies are sent to the list maintainer, who can then forward them as required.

A more serious problem is the way other sites handle bounced mail. In an ideal world, all sites would correctly bounce mail to the Errors-To: address [3] and (less desirably) to the envelope sender. Unfortunately, not all sites are so well-behaved. If a mailing list is not carefully set up, there is a possibility that bounced mail will be resent to the list as a whole. To minimize such potential catastrophes, follow the guide in Table 25.1.

[3] The sendmail program does use the Errors-To: header, despite the fact that it was originally a hack to get around UUCP, which confused envelope and header. The Errors-To: header is not an Internet standard (in fact it violates the Internet standards) and cannot be expected to work on MTAs other than sendmail. Beginning with V8.8, Errors-To: is supported only if the UseErrorsTo (l) option is set to true.

25.5.2 Gateway Lists to News

When gatewaying a mailing list to Usenet news, the inews(1) program bounces the message if it is for a moderated group and lacks an Approved: header, which can be added by a filter program (see Section 24.3, "Write a Delivery Agent Script") or by a news gateway delivery agent.

If your site is running (or has access to) Usenet news, the recnews(1) program that is included therein may be used to gateway mail to newsgroups. It inserts the Approved: header that inews needs and generally handles its gateway role well. One minor pitfall to avoid with recnews is making separate postings when you intend cross-postings:

mail-news: "|/usr/local/recnews comp.mail comp.mail.d"  separate postings
mail-news: "|/usr/local/recnews comp.mail,comp.mail.d"  cross-posted
                                         
                                   note the comma

25.5.3 A list-bounced Alias

There are many ways to handle bounced mail in managing a mailing list. One of the best ways for large lists is to create a bounce alias for a list:

list-bounce: :include:/usr/local/lists/list-bounce

When an address in the main list begins to bounce, move it from the main list's file to the corresponding list-bounce file. Then send a message to that list nightly (via cron(8)), advising the users in it that they will soon be dropped. To prevent the bad addresses from deluging you with bounced mail, set up the return address and the envelope to be an alias that delivers to /dev/null:

black-hole:   /dev/null

Finally, arrange to include the following header in the outgoing message:

Precedence: junk

This prevents most sites from returning the message if it cannot be delivered.

There are also programs available that can help to manage large and numerous mailing lists. We will cover them later in this chapter.

25.5.4 Users Ignore list-request

It is impossible to cause all users to interact properly with a mailing list. For example, all submissions to a list should (strictly speaking) be mailed to list, whereas communications to the list maintainer should be mailed to list-request. As a list maintainer, you will find that users mistakenly reverse these roles surprisingly often.

One possible cure is to insert instructions in each mailing at the start of the message. In the header, for example, Comment: lines can be used like this:

Comment: "listname" INSTRUCTIONS
Comment: To be added to, removed from, or have your address changed
Comment: in this list, send mail to "listname-request".

Unfortunately, user inattention usually dooms such schemes to failure. You can put instructions everywhere, but some users will still send their requests to the wrong address.

A solution some sites use when the list is used only for official and rare mailings is to install the list name in the aliases file just before the mailing:

list:	:include: /usr/local/lists/official.list      before

Then run newaliases(1) and send mail to the list. After all the mail for the list has been queued, edit the aliases file and comment out that entry:

#list:	:include: /usr/local/lists/official.list      after

Run newaliases(1) again, and you will have disabled that list. That way, mail that is wrongly sent to list will bounce back to the sender who made the mistake instead of wrongly being broadcast to the list as a whole.

25.5.5 Precedence: bulk

All mass mailings, such as mailing-list mailings, should have a header Precedence: line that gives a priority of bulk, junk, or list. On the local machine these priorities cause the message to be processed from the queue after higher-priority mail. At other sites these priorities will cause well-designed programs (such as the newer vacation(1) [4] program) to skip automatically replying to such messages.

[4] The vacation(1) program is a wonderful tool for advising others that mail will not be attended to for a while. Unfortunately, some older versions of that program still exist that reply to bulk mail, thereby causing problems for the mailing-list maintainer.

25.5.6 X.400 Addresses

The X.400 telecommunications standard is finding increased acceptance in Europe and by the U.S. government. Addresses under X.400 always begin with a leading slash, which can cause sendmail to think that the address is the name of a file when the local delivery agent is selected:

/PN=MS.USER/O=CORP/PRMD=CORP/ADMD=TELE/C=US/

To prevent this misunderstanding, all such addresses should be followed by an @domain part to route the message to an appropriate X.400 gateway:

/PN=MS.USER/O=CORP/PRMD=CORP/ADMD=TELE/C=US/@X.400.gateway.here