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
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
) insist on
replying to the envelope sender as conveyed
in the five-character "
A more serious problem is the way other sites handle bounced mail. In an
ideal world, all sites would correctly bounce mail
When gatewaying a mailing list to Usenet news, the
bounces the message if it is for a moderated group
and lacks an
If your site is running (or has access to) Usenet news,
(1) program that is included therein may be used
to gateway mail to newsgroups. It inserts the
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
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: "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
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
to think that the address is the name of a file when the
To prevent this misunderstanding, all such addresses should be followed by an @domain part to route the message to an appropriate X.400 gateway: