Chapter 4. Early days

Table of Contents
4.1. Configuration hassles
4.1.1. Membership policy
4.1.2. Moderation
4.1.3. Archiving
4.1.4. Reply-to headers
4.1.5. Subject tags
4.2. The welcome message
4.3. Intros

4.1. Configuration hassles

In the early days of your mailing list, you're almost certain to have some configuration issues. There are many issues to face, all of which impact on the ongoing effectiveness of your mailing list.

4.1.1. Membership policy

Fairly early on, you're going to have to decide what membership policy to take.

Table 4-1. Membership policies

Policy Description
Open Anyone can subscribe
Open with confirmation Anyone can subscribe, but each new subscriber will be sent a message to which they must reply, as confirmation that they actually meant to subscribe and weren't added to the list by some third party
Approval required Anyone can (attempt to) subscribe, but all subscriptions must be approved by the list owner
Closed Only the list owner can add anyone to the list

"Open with confirmation" is the most common configuration for new lists these days, as it allows a measure of protection against maliciously forged subscriptions.

4.1.2. Moderation

A moderated list is one which requires all posts to be approved by the list owner or another moderator. This is particularly suited to announcement mailing lists, and may also be used on lists where quality control must be ensured, or where there is potential for offensive material to be posted.

Moderation imposes a considerable administrative overhead, and should only be used when necessary. The use of a "black list" (people who may never post to an otherwise unmoderated list) or a "white list" (people who may always post to an otherwise moderated list) may be a more workable solution, but can be hard to implement in some mailing list software.

4.1.3. Archiving

Many mailing lists are archived on the World Wide Web. This allows both subscribers and outsiders to read old posts, and is particularly useful for technical lists where common questions are asked again and again if they cannot easily be found when needed.

Archiving is either achieved through the mailing list software itself (eg Mailman and Lyris) or via a third-party archiving tool such as Hypermail or MHonArc.

There are disadvantages to web archives, however. The first is that the hundreds of HTML pages generated by such archives clutter up the web. Many archives have been indexed by search engines, and may show up in search results. This is sometimes a good thing (as in the not uncommon case of someone typing in half a dozen technical terms and finding a mailing list post that deals with exactly the issue they're looking for) and sometimes a bad thing (such as when a search shows up hundreds of irrelevant mailing list posts before any "real" pages).

In my opinion, this is a failing of the search engines, and canny searchers know how to avoid mailing list hits when they don't want them (by using -thread to avoid pages containing the word "thread" (as most mail archives do) in Altavista, for instance).

If you want a web archive for the benefit of your members, but don't want it indexed by search engines, there are a couple of things you can do. Firstly, some list management software (such as Mailman) lets you choose whether to make the archives public or not. Secondly, a robots.txt file can be used to turn away the search engine indexing spiders from any web page, including your archives.

The other problem with web archives is that of privacy. Unless you keep reminding them, mailing list members may not realise that their words are being put on the World Wide Web for anyone to read. If your list is of a personal or controversial nature (eg support for gay teenagers), don't archive it. Don't imagine that people won't find it. They will. I should know -- I just had one of my mailing list posts hit the headlines on ZDNet.

4.1.4. Reply-to headers

At some stage in every list's life, someone will suggest that you make the Reply-to header point back to the list. Don't do it. There are numerous technical reasons not to, which are fully documented in Chip Rosenthal's essay entitled "Reply-to munging considered harmful" at http://www.unicom.com/pw/reply-to-harmful.html.

Simply speaking, setting the Reply-to address back to the list can cause more problems than it solves. Rather than breaking things in this manner, you should try to educate people by pointing them at the aforementioned article.

Let me say it again: DO NOT SET THE REPLY-TO POINTING BACK TO YOUR LIST! I really mean it.

Actually, I know experienced list admins who will sometimes munge the Reply-to header, but they usually have very good reasons for it. Don't do it unless you've read and considered the article mentioned above and really know what you're doing. The circumstances in which this is done are usually when there is a small list in a homogenous environment (eg the staff of a small company), or when you have a social list for non-technical people who go beyond "non-technical" and into the realm of "clue resistant". In that case, you have my condolences, and I concede that your prime directive should be to save yourself stress and headaches.

4.1.5. Subject tags

Many lists have a tag in the subject line such as [ListName]. This is used to easily distinguish lists from each other, both by humans and by filtering software. Filtering on subject lines isn't ideal, and there are better things to filter on for most mailing lists (Sender: headers for majordomo, List-ID: headers for mailman, etc), but a shortish subject tag doesn't cause any particular difficulty to anyone, breaks no software, and solves more problems than it creates. I strongly advise a subject tag for all lists.