Advice for Mailing List Owners

Advice for Mailing List Owners Kirrily Robert skud@netizen.com.au Netizen Pty Ltd 1999 Kirrily Robert This work ("Advice for Mailing List Owners") is distributed under the terms of the Open Publication License.

LICENSE Terms and Conditions for Copying, Distributing, and Modifying Items other than copying, distributing, and modifying the Content with which this license was distributed (such as using, etc.) are outside the scope of this license. 1. You may copy and distribute exact replicas of the OpenContent (OC) as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the OC a copy of this License along with the OC. You may at your option charge a fee for the media and/or handling involved in creating a unique copy of the OC for use offline, you may at your option offer instructional support for the OC in exchange for a fee, or you may at your option offer warranty in exchange for a fee. You may not charge a fee for the OC itself. You may not charge a fee for the sole service of providing access to and/or use of the OC via a network (e.g. the Internet), whether it be via the world wide web, FTP, or any other method. 2. You may modify your copy or copies of the OpenContent or any portion of it, thus forming works based on the Content, and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified content to carry prominent notices stating that you changed it, the exact nature and content of the changes, and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the OC or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License, unless otherwise permitted under applicable Fair Use law. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the OC, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the OC, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Exceptions are made to this requirement to release modified works free of charge under this license only in compliance with Fair Use law where applicable. 3. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to copy, distribute or modify the OC. These actions are prohibited by law if you do not accept this License. Therefore, by distributing or translating the OC, or by deriving works herefrom, you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or translating the OC. NO WARRANTY 4. BECAUSE THE OPENCONTENT (OC) IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE OC, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE OC "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK OF USE OF THE OC IS WITH YOU. SHOULD THE OC PROVE FAULTY, INACCURATE, OR OTHERWISE UNACCEPTABLE YOU ASSUME THE COST OF ALL NECESSARY REPAIR OR CORRECTION. 5. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MIRROR AND/OR REDISTRIBUTE THE OC AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE OC, EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

More information about Open Content may be found at http://www.opencontent.org/ 1.0 1999-10-29 KR Several minor changes in response to feedback 0.9 1999-09-30 KR Initial version Contents Introduction This is a collection of advice for mailing list owners based on my experience of running technical and social lists of all sizes since 1994. It's not a technical document, and you won't find out how to configure your mailing list software here. Instead, you'll learn some general techniques to help you make your mailing list run smoothly and keep yourself sane in the process. This article can be found at http://netizen.com.au/~skud/articles/mladvice/. Any comments should be emailed to the author, Kirrily Robert, at skud@netizen.com.au. So you want to run a mailing list Introspection You've come up with a great idea: a mailing list for people who like chocolate mud cake, or drive Formula-1 racing cars, or write major accounting packages in INTERCAL. Whatever. Before you start, you'll need to think about a few things, and the first thing you should think about is why you want to start the list. Most people start mailing lists for selfish reasons, and this isn't a bad thing. Usually, you'll want to start the list to disseminate information about something that you "own" (for instance, a technical mailing list for a piece of software you distribute, or an announcement list for a club or business), or you want to form a list for discussion of a topic you're interested in and hopefully meet other people with similar interests. Sometimes it's a combination of the two. Just because you have a vested interest in the mailing list doesn't mean that you shouldn't start it. But be wary of starting a list whose publically stated aim is different from your own personal aims. An example of this might be a list which you publicise as being "a help and support group for new web authors" but which you really intend to be a vehicle for you to sell your book about HTML. Commercial interests are the most common example of such lists, but there are others. If your personal aims do not match the publicly stated purpose of the list you're hoping to start, you need to change one or the other. The easiest thing is to change the publicly stated purpose of the list -- simply include in any announcements, publicity or FAQs a blurb which describes your reasons for starting the list. Disclosure of purpose I'm starting this list in the hopes of meeting people who share my interest in this topic. - - - This list is intended to inform its members of the products and services provided by ExampleCorp, as well as to provide a discussion forum for users of our products. - - - This list is the outgrowth of discussions between myself and Joe Smith, who suggested that a mailing list would be an appropriate way to encourage people to contribute to our political cause. Market research You might think that market research is unnecessary since you aren't trying to make money from your mailing list. Wrong! While you might not be looking for a profit, you are going to invest a lot of time and energy into the list, so you may as well make sure it's going to be worth it. The two most important things to check are firstly, is there a need for the list, and secondly, does another list or forum exist already? Find out the answers to these by asking in related fora including other mailing lists, newsgroups, web-based bulletin boards, IRC or other chat facilities, etc. Don't just ask "do you think it's a good idea?" but specifically ask people if they would subscribe to such a list if it existed. If it appears that there are people interested in your list (a dozen positive responses should be sufficient), and if there is no other list already doing exactly the same thing, then by all means go ahead and start your list. If you do not get any expressions of interest, you will probably find yourself on a very quiet list, talking to yourself. If you find that there is another list with an identical or similar purpose, join it and read/contribute for a few weeks before you make a final decision either way -- it may be that your list would be differentiated in some important way (geographical focus, noise level, etc), in which case it will probably be worth going ahead anyway. Setting up your list List software One of the first decisions you'll need to make is what list software to use. There are several choices available, each with their own advantages and disadvantages. The deciding factor, however, should be "use whatever's easiest for you". If your ISP or workplace provides mailing list software, go with what's there. If, however, you're in a position to make your own choice, here's a brief run-down of the pros and cons of various mailing list software. Majordomo Majordomo is probably the most common mailing list software around. It's easy for people to subscribe, fairly configurable (via email), and lots of people will be able to help you with it. On the down side, it doesn't do web archives without the help of 3rd-party tools like Hypermail or MHonArc, doesn't do moderation easily, and can overwhelm list owners with "bounce" and "approve" messages if subscribers' email addresses don't work. Majordomo is written in Perl, albeit nasty, messy, version 4 Perl which is pretty much impossible to work with. A new version is expected sometime "real soon now". Mailman While the world waits for Majordomo's next version, Mailman is taking a lot of its market share. Mailman provides a web interface as the default means of subscribing to and administering lists, which is perfect for inexperienced list administrators. Email interfaces are also available, however. Mailman's great strengths include automatic web archives, mail-to-news gateways, very easy administration, excellent handling of "bounce" and "approval" messages, and simple mailing list moderation. On the down side, its email interface isn't as nice as Majordomo's, and not as many people know it. Ezmlm Ezmlm is a mailing list manager designed to work with the QMail MTA. It is supposedly very fast and good at handling very high volume lists (hundreds or thousands of subscribers). On the down side, its email interface is pretty ugly. LISTSERV LISTSERV is fairly common in Universities. It has a mail interface which is not too bad. Administration is usually fairly centralised, and you may need to get your site's postmaster to do a lot of the work for you. Generally speaking, don't use this unless it's your site's standard. Lyris Lyris is a commercial list management system. I don't know much about it other than it has some web interfaces which look slick but are particularly unusable. Free list hosting services Free list hosting services are available at several places on the web. The advantage of these is that any schmuck can set up a list and run it. The disadvantage is that you'll usually get the host site's advertisements pasted into every email that goes to your list, and that the subscribers lists may be sold to commercial direct marketing organisations (read: SPAM mongers). Check whether the hosting site has a suitable privacy statement before inflicting a lifetime of junkmail on your list subscribers. A list by any other name... Choosing the right name for your list can be a real challenge. The name should reflect, as accurately as possible, the purpose of your list. It should also be as short as possible. List names often begin with an (abbreviated) place name. If your list is intended for people in a particular geographic region, it's a good idea to do this. An example of a list I'm on that does this is the "Aussie ISP" list (a discussion list for Australian ISPs), which is ozisp@aussie.net Where there are several lists dealing with a related topic, it is usual to use a suffix to indicate the purpose of each list. Common examples include: -announce (for announcements) -discuss (for discussions) -dev (for development issues, especially of sofware) -support (for support) -jobs (for job postings) ... et cetera Publicity You should publicise your new mailing list with a brief (10 lines) announcement to appropriate fora such as newsgroups, related mailing lists, websites, etc. Be sure to include the name of the list, its purpose, the subscription address, and a URL or other pointer to more information. If you are posting to a non-technical forum, be sure to spell out the subscription process in painstaking detail. Announcement for a technical list I've just set up foonix-dev for developers of the foonix system. If you're interested, simply: % echo subscribe | mail foonix-subscribe@example.com Announcement for a social list If you are interested in plays and theatre showing in Melbourne, Australia, you might like to subscribe to the new mailing list I've set up called melb-theatre. To join this list, send an email to majordomo@example.com.au with the words "subscribe melb-theatre" (without the quote marks) in the BODY of your message. Early days 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. Membership policy Fairly early on, you're going to have to decide what membership policy to take. 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. 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. 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. 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. 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. The welcome message Once you've got a handful of subscribers, it's a good idea to send out a formal welcome message and get the ball rolling. Sample welcome message Hi folks, The list's up and working, and we seem to have about a dozen people subscribed, so I thought I'd post a quick welcome message: WELCOME! Please feel free to post any questions or discussion topics to the list by sending email to listname@example.com, and feel free to email me personally at myname@example.com if you have any problems. Just to introduce myself for those of you who don't know me... My name is Fred Foonly, and I'm a software engineer by profession. I have a particular interest in GUI design, so I'm looking forward to seeing how this list evolves and getting some new ideas for my work. Later, Fred The only time you shouldn't use a welcome message is for an announcement list. Intros Particularly on a social or semi-social mailing list, the welcome message will lead straight on into a bunch of introduction messages as members make themselves known to each other. These will, in turn, evolve into discussions of topics raised in the intro messages. Sometimes you'll find the intro messages irritating, especially when a busy list goes through second-round intros to introduce all the old people to the new people, ad infinitum, but there's nothing you can do about it except try to steer the intros towards "real" topics as quickly as possible. Smooth running The golden rule The golden rule of list management is "benevolent dictatorship". You, as a list owner, can do whatever the hell you like with your list, including closing it down when you get sick of it. You're offering it as a service to the community and because you're personally interested in it, not because you're somehow obliged to. Don't try to use democracy on a mailing list. There'll always be at least n+1 opinions, where n is the number of subscribers, and in fact there are usually more than that. If you want to do something to or with the list, post a message telling them your plans, allow a couple of days for any major issues to arise, then do what you feel is right. Any other course of action leads to insanity. On topic? What's on topic for your list? You need to have some idea of this by the time your list's a week old, or reaches twenty posts a day -- which ever happens first. The best thing to do is write a short list of allowable topics and just announce it, preferably when you start the list; refinements can occur as time goes on. Ideally, this list of allowable topics will become part of a FAQ which is sent to new members, posted regularly to the list, and kept somewhere on the World Wide Web. Allowable topics Topics welcome on the Chocolate Cake List include: - recipes - chocolate cake stories - brand comparisons - chocolate cake reviews - some discussion of other desserts Off-topic are: - non-dessert-related posts - protracted threads about desserts other than chocolate cake Don't be afraid to put qualifiers with respect to how much off-topic discussion is allowed. People would rather see "some discussion..." as in the example above than an overly legalistic set of rules. Most list subscribers will be fairly sensible about what constitutes a semi-relevant post, and a gentle encouragement to include an "ObFoo" (where "Ob" stands for "Obligatory" and "Foo" is the topic at hand, eg "ObCake" for the Chocolate Cake List) in off-topic posts is usually enough to ensure some reasonable level of signal to noise. Being a net.cop If etiquette is the grease on the axle of society, then netiquette is the grease on the axle of a mailing list. As a list owner, you need to make sure that your list's members are behaving themselves both socially and technically. On the technical front, it's worth including a set of rules in your FAQ about the format of posts to the list. Suggested rules include: No binaries or other attachments No HTML or other non-text formatted mail Wrap text at under 80 characters Signature files no more than 4 lines long On the social front, you might like to suggest: NO SHOUTING Keep it nice -- no name-calling, insults, or offensive material Remember that it's hard to tell a person's tone of voice in email. Ask yourself whether a post could have been intended as a joke, sarcasm, or a hypothetical idea before flaming. Don't repost private mail to the list; don't repost list mail to anywhere else Before posting a question, check the FAQ, documentation, and recent posts to the list to see if your question has already been answered Conflict resolution Sometimes major dramas will occur, such as an all-out war between subscribers, a person who repeatedly posts offensive material, etc. The only way to deal with such incidents is to make sure you have your "benevolent dictator" hat firmly on your head, and sort it out as quickly as possible. Suitable ways of dealing with such problems include warning the perpetrators that they will be banned from the list if their activities continue, and/or actually banning them. There's not much else at your disposal. Do you need a listmom? Social lists and technical lists have very different dynamics. This should come as no surprise to anyone. What may be news to you, though, is that social lists often need two administrators -- a technical one and a social one. The social administrator is often referred to as a "listmom" or "den mother" or some other maternal kind of name, and is in fact often female (though not always). Her (or his) main activity is ensuring that the list members all play nicely and that nobody gets hurt. If you run a busy social list, you might like to consider formally splitting the administrative roles so that you have separate people, with separate titles, looking after the social and technical aspects of the list. This can relieve some of the time and effort burden, as well as allowing people to do what they're best at. Let's face it, not every techie can be a social leader, and not every social leader is technically skilled. If you run a technical list, you'll almost never have to do anything of this kind. Managing many lists There are extra issues related to running many related lists. In particular, you may need to make a regular post to all your lists explaining what lists exist and what they're for. This helps keep things on topic on all the lists. Your list-of-lists should contain the list names, subscription details, main focus, and an example of the sort of thing posted there. I'd recommend posting it fortnightly or monthly, depending on how busy your lists are and how badly they need it. List of lists Here is the monthly reminder about the foonix mailing lists. foonix-dev Subscription address: foonix-dev-request@example.com Topic: Developers of foonix Example: "Should we include this in the next release?" foonix-announce Subscription address: foonix-announce-request@example.com Topic: Announcements about foonix Example: "Version 3 is available for download via FTP" foonix-support Subscription address: foonix-support-request@example.com Topic: Questions and support requests Example: "I can't get foonix to install" Automate, automate, automate! To prevent your list admin job from becoming onerous, you should automate as many things as possible. Make friends with cron and alias, learn to love procmail, and beg, borrow or steal a collection of scripts to help simplify administration as much as possible. If you're spending more than half an hour a day at volunteer list administration, you haven't automated enough. If you're letting administration tasks pile up for more than a few days at a time, you haven't automated enough. Death of a list Natural causes Sometimes lists just die of old age. The topic they were created for has died down, and there's no point to it any more. The best thing to do is just announce that you're closing up shop, shut the list, and move on to bigger and better things. Lists that never take off About half the mailing lists I've started have never taken off. This is normal, as far as I can see. Sometimes there's a flurry of interest for a month or so, but insufficient momentum to keep it going. Other times it was just a bad idea to start with. Both cases are indications of insufficient market research at the start. When this happens to a list, you can either try to breathe life into it by sheer force of willpower, or let it go. If you choose to do the latter, be sure to announce that you're closing the list rather than just let it die down. Closing a list Since this list hasn't had any traffic for over six months, I am going to close it down at the end of the week. Thanks to those of you who contributed early on, and I hope to see some of you in related groups in the near future. All the best, Fred. Crash and burn Sometimes an otherwise active list will die due to a burn-out on the part of the list owner or the system on which the list is running. If you, as an list owner/admin, feel yourself burning out, try to hand the list on to someone else. Do this before you have a nervous breakdown or just start filtering the list to /dev/null. A list without an admin (or with an absent or uncaring admin) will get messy with off-topic threads, pointless meta-discussions, misdirected administrative requests, and god knows what. It's a pity to see a good list go down the drain, so try to find a guardian for your list before this happens. You might even like to ask someone to look after the list for a month or a year while you take a break from it. Sometimes a system failure can bring a list down. If you're lucky, someone kept a backup of the subscriber list and you'll be able to recreate the list either on the same system (when it's back up again) or on another system. If your list is really important and you're not sure of the hosting site's backup procedures, , keep your own backup of the subscriber list. If you don't have the subscriber list and need to start the list again from scratch, you'll need to post an announcement to all relevant places (related lists, newsgroups, websites, etc) to try and reach as many of your original subscribers as possible. If you're having trouble getting the list running again, don't be afraid to put out a plea asking for a new list host. Many people are able to provide majordomo or mailman lists on their own machines, and it's quite likely that there is at least one of these people in your net community who would be willing to help out. A popular, well-run list will always be able to find a new home.