Owners

How to create a list

The first step is to define to which topic or group the list will be dedicated. Most ETSI lists will be created for a working group, STF, ETSI Project or TC, but a list could also be based on a subject of interest to multiple groups.

Section 3 describes the basic keywords needed to define your list and proposes default values for many of them. Once you have decided on the options for your list, you can create it either by completing the form (under construction) or by contacting the HELPDESK at e-mail Helpdesk@etsi.org.

When you are satisfied with the options for your list, send your request to sitemanager@etsi.org

How to use this section

If you follow the recommendations below you will have a list which balances security and workload. There are over fifty options which you can set for your list. Not all the all commands and options are described below - just the most common and most useful.

The basics

Description

The first thing you should choose for your new list is a description of up to 40 characters.

Password

You should also choose a password for your list. This password will be used to change the list options. It is not needed to send messages to the list. The password should be eight characters and ideally should include at least one digit. The List Password section explains what the password does.

Identifying the Owner(s)

At least one owner must be specified for each list. It is usually the person who requested that the list be created in the first place. The owner has the power to decide how the list will be run and responsibilities to ensure it works smoothly. The details of what the owner can and must do depend on the options he has selected for the list.

A list may have more than one owner. In fact, to ensure smooth operation of the list during holidays etc., it is recommended to have at least two owners.

Subscription options

Public, closed and private lists

SUBSCRIPTION= can be OPEN, BY OWNER or CLOSED.

If subscriptions are OPEN then the list will be public in that any request to join will be accepted.

When subscriptions are BY OWNER, all subscription requests will be forwarded to the owner(s) who can accept them or ignore them. This is the recommended setting for ETSI lists.

If subscriptions are CLOSED, requests to subscribe to be automatically rejected.

Validating subscribers’ e-mail addresses

One of the biggest headaches for list owners is dealing with "bounces", or mail which cannot be delivered. One way to reduce the number of bounces is to ensure that the e-mail address of new subscribers can be reached.

If the CONFIRM option is specified, LISTSERV sends a message containing a random six character code to any person who tries to subscribe. The code is sometimes referred to as a "magic cookie". In the message it asks the user to send the word "OK" and the code back to LISTSERV. Users normally have 72 hours to reply.

If LISTSERV does not receive the message containing the code, it will not accept that person. The reasoning is that if the person did not receive the request to return the code, then there is a problem with their e-mail address and they wouldn’t receive the mail from the list either.

You can specify the CONFIRM option with the OPEN and BY OWNER commands. E.g.

SUBSCRIPTION= BY OWNER, CONFIRM

Notification

NOTIFY= Defines whether or not (or to whom) subscription notification is sent. It is useful to keep multiple owners informed of subscription conformations etc. made by other owners.

NOTIFY = can be set to "NO" for no notification, "YES" for the owner(s) to receive notification, "OWNER", indicating the first or main list owner, "OWNERS" indicating all list owners, or a single e-mail address e.g. HIM@EMAIL.ADDRESS to notify to that individual. The recommended setting is

NOTIFY = OWNERS

Renewing subscriptions

Over time the list of participants will change. New people will become interested and others will move on or will concentrate on other things. As the list grows the potential for problems will increase. One way to control this is to remove subscribers who are no longer interested in your list. This can be done by asking all subscribers to renew their subscription every so often. The renewal keyword lets you specify how often LISTSERV will ask your subscribers to renew their subscription and how many days they have to confirm that they wish to remain on the list. The recommended value is:

RENEWAL=3-MONTHLY, DELAY(25)

which tells Listserv to request a renewal every 3 months and to remove any subscriber who hasn’t responded within 25 days. The renewal frequency can be set to monthly, yearly, weekly, or a numeric variation e.g. 3-monthly. Small stable lists may consider setting RENEWAL=NO.

It is possible to waive subscription renewal for certain users (such as list owners). In order to do this, add the command :

SET listname NORENEW FOR him@e-mail.address

You can add this line for each person whose renewal is to be automatic.

Security - passwords, validation and confirmation

Many of the list keywords can only be changed via a message coming from the list owner. However, recognising that mail can be forged, L-Soft™ has introduced some additional levels of security for LISTSERV.

List Password

New lists have a password defined when they are created. When sending the list back to the server, the password is prefixed to the list file for validation. For security reasons the PW= parameter is "invisible" once it is defined; i.e., it does not appear, either when the list is reviewed, or when it is retrieved with a GET command by the list owner.

Validating list modification commands

The VALIDATE= command determines which commands require the password.

When VALIDATE= NO, all commands except PUT are taken at face value with no validation. While users are not bothered with validation requests, the list is totally unprotected from attacks by hackers.

When VALIDATE= YES, commands such as DELETE or ADD, require password validation. For list owner commands, both personal and list passwords are accepted. Some user commands may accept a personal password, while others will cause the request to be forwarded to the list owners for verification.

On the Internet it is relatively easy to forge a message to make it appear to have come from someone else (such as a list owner) but it is much more difficult to catch a specific mail message intended for someone else. When VALIDATE=YES is specified, an additional level of security can be added to counteract such forgeries.

If the CONFIRM option is specified, LISTSERV sends a message containing a random six character code to any person who tries change the list options. The code is often referred to as a "magic cookie". In the message it asks the person to send the word "OK" and the code back to LISTSERV. If the request was contained in a forged message, the person whose address was forged will be alerted when they receive a request to confirm of a command they did not send, and the forger will not know the code needed to make the confirmation.

If the original message contained the list password, LISTSERV does not always use the "magic cookie" confirmation, but can be made to do so if the additional parameter , NOPW is also defined.

In summary

VALIDATE=NO - all commands except PUT are automatically accepted - Should not be used.

VALIDATE=YES - all "protected" commands need password validation. This option is acceptable for lists if the owner wishes to reduce his work load and the topics are not sensitive.

VALIDATE=YES,CONFIRM - protected commands are validated using the "OK" mechanism by default, although passwords are also accepted where appropriate. This is a good compromise between list security and list owner convenience.

VALIDATE=YES,CONFIRM,NOPW - protected commands are validated using the "OK" mechanism. Passwords are not accepted, as they are not as safe as "cookies". This is the recommended setting for secure lists.

Viewing the membership of a list

Anyone who knows the e-mail address of the ETSI mail server can request a list of lists with the LIST command and then request a list of the people subscribed to each list with the REVIEW LISTNAME command. Such information is frequently used for compiling mailing lists for junk mail. One way to avoid this is to set your list to REVIEW=PRIVATE which means that only other members of the list can see the list of subscribers.

Confidential lists

CONFIDENTIAL= NO is the recommended value and indicates that the existence of the list should not be hidden from users. If you hide the list, it is difficult for new subscribers to join. A confidential list will not appear on the LIST command output. YES means that the list is unconditionally confidential. A third option, SERVICE, is not applicable to ETSI.

Note that a list can not be hidden from its own subscribers and list owner(s).

Posting to the list

The SEND= command defines who can send messages to the list. The recommended setting is SEND= PRIVATE for most lists which means that only subscribers can post to the list. If your list is to be used only for dispatches or announcements you may consider SEND= OWNERS or SEND=him@e-mail.address.

Mail/digests and archives

Archives / Indexes

With archived lists, a copy of each message is kept and members may order a list, or index, of stored messages and then order the actual messages which are of interest. Instructions on how to get archived messages are given in the users guide.

The recommended settings to configure your list to keep archives is

NOTEBOOK= YES,ARCHIVELOCATION,MONTHLY,PRIVATE

NOTEBOOK= YES tells Listserv to keep archives for your list. The ARCHIVELOCATION is only of concern to the site manager and will be defined by him. MONTHLY tells LISTSERV to create a new archive index every month, and PRIVATE means that only subscribers to your list can order archives.

Digests

By default, when someone sends a message to a list, it is distributed to the other members as soon as possible. You can also provide the option for a member to receive all the messages for a period together in a single file. This "batch" of messages is called a digest. In fact, it is not a digest in the normal sense of the word, as the contents of the messages are not condensed or modified in any way. They are simply sent together. The following settings are recommended.

DIGEST= YES, DIGESTLOCATION,DAILY,04,1000

DIGESTLOCATION will be defined by the site manager. DAILY tells LISTSERV to send a digest of each day’s messages. Other alternatives include WEEKLY and MONTHLY. 04 tells LISTSERV to send the archive at 04:00 hours (or, on the fourth day of the week, or day of the month). The final parameter, 1000, tells Listserv the maximum number of lines it should allow for a digest. This is to avoid problems for some e-mail systems which cannot handle very large messages. If a digest reaches this size, a "special edition" digest will be issued at that time, and the remaining messages will be sent in the normal digest at the usual time.

Dealing with bounces

Bounces are the messages returned to you when your list tries to send to an e-mail address which is not accepting mail for one reason or another. It may be that the persons mailbox is full, that the server has problems, that the person doesn’t work for that company any more.

The ERRORS-TO=OWNERS keyword defines that the owner of each list deals with the non-delivery messages for their own list.

So what can you do about these bounces? The problem is the same as dealing with non delivery messages from individual messages. Only the scale is different. Read the message carefully, try to understand it and act accordingly.

The good news is that you can configure LISTSERV for automatic deletion of users whose account has expired or whose system has been permanently disconnected. The recommended settings are

AUTO-DELETE= YES, SEMI-AUTO,DELAY(4),MAX(100)

SEMI-AUTO means that LISTSERV looks for "permanent" errors (no such user, no such host, and so on). If the failing addresses are on the list, (the errors can also come from a forwarded address) LISTSERV removes them and notifies you. The list owner should decide if they need to contact the person or organisation to get a new e-mail address. If LISTSERV cannot understand the delivery error, it is passed to the list owner.

The default DELAY() is 4. This is the number of days that LISTSERV will wait before a subscriber is automatically deleted. If DELAY(0) is coded, LISTSERV won't wait. If DELAY(4) is coded, LISTSERV will delete the user if it detects errors 4 days after the initial error, even if there were none in the intervening period. Most delivery errors occur on weekends when systems are taken down for maintenance or system administrators are not around to reboot after crashes. Because of this, most delivery errors only last for 2-3 days and may not be "permanent" even if they seem to be at first.

To prevent auto-delete monitoring from getting out of hand, subscribers are deleted after a specified number errors regardless of the number of days. The default is a generous MAX(100).

If there are permanent errors for users LISTSERV could not find on the list, (e.g. because the address on the list forwards mail to another address), or if there are only "temporary" errors (host unreachable for 3 days, system error, disk quota exceeded, and so on), LISTSERV passes the message to the list owner.

If MANUAL is set, the auto-delete monitor informs the list owner of the error(s) and takes no further action. A third option FULL_AUTO should not be used for ETSI lists as it slows down e-mail delivery.

During a public holiday period it is best to switch auto-delete to MANUAL. Do NOT restore to AUTO on the first day back. Wait DELAY+2 days before changing back to SEMI-AUTO, to allow others some time to fix the problems which may have occurred during the holiday.

If you have a subscriber who has intermittent problems you can send him all messages for a period in a single digest, thus reducing the number of messages he receives and therefore the potential for non-delivery messages. Use the following command:

SET listname DIGEST FOR him@e-mail.address

Creating the list

Once you have decided the options for your list, you can create it by copying either the template for the discussion list or the dispatch list and send this to helpdesk@etsi.org.
The sitemanager will contact you when the list has been created, normally within one or two days. You can then populate your list, either by asking potential list members to subscribe (see the Subscribers Guide for details), or by using the ADD command described in the Adding and deleting subscribers section below . Don’t forget, owners are NOT automatically members of the list. You must subscribe or add yourself if you want to receive the list correspondence.

Discussion list or dispatch list

Discussion list

* listname : sample description for listname
* Owner=name@email.address (some one)
* Subscription= by owner, confirm.
* Renewal=6-monthly,delay(25)
* SET listname NORENEW for name@email.address
* Validate= YES,CONFIRM
* Review= Private
* Confidential= No
* Send= Private
* Notify= Owners
* Errors-To= Owners
* Auto-Delete= Yes, Semi-Auto,Delay(4),Max(100)
* Notebook= yes,d:\etsi\"type"\name of list,monthly,private
* Digest= yes,d:\etsi\"type"\name of list,daily,01,1000

Dispatch list

* listname : sample description for listname
* Owner=name@email.address (some one)
* Subscription= by owner, confirm
* Renewal=6-monthly,delay(25)
* SET listname NORENEW for name@email.address
* Validate= YES,CONFIRM
* Review= Private
* Confidential= No
* Send= Owner  ( Or any member )
* Reply= Sender
* Notify= Owners
* Errors-To= Owners
* Auto-Delete= Yes, Semi-Auto,Delay(4),Max(100)
* Notebook= yes,d:\etsi\"type"\name of list,monthly,private
* Digest= yes,d:\etsi\"type"\name of list,daily,01,1000

How to get people on to your list

Do not forget to advertise that your list is now available.