Depending on your own preferences, some requests from subscribers for operations that they can perform for themselves can be fulfilled by you as the list owner or by the subscribers with some coaching from you. While it is a negative approach, the list owner can never assume that the subscriber reads or saves the materials sent to him at the time of subscription. Therefore, you will have to deal on a regular basis with users who ask how to unsubscribe, or how to get archive files, or how to set their subscription to DIGEST or NOMAIL.
If a user asks a question about a topic that has been discussed previously, you might suggest in a tactful way that the answer can be found in the archives. If your host server supports the LISTSERV database functions, you might even include a sample DATABASE JOB that the user can "clip and send" to LISTSERV.
Often it is tempting to simply "get things over with" and take care of the user's request in many cases – the user wants to be set to NOMAIL because he's going on vacation, the user wants off the list, etc. – but while this solves the short-term problem, it doesn't teach the user anything. Naturally it takes more time to be a coach than it does to be the all-powerful list administrator, but the goodwill you can create by being proactive rather than reactive outweighs the convenience of simply sending the command yourself. You will find that many subscribers appreciate the fact that someone takes the time to explain the complexities of LISTSERV to them.
In order to cut down on the time it takes to respond in "coaching" situations, many list owners prepare "boilerplate" files with the answers to common questions that they can simply "cut and paste" into return mail. (Several such "boilerplate" files are included in Appendix C.)
By default, LISTSERV's internal loop-checking routines look for anything in the body of a mail message that looks like a header line – specifically anything that looks like a "To:", "Sender:", or "Reply-To:" header line. If it finds anything like this, LISTSERV intercepts the message and sends it to the list owner (or the person(s) designated by the "Errors-To=" keyword) as an error.
Often a user who replies to list mail includes all or part of the message he is replying to as part of his reply ("quoting"). While this is a questionable practice to begin with, unfortunately a number of popular mail programs make it worse by including the quoted message in its entirety (including header lines) in the body of the reply. For instance, the following message ended up in the author's error mailbox:
The problem with this reply was two-fold, from a list owner's standpoint. First (a netiquette issue), the sender didn't bother to remove unnecessary header lines from his reply. If properly formatted, however, this would not normally cause an error.
Second, the mail software he was using didn't include ">" characters at the beginning of every line of the included message. Had it done so, the message would have passed through LISTSERV unhindered.
One variation on this error is mail software that quotes messages by adding the ">" character followed by a space for esthetic reasons. For instance, using the above error as an example:
The ultimate solution to the problem is to warn subscribers to limit their quoting to a minimum, and in any case to be sure to delete anything that looks like a header line in the body of their reply.
Firewalls on the Internet are set up for essentially the same reason firewalls are designed into buildings and automobiles – to keep dangerous things (in this case, hackers, viruses, and similar undesirable intruders) from getting in and wreaking havoc with sensitive data. Unfortunately, they don't always keep people from behind them from sending mail out, and this can cause problems when users from such sites attempt to subscribe to lists.
If your list is set to confirm all subscriptions with the "magic cookie" method ("
Subscription= Open,Confirm"), you will receive an error message any time a user from a firewalled site attempts to subscribe, since the "cookie" confirmation message will bounce off the firewall. If your list is not set to confirm subscriptions, the same user will be able to subscribe to your list but all mail sent to him will bounce.
Some firewalls reportedly can recognize "friendly" LISTSERV mail and let it through, but because of security considerations, it is unlikely that this problem will ever completely go away. Thankfully it does not seem to be a major cause of mailing list errors.
LISTSERV expects list files to be delivered to it without any formatting characters (excluding, of course, the carriage return-line feed at the end of each line). This can cause a problem if you try to store the entire list (header and subscribers) using a mail client that inserts line-wrap characters into text longer than 80 columns. Specifically, one client that does this is Pine; others that can cause problem are cc:Mail and just about any Windows POP client.
Note: This is an unsupported utility. You will need to compile it with a C compiler (not supplied). The utility is primarily for users on unix systems, although with two minor modifications it can also be used on 32-bit Windows systems.
