At small sites that just use mailing lists internally, the problems are few and can be easily solved locally. But as lists get to be large (over a few hundred recipients), many (over 50 lists), or complex (using exploders), problems become harder to localize and more difficult to solve. In the following discussion we present the most common problems. It is by no means comprehensive, but it should provide information to solve most problems.
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
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
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
 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
l) option is set to true.
|Envelope sender||Section 31.10.14, $f||Should be local list maintainer|
|Section 34.8.59, SaveFromLine (f)||Same as envelope sender|
|Section 35.10.14, From:||Original submitter|
|Section 35.10.33, To:||Local list maintainer, list as a whole, or original submitter|
|Section 35.10.13, Errors-To:||Local list maintainer|
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
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
When an address in the main list begins to bounce, move it from
the main list's file to the corresponding
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
Finally, arrange to include the following header in the outgoing message:
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.
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
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.
All mass mailings, such as mailing-list mailings, should have
Precedence: line that gives a priority
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)
program) to skip automatically replying to such messages.
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
delivery agent is selected:
To prevent this misunderstanding, all such addresses should be followed by an @domain part to route the message to an appropriate X.400 gateway: