Please note that much of this chapter is subjective, based on personal experiences during several years of list ownership, and may not necessarily match your own philosophy of "the way things ought to be." The following sections are offered as one way to run a list, and the author does not mean to assert that the one way offered - his way - is the only way. As we seem to say so often, "your mileage may vary."
One of the most important things you can do as a list owner is make it clear from the outset what policies are in place and will be enforced if it becomes necessary. Due to a potential for controversy, for instance, some lists may require a formal "list charter" by which all subscribers must agree to abide before they are allowed to subscribe. Other lists may be able to get by with a simple welcome file (see below) that spells out basic netiquette, polices on "flaming" and commercial posts, and anything else that seems appropriate (such as how to get in touch with the list owner in an emergency, where the list archives are located, etc.).
It is particularly important on open subscription lists that you make a concerted effort to remind your subscribers on a regular basis of the policies you have set for your list, as well as any other information they need in order to make best use of your list. If you have a great deal of subscriber turnover, it may be necessary to do this every few weeks. You may decide to put together a quarterly or semi-yearly post for more stable lists. Ensure that the subject line is indicative of what the administrative posting is so that there is no question as to whether or not you posted it (even if subscribers don't read it).
By default, the list owner becomes a moderator of sorts, even if the list in question is neither edited nor officially moderated. This means that, as a list owner, you must be prepared to maintain order if it becomes necessary. At the same time, you must moderate yourself so that you do not alienate users and cause your list and/or host institution to suffer as a result. Thankfully, mailing lists have generally enjoyed relative peace and quiet over the years in comparison to newsgroups, but mailing lists have unique problems of their own.
Lists dedicated to controversial subjects are more likely to become arenas for "flame wars" between subscribers with hard-held and differing opinions than those dedicated to the discussion of popular software packages, but this does not mean that the latter are immune any more than it means that the former are constantly plagued by flames. The example set by you as list owner and as a participating subscriber to the list is perhaps the most important factor in whether or not your list becomes a site known for strife and controversy. In other words, if you appear not to care about whether or not discussion is on topic and/or civilized, no one else will, either. Yet if you become a policeman - the other end of the spectrum - no one will want to subscribe or participate for fear of your wrath. Either way, your list is unlikely to last very long.
The middle ground is, as in most things, the place to be when administering a list. Some call this "firm but fair," letting things go pretty much as they will but stepping in with a wry or gently chiding remark from time to time when exchanges get heated. And they will! Software discussion lists are particularly bad about this when new subscribers ask "frequently-asked questions" (FAQs) and veteran subscribers respond in exasperated fashion with "RTFM!" (Read The Fine Manual) and similar nasty retorts. Good list owner practice at this point is likely to be a good-natured reminder from you that flames belong in private mail, pointing out that new subscribers have no way of knowing that the particular questions they ask have been asked (and answered!) n random times before.
Finally, if your mailing list has an international audience, you will need to be careful to account for language problems and cultural differences. You will need to decide which languages are allowed or not allowed on the list; this should be mentioned shortly in the list abstract or welcome message. In most cases, the official language will be English. As your list grows, some subscribers may object to this decision, arguing that people who have trouble expressing themselves in English should be allowed to use their own language, with the understanding that many people will be unable to understand what they are saying. As the list owner, it will be your call. Usually, the best compromise is to start a separate list for discussions in the new language. However, you must be careful in wording your decision. In multi-lingual cultures, it is usually considered a courtesy to use the other person's language. It is certainly considered rude for people to demand that everyone else should speak their language. Thus, if your native language is English, you will be in a delicate position. To avoid a flame war, you will want to make sure that your decision does not come out as a unilateral demand. Politely suggesting a separate list, and tolerating an occasional non-English posting when the poster genuinely cannot speak English, is often the best course of action.
Another possible source of flame wars is unintended rudeness. It is easy to forget that non native speakers are making an effort every time they post something to the list. People will make mistakes, sometimes appearing rude when they did not mean to, simply because they used the wrong word. Another cause of apparent rudeness is cultural difference. Things which are perfectly normal in one culture can be insulting in another. For instance, ad hominem attacks are perfectly acceptable in some countries. Conversely, referring to other people by their first name ("As Peter said in his last message, ...") can be downright insulting in some cultures, where anything short of the full title is at best condescending. But, of course, in other countries the use of the full title is considered sarcastic... There is no middle ground here, because there are too many conflicting cultures and too many languages. The only way to successful cross-cultural communication is through the tolerance of other people's cultural habits, in return for their tolerance of yours.
Edited lists are generally used for the purpose of "full moderation" or for refereed electronic journals or the like, for which random postings from subscribers and/or non-subscribers may not be welcome for general distribution. This places the list owner and any editors in the position of being full-time monitors of what is and is not allowed to go through to the list.
A word of warning to potential list editors: Rules on the Internet are not set in stone. Some people will insist on their right to post without what they will term "censorship" by the list editor. Some will become upset to the point of threatening to report you to your local computing center administrators for abridging their freedom of speech, or (in the U.S.) even threatening to sue your institution and you personally for an abridgment of their First Amendment rights. It is therefore vitally important to you that you keep a "paper trail" of such complaints in the event that threats become reality and you are asked about them. This common practice in the business world should be common practice in list ownership as well.
Freedom of speech and copyright issues on the Internet have not yet been tested in the courts as of this writing. These are both areas in which list editors and list owners in general must tread carefully. Always document any problems you may have in these areas.
Note that L-Soft currently recommends that edited lists be coded with the ",Confirm" parameter to the "Send=" keyword, in other words:
* Send= Editor,Confirm
or
* Send= Editor,Hold,Confirm
This will help prevent malicious users from forging mail from an editor address in order to get around your moderation settings, by telling LISTSERV to require an "OK" confirmation whenever it receives a posting from an editor address. The "OK" request goes to the editor address, so the forger is stymied.
Note also that some vacation programs and broken mailers have recently been "reflecting" mail back to lists in such a way that the mail appears to be coming from the editor's address (and the mail therefore gets through). Setting the ",Confirm" option will stop this phenomenon as well.
Should you decide that an edited list is the way to go for your particular situation, you need only add the following lines to your list header file:
* Send= Editor
* Editor= userid@some.host.edu
where "userid@some.host.edu" should be replaced with the network address of the person who will be handling submissions to your list. There can be multiple editors as well (and multiple Editor= lines, if desirable), and they do not have to be list owners:
* Send= Editor
* Editor= alex@reges.org,joe@foo.bar.edu
* Editor= tony@tiger.com
Normally, LISTSERV forwards submissions only to the first editor defined by the "Editor=" keyword. In the case above, all submissions would go to the primary list owner.
NOTE CAREFULLY that the first editor CANNOT be an access-level; e.g., you cannot use the notation "Editor= Owner" to define the first editor. LISTSERV requires that the primary editor of a list must be the e-mail address of a real person.
Note also that this does not apply to second and subsequent editors. For instance, in order to allow subscribers to post directly but have non-subscriber posts sent to an editor for approval, you can code something like:
* Send= Editor
* Editor= alex@reges.org,(MYLIST-L)
On a high-volume list, LISTSERV allows you to share the editing load via the "Moderator=" keyword. By default, this keyword is set to the same value as the first editor defined by "Editor=". When you define more network addresses with the "Moderator=" keyword, LISTSERV sends submissions to each moderator in sequence. The difference between the "Editor=" and "Moderator=" keywords lies in the fact that while any editor can post directly to the list, only moderators receive the forwarded submissions from non-editors.
Here is an example of a list with both Editor= and Moderator= keywords defined:
* Send= Editor
* Editor= joe@foo.bar.edu,tony@tiger.com,kent@net.police.net
* Moderator= kent@net.police.net,joe@foo.bar.edu
This list will "load-share" the editing duties between Kent and Joe. Tony is able to post directly to the list, but will not receive forwarded subscriber posts for editing.
Note that whereas an Editor is not required to be a Moderator, a Moderator should always be listed as an Editor. LISTSERV currently compares the contents of the "Editor=" and "Moderator=" keywords and consolidates the two sets of parameters if necessary, but coding lists this way is not considered good practice and the "compare/consolidate" feature may be removed in a future upgrade.
Beginning with 1.8c, if the parameter "All" is coded before any moderator addresses, LISTSERV will send copies of all postings to all moderators, any of whom may approve the message. An example of this would be
* Moderator= All,kent@net.police.net,joe@foo.bar.edu
Assuming "Send= Editor, Hold", once a message is approved by one of the moderators, any other moderator attempting to approve the same message will be told that an identical message has already been posted to the list.
If "Send= Editor" (e.g., without "Hold"), please note that if a note is appended or prepended to the edited post, or if the body of the post itself is edited (that is to say, if the body of the approved message is changed), duplicates are possible. Thus it is important that the moderators of any list set up this way pay close attention to whether or not the posting has already been approved by another moderator.
By default, LISTSERV forwards subscriber contributions to the Moderator/Editor with the following paragraph prepended to the message body:
-----------------------------------------------------------------------
This message was originally submitted by JOE@FOO.BAR.COM to the ACCESS-L
list at PEACH.EASE.LSOFT.COM. If you simply forward it back to the list, using
a mail command that generates "Resent-" fields (ask your local user support or
consult the documentation of your mail program if in doubt), it will be
distributed and the explanations you are now reading will be removed
automatically. If on the other hand you edit the contributions you receive into
a digest, you will have to remove this paragraph manually. Finally, you should
be able to contact the author of this message by using the normal "reply"
function of your mail program.
------------------ Message requiring your approval (25 lines) -----------------
[message body]
-----------------------------------------------------------------------
Figure 6.1. The "editor-header" prepended by default to subscriber contributions
forwarded to the list moderator.
If you leave this paragraph prepended to the message, LISTSERV will strip it
off when it processes the message and to all intents and purposes the message
will appear to have come directly from the original sender. Warning: If your
mail program or client does not generate "Resent-" fields, the forwarded
postings will appear to be coming from you rather than from the original
sender. See Section 6.6 for an alternative if your mail program does not
generate these fields.When you are ready to edit and/or submit the contribution to the list, simply use the "Forward" function of your mail client. You can make any changes you feel are appropriate to the message body, but be sure to read sections 6.2 and 6.3 above before deciding to do so.
LISTSERV includes an optional mechanism allowing you to simply "ok" messages which are then posted with all the correct headers. This option is targeted mainly at list moderators who just approve/reject messages, as opposed to people who actually edit the content of messages. The option is also a good choice if you have a mail client that does not insert "Resent-" header lines into forwarded mail.
To activate this feature, code your list "Send= Editor,Hold" and be sure that you have defined at least one editor who will be in charge of approving the messages. This defaults to the primary list owner if no other editor is defined. A copy of the message on "hold" is sent to the editor with minimal instructions (in order to avoid adding a long message before the text needing approval each time).
To approve a message forwarded to you with "Send= Editor,Hold", simply reply to the approval request and type "OK" as the body of your reply. LISTSERV will normally pick up the confirmation request number from the subject line. If there is a problem, LISTSERV may ask you to resend the approval confirmation along with the number. For instance,
OK 6A943C
If the message has been in the spool longer than the time-out period (LISTSERV holds these jobs for a minimum of 7 days), you will receive notification that the confirmation number does not match any queued job.
If you do not want the message to be forwarded on to the list, you need not do anything. The message will expire automatically at the end of the time-out period and will be deleted from the queue.
List topics provide powerful "sub-list" capabilities to a list. When properly set up and used, topics give subscribers the ability to receive list postings in a selective manner, based on the beginning of the "Subject:" line of the mail header. It is important to note the following points about topics:
* Topics= topic1,topic2,...topic11
And the basic syntax used to set topics for users once they have been defined is:
SET listname TOPICS: xxx yyy zzz for userid@host
where xxx, yyy, and zzz can be:
Finally, it is important to note that topics are active only when the subscriber's subscription is set to MAIL. Digests are indexes always contain all the postings that were made, because the same digest is prepared and sent to all the subscribers.
With the "Default-Topics=" keyword, you can also set default topics for users that will be effective as soon as they subscribe to the list. For instance,
* Default-Topics= NEWS,BENCH,OTHER
would set the new user to receive topics NEWS, BENCHmarks, and any messages that are incorrectly labeled.
See Appendix B for more information on setting up and using list topics.
When a user subscribes and signs off of a list, LISTSERV looks for list owner-supplied files called listname WELCOME and listname FAREWELL, respectively. If found, it sends the user a copy of the appropriate file in addition to its own administrative message. The WELCOME and FAREWELL files allow the list owner to send a more personal message to the user that can help set the tone for how the list is used. The WELCOME file may contain information about the list charter and netiquette rules, or be simply a message welcoming the user to the list. The FAREWELL file can be used to gather feedback about how the list is serving users.
The procedure differs slightly on VM systems, but the following will work for unix, VMS and Windows systems:
Here is the format of a very simple WELCOME file. (Note that the FAREWELL file is created and stored in an identical manner.)
----------------------------------------------------------------------- PUT SONGTALK WELCOME PW=XXXXXXXX Subject: Welcome to Songtalk! Welcome to Songtalk, the list for Songwriters talking about their work. Your list owner is Susan Lowell (susan@lsoft.com). ----------------------------------------------------------------------- Figure 6.2. Sample WELCOME file.
The WELCOME file should contain information geared toward orienting the new subscriber to several areas. The outline of a suggested WELCOME file follows:
Users new to the use of L-Soft's LISTSERV are encouraged to read the online files LISTSERV REFCARD and LISTSERV GENINTRO, which can be obtained by sending the following commands in the body of a mail message to LISTSERV@LISTSERV.NET:
INFO REFCARD
INFO GENINTRO
The following FAREWELL file is used on ACCESS-L@PEACH.EASE.LSOFT.COM, and is intended as a tool to get feedback from users. ACCESS-L's list owner typically receives 3-5 responses to this message each week.
----------------------------------------------------------------------- Subject: Your ACCESS-L Signoff Request I'm sorry to see that you're leaving ACCESS-L. If there is anything you believe ACCESS-L should have offered but didn't, or there are any other suggestions you may have for the list, please feel free to write directly to me. Sincerely, Nathan Brindle <nathan@ubvm.cc.buffalo.edu> ACCESS-L List Owner ----------------------------------------------------------------------- Figure 6.3. FAREWELL file used as a feedback tool.
It is possible to modify LISTSERV's default mail template so that only one message is sent to users when they subscribe and unsubscribe, rather than an administrative message from LISTSERV and a WELCOME or FAREWELL file from the list owner. See Chapter 9 for the details on modifying the default mail templates.
However, it is likely that the average list owner will prefer to use the WELCOME and FAREWELL files over changing the more-complicated templates. Thus both avenues are provided, and may be used depending on the list owner's level of comfort.
Like so many other things, network users tend to expend a great deal of virtual gunpowder about the subject of etiquette on the network (otherwise known as netiquette). Part of the culture of the network is built on the fact that an individual user can put forward any face he or she cares to present. Thus over time, the network has evolved various sets of rules that attempt to govern conduct. To avoid taking up a great deal of space arguing the merits of differing systems of netiquette, the following general pointers that should be accepted by most users are offered for the convenience of the list owner.
Recognize and Accept Cultural and Linguistic Differences
The Internet is international, and while English is generally accepted as the common language of the network, list owners and list subscribers cannot afford to take the position that everyone on the Internet understands English well. In a medium that is invariably connected to language, special understanding is required to deal with questions or statements from people for whom English is not the primary tongue. Often today (at least in the US) a person's first sustained interaction with others on an international basis is via the Internet. It is imperative that this interaction be on the highest level of cordiality and respect from the outset in order for all concerned to benefit.
Additionally, care should be taken when using local idiom and slang. A common word or phrase used by Americans in everyday speech, for instance, might be taken as profanity or insult by those in other English-speaking countries, and may not be understood at all by non-native speakers of English. When a list has a high international readership, it is probably best to avoid non-standard English so as to provide the clearest and least-objectionable exchange of ideas.
Private Mail Should Dictate Private Responses
If someone on a mailing list has sent a private message to you (i.e., not to the list at large) and you have lost that person's address but want to respond, do not post private mail to the list. The REVIEW command will give you a copy of the list membership that you can search for the person's address. If this approach does not work, contact the local postmaster or the list owner for help.
Flaming is (Usually) Inappropriate
Flames (insults) belong in private mail, if they belong in mail at all. Discussions will often result in disagreements. Rebuttals to another person's opinions or beliefs should always be made in a rational, logical and mature manner, whether they are made publicly or privately. What is a flame can range from the obvious (ranting and raving, abusive comments, etc.) to the not-so-obvious (comments about how many "newbies" seem to be on the list these days, "RTFM!" exhortations, etc.).
Foul Language
Subscribers should refrain from abusive or derogatory language that might be considered questionable by even the most liberal and open-minded of networkers. If you wouldn't say it in front of your mother, don't say it in electronic mail.
Unsolicited Advertising and Chain Letters
Most of these are contrary to appropriate use policies governing the use of the poster's Internet access provider. Not only that, they are annoying and (in the case of chain letters) often illegal. See Section 6.10 on the subject of "spamming" for more details.
Other Disruptive or Abusive Behavior
Self-explanatory. It is rarely possible to catalog all forms of anti-social network behavior. Be sure that you as a list owner cover as many bases as you think necessary when promulgating a code of netiquette for your list. Then - be sure to adhere to it yourself.
"Spamming" is a network term invented to describe the act of cross-posting the same message to as many newsgroups and/or mailing lists as possible, whether or not the message is germane to the stated topic of the newsgroups or mailing lists that are being targeted. A "spam" is defined therefore as either (1) a specific act of spamming, such as the so-called "Green Card Spam", or (2) the message that actually comes to your list as a result of someone initiating a specific act of spamming ("The message you just saw was a spam, and it should be ignored"). Spams are fairly easy to recognize at a quick glance; they often have "To:" fields directed to large numbers of lists, usually in alphabetical order.
If a spam gets through to your list, it will probably engender sarcastic replies (often with the spam quoted in its entirety) - and if your list is coded "Reply-To= List", they will likely come back to the list. It is therefore imperative that you make subscribers aware that when a spam occurs:
If this does not work and subscribers send their complaints to the list anyway, it might be a good idea to moderate the list for a few days until the furor dies down.
LISTSERV attempts to detect "spams" using a variety of proprietary methods. When LISTSERV decides that a message is a spam, it locks out the user for 48 hours, worldwide in the case of backbone servers.[3] While locked the user is still able to use LISTSERV normally and to post to mailing lists, but all messages will be forwarded to the list owners for human verification. The user is informed that this has happened but is not informed of which lists caught the message and which didn't, denying him any idea how successful he has been.
L-Soft will not document how LISTSERV decides a message is a spam because the point has been reached where a number of authors are writing and selling books detailing how to avoid such precautions. If L-Soft were to document its methods, the next editions of these books would simply include updated instructions on how to bypass them.
As a list owner, it is important that you take into consideration any appropriate use policies that might apply to your list. For instance, if your list is hosted by an educational site that has a policy restricting mail with commercial content from being sent out by its users, your list will technically be in violation of that policy if it distributes mail from users advertising commercial services. You would be well advised to request a copy of the appropriate use policy (if any) from your host site and make sure that your subscribers are aware of it by including pertinent sections in your WELCOME file and/or your administrative postings.
Host sites are not the only entities that might have appropriate use policies. The network your host is a part of may have such policies as well.