Table of Contents Previous Next Index

Section 4 List and Subscriber Management

Section 4 List and Subscriber Management
The List Management menu on the Toolbar gives you a variety of features for working on and maintaining your lists and subscribers.
4.1 Using the List Management Dashboard
The List Management Dashboard is one of the screens that may appear when you log in. (This is determined by your preference settings.) If it does not appear, then you can open the dashboard by clicking List Management, and then List Dashboard.
The top part of the List Management Dashboard is divided into two sections, providing information and reports about your technical support and lists.
Figure 4-1 List Management Dashboard - Top Half
Each section uses icons to indicate its status and available actions:
Green Shield with a Checkmark – This icon means that you are current. Note that in the Moderation section this icon mean that there are no messages pending moderation.
Orange Diamond with an Exclamation Mark – This icon means that something requires attention. Note that for the Moderation section, this icon means that there are messages pending moderation.
Life Buoy – This icon is used if the Server Administrator has enabled technical support, making it easy and convenient to send requests to L-Soft support. Once you click on this icon, an email message opens. Enter any information describing your problem. Please be as detailed as possible.
The Technical Support section shows whether or not the Server Administrator has enabled technical support. If it is enabled, then the Life Buoy icon is shown, making it easy and convenient to send requests to L-Soft support. Once you click on this icon, an email message opens. Enter any information describing your problem. Please be as detailed as possible.
The Moderation section lists any messages that are awaiting moderation. The messages displayed here are those that belong to a list for which you are listed as a moderator.
Note: This section is only displayed if you are a moderator on one or more lists. In addition, only two icons are used in this section. The green icon indicates that there are no messages pending moderation; the orange icon indicates that there are messages pending moderation.
The bottom part of the screen contains a table that shows list configuration and list activity (changelog) data, which is a combination of the List Report and the List Activity reports. (Note that the list activity data is only visible if a list has changelogs enabled.) By default, the changelog data is not automatically calculated because of the time it takes to process the log files, especially if you have many lists or if they have large log files. To calculate the data, just click on one of the plus signs, [+]. If you would like the changelog numbers to be loaded automatically every time you access the page, you can change the Owner Dashboard Changelogs setting in the Preferences section.
To add or remove columns from the table, click the Edit Table option. This option is a great way to customize the information shown in the table, making sure only the information you want to see is visible. If you customize the table, then your changes will be saved in your preferences and will be automatically loaded every time you log in.
The Lists Per Page parameter controls how many lists will be displayed on a single page. The default is 10. If you want to break the list into 20 lists (for example), then simply enter "20" in the box and click [Update].
The Changelog Period parameter lets you select the date range for the changelog columns in the report. The default is 1 day. If you want to change this period, simply choose a different option from the drop-down menu, such as 14 days, and then click [Update].
Figure 4-2 List Management Dashboard - Bottom Half
4.2 List Configuration
Lists can be configured using a wizard, which guides you step-by-step through the configuration process, or manually.
Figure 4-3 The List Management Menu
4.2.1 List Configuration Using the Wizard
To open the List Configuration Wizard, click on the List Management menu, select List Configuration, and then select List Configuration Wizard.
Tip: To view help for any option in the List Configuration Wizard, simply click on the Help icon associated with it.
4.2.1.1 Descriptions
On the Descriptions Tab, enter the following information:
List Title – A short description of the purpose of the list. The list title must fit on a single line and not exceed 40-50 characters. Choosing a descriptive title is important for public lists because it will be displayed when people search CataList, the online catalog of LISTSERV lists. Potential subscribers should be able to determine the purpose of your list by reading the title. The list title is also used as the "name" part of the list's email address in the mail headers of messages distributed to the list. It is also used in the Web Interface and in some administrative messages.
List Description – Enter a few lines of text containing a brief description of the purpose of the list. This description will be available to anyone who retrieves the public portions of the list header through a "REVIEW listname" command. The list description will also be displayed on the list's home page or archive index.
For the purpose of the Wizard, the list description is defined as any text following the last keyword definition or the last .HH OFF directive (whichever comes last) up to the start of the "HTML description" (if present). If you edit the list configuration header directly, you may enter comments throughout the header (comments are any text that is not a keyword definition or a directive). These will not affect the list description, unless they follow the last keyword definition or .HH OFF directive.
HTML Description – (Optional) If provided, it will be used by CataList, the online catalog of LISTSERV lists. If a text-based list description is not provided, then the HTML description will also be used on the list's home page or archive index. If a text-based list description and an HTML description are both provided, the text-based list description will be displayed by default. This default behavior can be changed by editing the list's OBJECT-A0-LISTDESC template.
To delete an existing list description, check Delete List Description, and click [Submit].
To delete an existing HTML description, check Delete HTML Description, and click [Submit].
Figure 4-4 The List Configuration Wizard - Descriptions Tab
To edit the list configuration manually, click Edit Manually. For more information, see Section 4.2.2 Manual List Configuration.
4.2.1.2 Access Control
The Access Control Tab contains the keywords that define the addresses that have access to specific functions.
The following keywords are available for definition, if applicable:
Attachments – Use this keyword to control the posting of various types of MIME attachments (images, audio, etc.) to you list. It also includes the ability to control the posting of inline uuencoded files to your list on an “on/off” basis; “off” being the default if attachment control is enabled.
For detailed instructions, see the online help by clicking the Help icon associated with Attachments.
Important: The ability of LISTSERV to filter or reject messages that contain MIME attachments is completely dependent on the ability of the poster's mail client to properly identify the MIME attachment when the mail is originally sent. Filtering/rejection is done based on the Content-Type headers found in the message – NOT by evaluation of the actual contents of the attachment. If, for instance, an executable binary (normally Content-Type: application/octet-stream) is sent by the client with a Content-Type of "text/plain", it will not be filtered or rejected by LISTSERV since text attachments are not covered by this keyword setting.
Files – (NJE only; obsolete in other versions) Use this keyword to indicate whether NJE files can be sent to the list or not. The default value is No, which may prevent some non-RFC822 mailer users from posting to lists.
Note: This keyword has absolutely no effect under the non-NJE versions of LISTSERV. Specifically it will not prevent users from sending "attached" (MIME-encoded) files to lists. It is provided under all versions for backwards compatibility only (i.e., for lists being migrated from NJE servers). See the Attachments keyword for attachment blocking.
Filter – Use this keyword to specify how the "filtered" address patterns are to be applied. Select one of the following:
Also – If you want the addresses or patterns entered below to be in addition to the "default" filters set up for the whole server (recommended).
Only – If you want to replace the default filters.
Safe – If you want to use the "safe" filter.
For detailed instructions, see the online help by clicking the Help icon associated with Filter.
Review – Use this keyword to define the categories of users that are allowed to review the non-concealed Internet addresses and names of subscribers to the list. The default is Private.
Send – Use this keyword to define the categories of users who can mail to the list. This can be used to place the list under the control of an editor. The default value is Public.
For detailed instructions, see the online help by clicking the Help icon associated with Send.
Stats – (VM Only) Use this keyword to indicate whether or not statistics are to be maintained for the list. If yes, select which level of statistics is desired and who is able to retrieve the statistics reports. The default value is Normal,Private.
Note: This keyword is obsolete and has absolutely no effect on all ports of the software except for VM. On non-VM servers it is provided for backwards compatibility only (i.e., for lists being migrated from VM) in order that any existing Stats keyword setting in a migrated list header does not trigger a command parser error.
4.2.1.3 Distribution
The Distribution tab contains the keywords that determine the method of distribution for list message.
Figure 4-5 The List Configuration Wizard - Distribution Tab
The following keywords are available for definition, if applicable:
Ack – Use this keyword to define the default value of the "ACK/NOACK" distribution option for the corresponding list, that is the value assigned to new users when they subscribe to the list. This value can be altered by subscribers' "SET" command, but not by users who are not signed on to the list. This means that this option will always be in effect when distributing mail from people who are not on the distribution list.
If Yes is selected, then a short acknowledgment with statistical information on the mailing will be sent back to you.
If No is selected, then no acknowledgement will be sent. This is the default value.
Daily-Threshold – Use this keyword to limit the number of postings that may be processed by the list in a calendar day (midnight to midnight, server time), and, with the addition of an optional second parameter, limits the number of postings that may be accepted from any individual user per calendar day (midnight to midnight in the server's local time zone).
The default is 50. When the value of the first parameter is reached, the list is automatically placed on hold, and the list owner or LISTSERV maintainer must issue the FREE listname command.
Note: It may or may not be advisable to increase this parameter for higher-volume lists – individual list owners should study the issue carefully before increasing the daily threshold of their high-volume lists.
When the value of the optional second parameter is reached by an individual user, the user is told that their posting will not be processed and that they should resend it later if they still want it to be posted. The list itself is not held in this situation. The default is to have no such limit, in which case the second parameter is not defined. List owners and list editors are exempt from the individual daily limit. There is no command to reset the limit for an individual user, although the list owner may update the header to increase the value.
Digest – Use this keyword to control the automatic digestification function allowing subscribers who do not have the time to read large numbers of messages as they arrive to subscribe to a digestified or indexed version of the list. The list owner decides whether digests are available or not, the frequency at which they are issued, and the day of week or time of day when the digest should be distributed.
For detailed instructions, see the online help by clicking the Help icon associated with Digest.
Internet-Via – (BITNET Only) Use this keyword to specify the host to use for routing Internet email. There is no default value. This parameter determines whether or not mail bound for Internet addresses is routed through a specific Internet gateway. In principle this keyword should never need to be set on non-BITNET hosts.
Mail-Via – Use this keyword to specify whether or not to send messages out through the LISTSERV “DISTRIBUTE” network or directly through the local SMTP server. The default is DISTRIBUTE.
Warning: This keyword should generally only be used by the site administrator to troubleshoot delivery problems.
Newsgroups – Use this keyword to define the RFC822 "Newsgroups:" header for a list. This field may be required by certain news gatewaying software and should only be defined if the list is gatewayed to Usenet and the gatewaying software requires it. The default is None.
NJE-Via – (BITNET Only) Use this keyword to determine whether or not mail bound for NJE addresses is routed through a specific gateway. This keyword should never be set on non-BITNET hosts.
Prime – Use this keyword to determine whether or not mail for the list is processed during "prime time", a value that is determined by the LISTSERV maintainer and is kept in the system configuration file. This keyword can be most useful in controlling the load on the machine running LISTSERV. The default is Yes (that is, list postings are distributed at the time they are received).
For detailed instructions, see the online help by clicking the Help icon associated with Prime.
Reply-To – Use this keyword to indicate whether or not the "Reply-to:" tag supplied by the sender of the mail file, if present, is to be preserved or discarded and, if discarded or omitted, what should be placed in the new "Reply-to:" generated by the server. The default value is List,Respect.
Note: Some mailing systems are unable to process a "Reply-To:" field with multiple addresses correctly and may therefore disregard the Reply-to= Both option and treat it as Reply-to= List.
Warning: Setting this parameter guarantees only one thing – that LISTSERV will generate an appropriate RFC822 Reply-To: header in the mail it distributes to subscribers. There is unfortunately no guarantee that the mail transfer agent (MTA) or mail client on the receiving end will honor the Reply-To: header. This is because some mail clients, out-of-office robots, and Internet MTAs either simply do not recognize the existence of Reply-To: or do not implement it properly. Specifically, RFC2076 "Common Internet Message Headers" reports that the use of Reply-To: is "controversial", which is defined as: "The meaning and usage of this header is controversial, i.e. different implementors have chosen to implement the header in different ways. Because of this, such headers should be handled with caution and understanding of the different possible interpretations." (RFC2076, page 4). While L-Soft recognizes that it is sometimes important to provide an explicit Reply-To: header to indicate a response path, L-Soft cannot be held responsible for problems arising from the inability of a remote server to properly process Reply-To: headers.
For detailed instructions, see the online help by clicking the Help icon associated with Reply-To.
Sender – Use this keyword to define the value LISTSERV will place in the RFC822 "Sender:" field. The second parameter is optional, and is included to allow the specification of a second mailbox for use with IETF headers. The first value is used for non-IETF headers and is expected to contain the name and address of the list, or the keywords LIST or NONE. The second mailbox is used for IETF headers; if it is omitted, the generic "owner-listname" mailbox is substituted.
Important: Setting this value DOES NOT change the RFC822 "From:" header. Per standard, LISTSERV is not allowed to change the From: header, but must pass it through unchanged.
Sub-Lists – Use this keyword to specify whether or not lists on this server are sublists of this list, creating a super-list.
For detailed instructions, see the online help by clicking the Help icon associated with Sub-List or see Section 4.2.4 Normal List vs. Super-List.
Topics – Use this keyword to define the topics for this list. List topics provide a way to run a mailing list (preferably moderated) where several sub-topics are being discussed in parallel, but some subscribers are only interested in a subset of the topics.
For detailed instructions, see the online help by clicking the Help icon associated with Topics or see Section 4.2.3 Topics.
4.2.1.4 Error Handling
The Error Handling tab contains the keywords that determine how LISTSERV deals with delivery errors. The following keywords are available for definition, if applicable:
Auto-Delete – Use this keyword to define whether or not LISTSERV should automatically delete users whose account has expired or whose system has permanently disconnected.
For detailed instructions, see the online help by clicking the Help icon associated with Auto-Delete.
Errors-To – Use this keyword to define the person or list that will receive rejection mail for the list. The default value is Owners.
Loopcheck – Use this keyword to determine the type of loop checking performed by LISTSERV to avoid perpetuating mail loops. The default is Full. Loop checking is configured on a list by list basis only.
Warning: ALWAYS USE THIS KEYWORD WITH CAUTION! Misuse of this keyword can and will allow mailing loops onto your list!
For detailed instructions, see the online help by clicking the Help icon associated with Loopcheck.
Safe – Use this keyword to control the email address LISTSERV places in the SMTP MAIL FROM: field, which is where standards-compliant mailers will return delivery errors. When set to No, then these errors are sent to the list address as before, hopefully to be intercepted by the loop detector and passed on to the list owner. When set to Yes, then the error address is set to 'owner-listname', and delivery errors sent to that address are passed on to the list owner without the risk of creating a mailing loop. The default is Yes.
Important: Setting this keyword to Yes does not guarantee that all errors will go to the 'owner-listname' mailbox. Unfortunately, there are many non-compliant mailers which will continue to send the error back to the list (usually because it is listed in the 'Reply-To:' or 'Sender:' field). Setting this keyword to Yes does significantly decrease the potential for mailing loops, but not enough to actually code "Loopcheck= No", unless you are sure that all your subscribers have compliant mailers.
Figure 4-6 The List Configuration Wizard - Error Handling Tab
4.2.1.5 List Maintenance
The List Maintenance tab contains the keywords that control list maintenance and moderation. The following keywords are available for definition, if applicable:
Editor – Use this keyword to define the list editor(s). Enter the email addresses that are allowed to post to the list without moderation. The first address is the "primary" editor and the default moderator and must be a single email address. To give the "editor privilege" to all subscribers of a list (on this server) enter the listname in parentheses, for example: "(MYLIST)".
When used in conjunction with the "Send=Editor" option, it causes all mail sent to the list to be automatically forwarded to the first person listed in the Editor keyword, who will then determine whether to allow it to be distributed to the list. The editors are the only persons (with the list owners) who are allowed to mail directly to the list. ANY editor can send mail to the list while only the FIRST one will receive copies of mail sent to the list (but see also Moderator).
Important: The first editor MUST be an email address that goes to a person, not a file server, list server, mailer, or other automated email address. Specifying a program's mailbox as the primary editor could result in a mailing loop for which L-Soft international, Inc., could not be held responsible.
For detailed instructions, see the online help by clicking the Help icon associated with Editor.
Editor-Header – Use this keyword to define the list editor(s). When used in conjunction with the "Send=Editor" option, it causes all mail sent to the list to be automatically forwarded to the first person listed in the Editor keyword, who will then determine whether to allow it to be distributed to the list. The editors are the only persons (with the list owners) who are allowed to mail directly to the list. ANY editor can send mail to the list while only the FIRST one will receive copies of mail sent to the list (but see also Moderator).
For detailed instructions, see the online help by clicking the Help icon associated with Editor-Header.
List-Address – Use this keyword to determine how LISTSERV announces its list address in the header of messages delivered to the list: NJE vs. Internet address, short vs. long list name, etc. The default options (when neither List-Address or the site configuration LIST_ADDRESS parameter are defined) are long list name and Internet address. A corresponding LIST_ADDRESS configuration option may be added to the LISTSERV site configuration file.
Important: The only effect of the List-Address keyword is to change the way the list identifies itself in list postings, command replies, etc. It does not instruct the mail system to create forwarding entries to support the new name, nor does it establish the specified name as an alias for the list (use List-ID for this purpose). In general, list owners should not use this keyword without first consulting with the LISTSERV maintainer.
List-ID – (VM Only) Use this keyword to define an alternate name (alias) for the list.
Note: List owners should not set a value for List-ID without first consulting with the LISTSERV maintainer, since it will be necessary to add appropriate system mailer aliases before the name specified in List-ID will work.
Moderator – Use this keyword to define which editors of a moderated list receive postings for forwarding to the list. The default is the first editor as defined by the Editor keyword. If multiple moderators are defined, the load is spread across them.
For detailed instructions, see the online help by clicking the Help icon associated with Moderator.
New-List – Use this keyword to define the name of the new list that this list has been migrated to.
Warning: This keyword can only be used on a list that has already been migrated and all other keywords except Owner removed from the list configuration. To prevent accidental deletion of all keywords, this Wizard will not remove the other keywords for you. The easiest way to do this is to go to the List Management page and use the Configuration button to edit the "list header" and remove all the keywords except Owner.
Notebook – Use this keyword to indicate whether or not an automatic log of every piece of mail sent to the list is to be kept, and to define at which interval of time its file name must be changed and who is allowed to retrieve it from the server. The default values are Notebook= No,A,Single,Private. Only a postmaster may set this keyword.
For detailed instructions, see the online help by clicking the Help icon associated with Notebook.
Notebook-Header – Use this keyword to determine whether or not individual messages in notebook archives are stored with full Internet header information or with "short" headers. The default is Short.
Notify – Use this keyword to define whether the list owner (or the person indicated by "Notify=mon-address") is to receive notification of new subscriptions and deletions, etc. The default is Yes, meaning that non-quiet list owners will be notified.
Owner – Use this keyword to define the person or list of persons who "own" the list. They are responsible for controlling access to the list and defining the list control keywords that are best suited to the purpose of the list.
This keyword is required in every list and there is no default value. Any combination of explicit network addresses and complex access-levels is acceptable, for example: Owner= BIG@BLUE,(STAFF-L),Owner(MAIN-L)
Note: The use of the "Quiet:" parameter causes all subsequently defined list owners to be excluded from receiving any delivery error messages or other administrative mail from LISTSERV.
Peers – Use this keyword to define the list of all the servers in the world that are peer-linked to the list, either directly or via one or more other peer servers. This information is used by the various list management commands to determine the "nearest" peer list to a given user. For example, when a SUBSCRIBE command is received from a user and it is determined that there is a nearer peer list for that email address, the subscription request is automatically forwarded to the appropriate LISTSERV.
Renewal – Use this keyword to control whether or not subscribers are required to renew their subscriptions on a regular basis, and what the subscription period is. Multiple renewal times can be set. Each renewal time can be specified as an interval or a set date.
For detailed instructions, see the online help by clicking the Help icon associated with Renewal.
Sizelim – Use this keyword to indicate the maximum size for acceptable messages to be posted to the list (larger messages will be rejected). A plain integer represents the size as a number of lines; add "K" or "M" after the integer to represent kilobytes or megabytes.
Subject-Tag – Use this keyword to define the text to use in lieu of the listname in the subject line for subscriptions set to "SUBJECTHDR".
For detailed instructions, see the online help by clicking the Help icon associated with Subject-Tag.
X-Tags – Use this keyword to indicate whether or not "X-To:" and "X-cc:" tags are to be included in the output mail files to list recipients of the original mail file (other than the list userid), and how they should appear in the RFC822 header.
4.2.1.6 Security
The Security tab contains the keywords that control list security. The following keywords are available for definition, if applicable:
Change-Log – Use this keyword to indicate whether or not to maintain a subscription changelog. This is required if you want to be able to produce historical and statistical reports about subscription activities.
For detailed instructions, see the online help by clicking the Help icon associated with Change-Log.
Confidential – Use this keyword to indicate whether or not the list should be hidden from users. A confidential list will not appear on the "Lists" command output. "Confidential= No" is the default value and indicates that the list is not confidential. "Confidential=Service" indicates that the list is to be hidden from users who are not in the list's service area (see "Service=" keyword) but not from other users. "Confidential= Yes" means that the list is unconditionally confidential.
Note: The local list of (public) lists can be retrieved only by those users who are considered local, per the setting of the server-wide LOCAL= variable in LISTSERV's site configuration file. All other users will be told that none of the lists on the server are visible via the LISTS command, and will be referred to the use of the LISTS GLOBAL search-text command or to the CataList. This is regardless of the setting of Confidential=.
Exit – Use this keyword to define the name of the exit program to be used with this list. Only a Site Administrator may set this keyword.
For detailed instructions, see the online help by clicking the Help icon associated with Exit.
Local – Use this keyword to define the nodes that are to be considered as 'local nodes' for service area checking. The LISTSERV machine is automatically considered as a 'local node' and does not have to appear in the list. Subscribers from any of the local nodes will receive separate pieces of mail with a single recipient in the "To:" field – in other words, they will never receive a grouped piece of mail as non-local recipients would if there are more than one recipient in their node. 'Node' is a generic term that means "anything after the '@' sign in the network address". For instance, "SEARN" and "SEARN.SUNET.SE" are both valid node names. By default, this keyword takes its value from the LOCAL variable in LISTSERV's site configuration file.
PW – (Peered Lists Only) Use this keyword to define the list password. When sending the list back to the server, the password is prefixed to the list file for validation (see the Validate keyword for more specifics). The PW parameter is "invisible" once it is defined; that is, for security reasons, it does not appear either when the list is reviewed or when it is retrieved with a GET command by the list owner.
Note: LISTSERV generates a 16-character random password for lists at list creation time if this keyword is not explicitly defined, making such lists more secure from random hackers. List owners are now encouraged to use personal passwords (defined with the PW ADD command, q.q.v.) in preference to list passwords for this reason. The one exception to this keyword's obsolescence is when you are creating peer lists. Peers must have the same PW keyword so you cannot use the LISTSERV-generated random password when creating peers.
Service – Use this keyword to specify a limited service area for this list (leave blank to allow subscriptions from anywhere).
For detailed instructions, see the online help by clicking the Help icon associated with Service.
Validate – Use this keyword to determine what level of validation (if any) is performed for various LISTSERV commands that apply to individual lists. There are six different settings ranging from very basic to very strict. The two most common settings are Yes and No.
For detailed instructions, see the online help by clicking the Help icon associated with Validate.
4.2.1.7 Subscription
The Subscription tab contains the keywords that control subscription to the list. The following keywords are available for definition, if applicable:
Confirm-Delay – Use this keyword to define the number of hours to hold subscription requests awaiting confirmation.
For detailed instructions, see the online help by clicking the Help icon associated with Confirm-Delay.
Default-Options – Use this keyword to define the subscriber options that will be the default for all new subscribers. Separate options with commas.
For detailed instructions, see the online help by clicking the Help icon associated with Default-Options.
Default-Topics – Use this keyword to specify which of the currently defined topics should be assigned to new subscribers by default.
For detailed instructions, see the online help by clicking the Help icon associated with Default-Topics.
Subscription – Use this keyword to define whether or not new users are allowed to subscribe to the list, and if not, whether their subscription requests are to be forwarded to the list owner or not.
For detailed instructions, see the online help by clicking the Help icon associated with Subscription.
Figure 4-7 The List Configuration Wizard - Subscription Tab
4.2.1.8 Other
The Other tab contains miscellaneous keywords that were not covered on the previous tabs. The following keywords are available for definition, if applicable:
Categories – Use this keyword to define the categories to use for searches in CataList.
For detailed instructions, see the online help by clicking the Help icon associated with Categories.
DBMS – (Non-VM Only) Use this keyword to specify whether or not this list is stored in a DBMS. This should only be set by the Site Administrator.
Warning: Do not set this keyword unless the LISTSERV site configuration is set up to work with a DBMS.
For detailed instructions, see the online help by clicking the Help icon associated with DBMS.
Indent – Use this keyword to determine the minimum number of columns allowed for list addresses in response to the REVIEW command. The default is 40.
Language – Use this keyword to define the language in which information mail and messages are to be sent to subscribers of the list. The postmaster must have provided the required data file (called idiom.MAILTPL, where idiom is the name of the language specified by this keyword) to the server. The default is English, which uses DEFAULT.MAILTPL.
For detailed instructions, see the online help by clicking the Help icon associated with Language.
Limits – (ISP Add-On Only) Use this keyword to define specific limits for a list. Currently only the number of subscribers can be limited.
Important: This keyword is available only with the ISP add-on and may only be added or changed by the LISTSERV Maintainer.
Long-Lines – Use this keyword to enable or disable "long-lines" support.
Note: This keyword was added to maintain compatibility with LISTEARN and will be removed in a future version of LISTSERV. The default is Long-Lines= Yes. It is unlikely that this keyword will need to be set for any list.
Mail-Merge – Use this keyword to specify whether or not mail-merge is allowed on this list. Mail-merge must be set by a postmaster as it requires certain site configuration settings. For more information about mail-merge, see Section 4.2.5 Mail-Merge.
For detailed instructions, see the online help by clicking the Help icon associated with Mail-Merge.
Misc-Options – This keyword is a catch-all for certain behavior-modifying options that are not otherwise covered by other, more specific keyword settings. Currently the only options available are as follows:
NO_SPAM_CHECK – Use this option to disable spam scans for a particular list and its associated xxx-request address. (This is only useful if the LISTSERV maintainer has enabled spam-scanning via the SPAM_EXIT feature.)
SUPPRESS_APPROVED_BY – Use this option to suppress RFC822 "Approved-By:" headers that would normally be generated by LISTSERV in messages posted through moderated lists.
IGNORE_EMAIL_CASE or RESPECT_EMAIL_CASE – These options are mutually-exclusive; only one can be defined at a time per list.

When set in a list header, Misc-Options= IGNORE_EMAIL_CASE causes the ADDcommand to ignore the case of the "local part" of list subscriber entries (that is, the part of the address that is to the left of the "@" sign). Although most modern mail clients are configured to ignore the case of the local-part, this behavior technically violates RFC821 which states that local-parts are considered case-sensitive.

When a list is set to Misc-Options= RESPECT_EMAIL_CASE, this tells LISTSERV to operate per RFC821 and treat address fields with differently-cased local parts as different addresses. The option is provided as an override to the site-level IGNORE_EMAIL_CASE configuration variable and does not need to be set to preserve the default unless the site setting has been changed to make IGNORE_EMAIL_CASE the default.
For detailed instructions, see the online help by clicking the Help icon associated with Misc-Options.
Translate – Use this keyword to determine whether or not LISTSERV keeps or removes control characters from files that it distributes. Yes removes control characters; No keeps them. The default setting is Yes.
4.2.2 Manual List Configuration
To configure a list manually, click on the List Management menu, select List Configuration, and then select Manual List Configuration.
Figure 4-8 Manual List Configuration
For those of you who want to configure the list manually, you can edit the list header in its "raw" state. This is only recommended for people who are very comfortable with the format of the LISTSERV list header and know the keywords and their parameters very well.
The list header appears in a multi-line text box that can be scrolled up and down. You simply type in the changes or added lines just as if you were using a regular text editor. When you are finished, click the [Submit] button to submit the changes. If you want to start over, you can click the [Reload] button to reload the header information from the server.
When you submit your changes with the [Submit] button, you will get the same kind of feedback from LISTSERV as you would if you sent a PUT operation by mail. The next screen will either say that the header of the list has been successfully updated, or it will indicate that it has found errors and that the header has not been stored. The feedback page also has a text box containing the header information you've just stored (or tried to store) so if you need to make further corrections to the header, you don't have to back up and start over.
The list header keywords and their parameters are documented in the List Keyword Reference document, in the online help, or (when using the configuration wizard) by clicking the Help icon for each keyword.
4.2.3 Topics
List topics provide a way to run a mailing list (preferably moderated) where several sub-topics are being discussed in parallel, but some subscribers are only interested in a subset of the topics. For instance, a working group might have general discussions, decisions, and messages related to meetings. People who cannot attend the meetings can then opt out of last calls for hotel reservations and discussions about seafood restaurants, whereas people who have no time to follow the discussions can elect to get just the decisions. At any rate, such a compartmented list requires a certain discipline in order to be successful, as the posters must label their messages to indicate which topic(s) they belong to.
Through the Topics keyword on the Distribution tab of the List Configuration Wizard, the list owner can define up to 23 topics for the list. For example:
Topics= News,Benchmarks,Meetings,Beta-tests
Warning: Once set, you must never reorder the Topics keyword.
To save disk space, LISTSERV remembers which topics users have selected through their ordering in the Topics keyword. That is, "News" is "topic number 1" for LISTSERV, "Benchmarks" is "topic number 2", and so on. This means that you can change the name of a topic without requiring users to alter their subscriptions (for instance, you could decide that "Tests" is a better name than "Beta-tests" and just make the change). However, you must never change the order of the topics in the Topics keyword. If you want to remove a topic, replace it with a comma. For instance, to remove the "Meetings" topic, you would change the keyword to:
Topics= News,Benchmarks,,Beta-tests
Topic names can contain any character except space, colon and comma; the use of double quotes or equal signs is discouraged, as they require special attention when coding list header keywords. In addition, topic names may not start with a plus or minus sign, and the words ALL, NONE, RE, OTHER and OTHERS are reserved.
Posters label their messages through the subject field. LISTSERV first skips any possible sequence of 'Re:' keywords, and takes anything to the left of a colon as a list of topics, separated by commas. The posting is considered to belong to all the topics listed before the colon. If none of these topics is valid for the list, it is classified in a special topic, "Other". If some of the topics are valid but others are undefined, the invalid ones are ignored. At any rate the subject field is left unchanged. Here is an example:
Subject: Benchmarks,News: Benchmarks for XYZ now available!
Messages that should be read by everyone can be posted to the special topic "All". Topic names can be shortened to any unambiguous abbreviation. In our example, "Be" is ambiguous because it could be either "Beta-tests" or "Benchmarks", but "Bench" is acceptable.
Subscribers select the topics they wish to receive with the SET command. The syntax is SET listname TOPICS: xxx where xxx can be:
A list of all the topics the user wishes to receive. In that case these topics replace any other topics the user may have subscribed to before. For instance, after 'SET XYZ-L TOPICS: NEWS BENCH', the user will receive news and benchmarks, and nothing else.
Updates to the list of topics the user currently receives. A plus sign indicates a topic that should be added, a minus sign requests the removal of a topic. For instance, 'SET XYZ-L TOPICS: +NEWS -BENCH' adds news and removes benchmarks. If a topic name is given without a + or - sign, + is assumed: 'SET XYZ-L TOPICS: +NEWS BENCH' adds news and benchmarks. The first topic name must have the plus sign to show that this is an addition, and not a replacement.
The colon after the keyword TOPICS: is optional, and TOPICS= is also accepted. Do not forget to include the special OTHER topic if you want to receive general discussions which were not labeled properly. On the other hand, if you only want to receive properly labeled messages you should not include it. ALL does include OTHER.
Important: Topics are active only when your 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.
4.2.4 Normal List vs. Super-List
Using the Sub-Lists keyword on the Distribution tab of the List Configuration Wizard, the list maintainer can define a "super-list" (as in opposite of sub-list), that is, a "container" list that includes all the subscribers in a predefined set of sub-lists. This can be done recursively to any depth. For security reasons, only the maintainer can create a super-list. Concretely, the "Sub-lists=" keyword is protected from owner tampering in the same fashion as "Notebook=". The value is a comma separated list of all the sub-lists, which must all be on the same (local) machine. For instance:
Sub-lists= MYLIST-L,MYOTHERLIST-L
or, if you want to put each sublist on a separate line,:
Sub-lists= MYLIST-L
Sub-lists= MYOTHERLIST-L
The default value for this keyword is null, e.g., to have no sublists.
Note: The super-list and all of its sublists must reside on the same LISTSERV server.
The only difference between a normal list and a super-list is what happens when you post to it. With the super-list, the membership of all the sub-lists is added (recursively) and duplicates are suppressed. Other than that, the super-list is a normal list with its own archives, access control, etc. You can even subscribe to it, and this is actually an important aspect of the operation of super-lists. If you are subscribed to the super-list itself, the subscription options used to deliver super-messages to you are taken from your subscription to the super-list, just like with any other list. All combinations are allowed, and in particular NOMAIL is allowed, meaning you don't want to get messages posted to the super-list. When you are subscribed to multiple sub-lists, on the other hand, things work differently:
NOMAIL subscriptions are ignored. You will get the super-message if you have an active (not NOMAIL) subscription to at least one sub-list. The idea is that the super-message must be equivalent to posting to all the sub-lists, without the duplicates. Since all it takes to get a message posted to all the sub-lists is a single non-NOMAIL subscription, this is how the super-list works. The only way not to get the super-messages is to subscribe to the super-list directly and set yourself to NOMAIL.
The DIGEST and INDEX options are ignored and internally converted to MAIL. The first reason is that, since in most cases the user will be on multiple sub-lists (otherwise you don't need a super-list in the first place), the only safe method to set subscription options for super-messages is by subscribing to the super-list so that there is no ambiguity. The second reason is that, in most cases, super-lists will be used for out of band administrative messages rather than for large volume discussions, so it is actually preferable to have the message sent directly. The third reason is that the super-list and sub-lists may not necessarily offer the same options (DIGEST and INDEX). In particular it is expected that many super-lists will not have archives. If you want a DIGEST or INDEX for the super-messages, you must subscribe to the super-list directly.
Topics, if defined, are evaluated on a per-list basis. That is, for every sub-list (and for the super-list), LISTSERV determines whether the topic of the message is one that you want to see. If not, it acts as if you were not subscribed to this particular list. Roughly speaking, this works very well if all the sub-lists have the same set of topics (or a well-defined set of common topics), and doesn't work well at all if every list has its own set of topics.
4.2.5 Mail-Merge
Advanced mail-merge features are available and can be accessed either by sending specially-formatted DISTRIBUTE jobs to LISTSERV or by using the web administration interface. The web interface is not a "wizard" but simply an interface that allows you to "cut and paste" a mail merge message and select different standardized groups of list subscribers to whom the message is to be sent.
Notes: LISTSERV's mail-merge functionality REQUIRES the use of LISTSERV’s Embedded Mail Merge feature. For more information, see the EMM keyword in the Site Configuration Keyword Reference document. Mail-merge functions are documented fully in the Advanced Topics Guide for LISTSERV.
4.3 List Configuration Task Wizard
The List Configuration Task Wizard guides you through providing digest and index versions of the list, in addition to the usual individual postings. To access this wizard, click on the List Management menu, select List Configuration, and then select List Configuration Tasks.
Make desired changes to each of the keywords on any of the tabs, and then press the [Submit] button. Alternatively, you can click on each keyword to access the Wizard pages for each keyword – these include lengthy explanations about the keywords.
Tip: To view help for any option in the List Configuration Task Wizard, simply click on the Help icon associated with it.
4.3.1 Administrators
The Administrators tab allows you to define the administrative roles for the list.
4.3.1.1 What is an Owner?
Owners are the primary administrators of the list. Email addresses with "owner" privileges may change the configuration and templates of the list, add and delete subscriptions, and change the settings on subscriptions.
Owners also receive email sent to the official list owner address. Unless otherwise specified, they receive notifications of subscriptions, signoffs, and error messages related to the operation of the list.
Some owner addresses may be designated as "quiet" owners. These addresses have all the owner privileges but do not receive any of the owner messages. Each list must have at least one non-quiet owner.
If you are replacing an owner, start by adding the new owner address. Next, make sure that the new address is able to function as an owner before removing the old address from the list of owners. If you make a mistake by first removing the old working address and then discovering the new address does not work, you may have to get the site administrator to fix your list for you.
4.3.1.2 What is an Editor?
On lists set to Send=Editor, editors are those addresses that are allowed to post directly to the list without moderation (that is, approval from a moderator).
On moderated lists where the Moderator keyword is not defined, the first editor listed in the Editor keyword acts as sole moderator.
On all lists, regardless of the value of the Send keyword, editors are not subject to limitations on the number of daily posts to the list, as set by the Daily-Threshold keyword.
The first editor listed in the Editor keyword must be an email address pointing to an individual. Other editors can point to lists on the same server including the current list; in that case, all the subscribers on the list have "editor" privileges. To enter the name of a list, you must enclose just the list name (not the list address) in parentheses.
If you do not specify the Editor keyword, the primary editor is the first listed Owner address.
4.3.1.3 What is a Moderator?
When a list is fully or partially moderated, all messages from "moderated" addresses are sent to the moderator(s) for approval. You can set up your list so that incoming messages go to each moderator in turn in a "round-robin" fashion, or so that all incoming messages go to all moderators.
If you do not specify the Moderator keyword, moderated messages get sent to the primary Editor address.
Messages are moderated in the following circumstances:
4.3.1.4 What is an Error?
Occasionally, problems occur on a list, and LISTSERV needs to know where to send error notifications. If you do not specify the Errors-to keyword, error messages will be sent to all non-quiet owners.
Listed below are a some of the most common circumstances where error notifications might be sent to the address specified by Errors-to (or its default value):
If the list is set to Auto-Delete=Yes, and there have been any delivery errors ("bounces") within the set time period, a "Daily Monitoring Report" is sent every morning.
If an email is received for the list containing mail headers pointing to the list (this may be an indication of a condition that would cause a mailing loop if the post were allowed to be delivered to the list).
4.3.1.5 What is a Notification?
Whenever someone subscribes or is added to the list, or someone signs off or is removed from the list, a notification is sent to the non-quiet owners (if Notify=Yes) or to the address(es) specified in the Notify keyword. To turn off notification of subscription activities, set Notify=No.
4.3.2 Security
The Security tab lets you set the security policies for your list.
LISTSERV's security options are wide ranging, from almost no protection (easiest to administer your list, but also most open to hacker attacks) to total protection requiring validation of each and every command sent to LISTSERV for your list. It is also possible to limit access to various aspects of your list, such as who can subscribe, who can review the list of subscribers, who can access the list archives, and whether the list is publicized in any way.
Security always requires a trade-off with convenience. Tightening up security requires you and your subscribers to go to extra trouble. LISTSERV provides many security options, but leaves the final choice up to the individual list owner. Think carefully in each case: How much does the need for convenience outweigh the need for security, or vice-versa?
4.3.2.1 Levels of Validation
The Validate keyword controls the level of command validation desired for your list. The default, Validate= No, requires password validation only for storing the list on the server. This is often sufficient for general needs. However, when a list is set this way, LISTSERV only compares the RFC822 "Sender:"/"From:" headers against the Owner= keyword(s) in the list header to determine whether or not the person ostensibly sending the commands has authority to do so. Otherwise, at this level, LISTSERV does not validate commands it receives for the list, assuming that the mail it receives is genuinely coming from a list owner. This level of validation does not protect the list from commands issued by hackers who have forged mail in the name of the list owner. If you run a list on a controversial topic or just do not feel comfortable without at least some security, Validate= No is not the best option.
The next level is Validate= Yes. At this level, LISTSERV requires a password for all of its "protected" commands. This password is the sender's personal LISTSERV password as defined by the PW ADD command. The commands protected by this level are those that affect subscriptions or the operation of the list, such as DELETE or ADD. Users will also have to validate most commands that affect their subscriptions, but generally can do so using the "OK" mechanism rather than defining a personal password. Some user commands will be forwarded to the list owner for validation rather than accepting password validation from the user.
The next level is Validate= Yes,Confirm. At this level, LISTSERV will require validation with the "OK" mechanism (see below) by default, but will still accept passwords where appropriate. While the less-secure passwords are still accepted, this is considered a good compromise between list security and list owner and user convenience.
The next level is Validate= YES,Confirm,NoPW. At this level, LISTSERV will no longer accept passwords as validation for protected commands. The logic is that because of the way the "OK" mechanism is implemented, passwords are not as safe as "cookies". This is the recommended setting for lists that must be kept secure.
Two other levels are Validate= All,Confirm and Validate= All,Confirm,NoPW. These levels require "OK" validation for all commands that cause a change in state except for the PUT command. If NoPW is not specified, passwords are accepted where appropriate. With these levels, commands that do not cause a change in state (such as QUERY) do not require validation.
Lists which are set to either Validate= Yes,Confirm,NoPW or Validate= All,Confirm,NoPW may not be managed with the Web Interface, which is password-driven.
4.3.2.2 Subscription Options
You can control subscription requests by use of the Subscription= keyword. By default, this keyword is set to Subscription= By Owner, meaning that all subscription requests will be forwarded to the list owner for disposition. You can also refuse all subscription requests by setting Subscription= Closed.
To code a list for open subscriptions without list owner intervention, use Subscription= Open. If you would like to add protection against forged subscription requests or bad return mailing paths, then use Subscription= Open,Confirm. The latter will cause a subscription confirmation request to be sent to the prospective subscriber, which he or she must respond to using the "OK" confirmation mechanism.
4.3.2.3 Service Areas
Defining a service area is a method of restricting access to your list by hiding it from a LIST GLOBAL command and/or by limiting subscription requests to a defined set of host machines. Limiting access to certain lists can be highly desirable; for instance, keeping a student list for a class section at a university from being advertised or accessible by people all over the world. Without setting certain keywords appropriately, such a list would be visible to a LIST GLOBAL command.
If you wish to simply hide your list from a LIST command, but still allow anyone to subscribe to it if they know it is there, use the keyword Confidential= Yes. Users subscribed to the list as well as the list owner(s) will be able to see the list if they issue a LIST command.
If you wish to hide your list from and refuse subscription requests from users outside the local area, you define two keywords:
Service= some.host.edu
Confidential= SERVICE
Service= can be set to a particular host machine, or a set of host machines or nodes. It can be set to Service= Local, meaning it will use either LISTSERV's global definition of which machines are Local, or the machines defined by the list keyword Local=. If you wish to set Service to Local, you should check with your LISTSERV site administrator to find out which nodes are considered local. If the global definition is not suitable, you can override it by defining the Local= keyword:
Local= bitnode1,some.host.edu,another.host.com
Service= Local
Confidential= Service
If there are many subdomains within your primary domain, you may wish to use the wildcard when defining the Local= or Service= keywords. For instance:
defines the service area as "HOST.COM and all subdomains ending in .HOST.COM".
4.3.2.4 Who May Review the List of Subscribers?
The ability to review the subscriber list may be restricted to either subscribers or to list owners. This is done by setting the Review= keyword appropriately.
To restrict reviews of the list to subscribers only, set Review= Private. This is the default.
To restrict reviews of the list to list owners only, set Review= Owners.
To allow anyone, including non-subscribers, to review the list, set Review= Public. This is not recommended unless your LISTSERV server is operating on an intranet.
You can also restrict reviews to users within the list's service area by setting Review= Service and defining the Service= keyword appropriately.
4.3.2.5 Who May Access the Archives?
Restricting access to the list's notebook archive files is similar to controlling who may review the list. This is accomplished by setting the fourth parameter of the Notebook= keyword to an appropriate value. For instance,
defines a monthly notebook on LISTSERV's A disk that is accessible by anyone. By changing Public to Private, access to notebooks becomes available only to list subscribers. The same access-levels are available for this keyword as for Review=.
Note: The location (second) parameter of the Notebook= keyword may be changed only by the LISTSERV maintainer.
If enabled, notebook archives are private by default.
4.3.2.6 Who May Post to the List?
The Send= list header keyword is the basic control for who may post mail to the list. If the list allows non-subscribers to post, set Send= Public.
For a list that does not allow non-subscribers to post, set Send= Private. Send= Private is the default.
If you want a further level of security for Send= Private, you may set Send= Private,Confirm. This setting requires each poster to confirm (with the "OK" mechanism) that the posting actually came from them. This can help in cases where a hacker might be trying to "spoof" (forge) mail from an otherwise legitimate subscriber. It is not recommended to set this in normal circumstances.
For a list where all posts are forwarded to a moderator/editor, there are three settings:
Send= Editor forwards all postings to the list editor (see the Editor= and Moderator= keywords). This setting allows the editor to make changes before forwarding the message back to the list. In order for the edited message to retain the original sender in the From: header, the editor's email program must be capable of inserting "Resent-" header lines in forwarded mail. If the email program is not capable of this, all such posts forwarded to the list will appear to be coming from the editor, not the original sender. Editors should check with their system administrator to find out whether or not their email program inserts the "Resent-" headers.
Send= Editor,Hold forwards a copy of the posting to the editor but differs from Send= Editor in that LISTSERV holds the posting for a period of time (usually 7 days) until the editor confirms the message with the "OK" mechanism (see below). Unconfirmed messages simply expire and are discarded by LISTSERV, so there is no need to formally disapprove a posting. This method of message confirmation is well suited to lists where it is not often necessary to modify the text of a posting, and also is an excellent work around if the editor's email program does not generate "Resent-" headers in forwarded mail.
Below is a sample of the editor-header for a list set to Send= Editor,Hold:
Date: Tue, 5 Mar 2002 10:47:21 -0500
From: "L-Soft list server at DRAGONFLY.DC.LSOFT.COM (14.3)"
<LISTSERV@DRAGONFLY.DC.LSOFT.COM>
Subject: MYLIST: approval required (XXXXXXXX)
To: Joe ListOwner <joe@PRUNE.EXAMPLE.COM>

This message was originally submitted by jack@UNIX.FOO.COM to the MYLIST list at DRAGONFLY.DC.LSOFT.COM. You can approve it using the "OK" mechanism (click on the link below), ignore it, or repost an edited copy. The message will expire automatically and you do not need to do anything if you just want to discard it. Please refer to the list owner's guide if you are not familiar with the "OK" mechanism; these instructions are being kept purposefully short for your convenience in processing large numbers of messages.
Send= Editor,Hold,Confirm is identical to Send= Editor,Hold except that postings coming directly from an editor must be confirmed (with the "OK" mechanism) by the editor who sent the message. This is the recommended setting for any moderated list or announce-only list because it protects the list from hackers who might try to forge (spoof) mail from a legitimate editor address.
A fourth method, called "self-moderation", exists for lists where subscribers are allowed to post freely, but non-subscriber posts are always sent to an editor for approval. To enable self-moderation, set
Send= Editor
Editor= userid@host,(listname)
Ensure that "listname" is in parenthesis. Self-moderation will catch all posts from non-subscribers, including posts from subscribers who are posting from a different address. For instance, if the subscriber originally signed up as joe@foo.com but is posting from joe@unix1.foo.com, LISTSERV will treat his mail as non-subscriber mail. Self-moderation may require some slight changes in individual user subscriptions in order for it to work seamlessly.
4.3.2.7 Restricting Subscriber Privileges
Another security issue involves protecting the list from people who refuse to play by the rules. LISTSERV includes several different levels of privilege restriction for these users.
The REVIEW personal option setting. By issuing a SET listname REVIEW FOR userid@host command to LISTSERV, you can moderate postings at the individual subscriber level. Postings from subscribers set to REVIEW are passed on to the Editor(s) or Moderator(s) of the list. If neither of these keywords are defined for your list, the postings are passed on to the primary list owner. The person who receives the postings can then determine whether or not to approve them. Note that the subscriber always receives notification that his or her posting has been forwarded to a moderator for approval. This is to avoid the impression that the subscriber's posting has been lost before reaching LISTSERV.
The NOPOST personal option setting. By issuing a SET listname NOPOST FOR userid@host command to LISTSERV, you can prevent a subscriber from posting to the list entirely. LISTSERV will reject postings from these subscribers and will not pass them on to a moderator. As with the REVIEW setting, note that the subscriber always receives notification that his or her posting has been rejected.
The NOPOST and REVIEW options are mutually exclusive.
You may define NOPOST or REVIEW as the default for all new subscriptions by including it in the Default-Options keyword.
4.3.3 Attachments
The Attachments tab allows you to define filtering of email sent to the list based on the contents.
LISTSERV allows you to restrict what types of attachments are allowed to be distributed to your list, put a limit on the size of messages, or even reject or moderate messages based on the mail headers or text of the message.
4.3.3.1 What is an Attachment?
Most email programs allow users to "attach" files to email messages they send. These files may be word processing documents, image files, or something else.
Since email is designed to transport plain text messages (and not image or word processing files), before attachments are sent they must be encoded in some way. The encoded attachment is then received and decoded automatically by the recipient's email program so that it can then be opened normally.
Unfortunately, attachments tend to be large, and sometimes they may contain viruses. For these reasons, many mailing list owners want to restrict the kind of attachments that are allowed on their mailing lists (or forbid them altogether).
There are two common methods that are used to encode attachments, MIME and UUEncoded.
4.3.3.2 MIME Attachments
The first and most common method of encoding is called MIME, which stands for "Multipurpose Internet Mail Extensions".
One advantage of this method of encoding for attachments is that messages containing MIME attachments have to include a description of what kind of file each attachment contains, using the list of types of files given at http://www.iana.org/assignments/media-types/.
By selecting specific MIME types to allow as attachments, you can tell LISTSERV to permit distribution of messages containing images, but not allow messages containing other kinds of attachments, for example.
Unfortunately, sometimes MIME attachments are not encoded correctly by the sending email program, so that the description of what kind of file the attachment is is inaccurate. (It might say that the file is an image when actually it is a spreadsheet document, for instance). For this reason, unless you ban attachments entirely, you cannot guarantee that no unwanted attachments will get through to the list.
It is possible to have plain text MIME attachments, with no encoding or special treatment required. As they are harmless, LISTSERV will not reject messages containing only plain text attachments.
LISTSERV's handling of most MIME attachment types is controlled by the Attachments keyword.
4.3.3.3 UUEncoded Attachments
Another, less common, method of encoding attachments is called "UUEncode".
Messages containing UUEncoded attachments do not include information about what kind of file the attachment contains. As a result, your only options are to allow all UUEncoded attachments or forbid them all.
LISTSERV's handling of UUEncoded attachments is controlled by the Attachments keyword.
4.3.3.4 HTML Messages
One special type of MIME message is the HTML message. HTML (Hypertext Markup Language) is the language used to write Web pages. Many email programs allow users to display and compose messages using HTML. Using HTML to compose email messages allows for more creative messages, including graphics and colorful text, which are not permitted in standard plain text messages.
Unfortunately, not all email programs are able to interpret HTML messages correctly, displaying instead the raw HTML code. Also, in recent years some computer viruses have spread through email using HTML messages. For these and other reasons, some list owners prefer not to allow HTML messages on their mailing lists.
LISTSERV's handling of HTML messages is controlled by the Language keyword.
4.3.3.5 Exchange and Outlook Attachments
Microsoft Outlook and Exchange use their own attachment type, application/ms-tnef. LISTSERV removes these attachments from messages it distributes unless specifically configured not to because they are disruptive to subscribers who use non-Microsoft email clients.
LISTSERV's handling of these attachments is controlled by the Language keyword.
4.3.3.6 Size Limits
One objection to messages containing attachments is that they tend to be large, and therefore may take a lot of time to download. For this reason, LISTSERV allows you to set a limit on the size of the messages it will distribute. This is controlled by the Sizelim keyword.
4.3.3.7 Content Filtering
The CONTENT_FILTER mail template form, if present, contains filtering rules, one rule per line, empty lines ignored. Each rule has the following format:
The prefix, if present, can be a mail header tag (for example "Subject:"); "Header:" to check the whole header; or "Text:" to search the message text. The latter is the default if no prefix is supplied, it is provided in case the pattern contains a colon in the first word. If there are multiple mail header tags with the specified name (such as "Received:"), each such tag is searched and it is enough for one of them to match the pattern. If the requested tag is not present in the header, there is no match. A text search will search every line of the first text/plain part in the message. If there is no text/plain part, there is no match.
Regular comparisons such as those described above are not case sensitive. Patterns are standard LISTSERV patterns: the asterisk is the wildcard character. If there is no asterisk in the pattern, it is replaced with "*pattern*".
The content filter also supports "exact match" comparisons, which are triggered by a double colon. For instance:
There are two significant differences between exact and regular match:
You must supply your own wildcard characters in an exact match (if you want to use wildcards). A regular match will insert leading and trailing wildcards if none are found. Thus, an exact match is the only way to make a comparison without wildcards.
You can make an exact match for the empty string. Empty regular matches are ignored since they map to a wildcard comparison for **, which would be always true. This also makes it possible to apply an exact match to a message that does not contain a specified header. For instance, if you want all messages to contain a (mythical) KABOOM: RFC822 header, with an exact match you can tell LISTSERV to perform one of the content-filtering actions if the the header is not present. This is not possible with a regular match.

Note however that you cannot differentiate a header with an empty KABOOM field from a header with no KABOOM field.
One of the most handy uses for the exact match syntax is to be able to write a rule to reject messages with blank subject lines. For instance:
Subject::
Action: REJECT Please resubmit your message with a non-blank subject.
 
Every rule can, optionally, be followed by an action rule. This has the following format:
Action: ALLOW
Action: REJECT reason
Action: DISCARD comment
Action: MODERATE
The available actions are the same for both regular and exact comparisons. For instance,
The default is "Action: REJECT" with no specified reason.
REJECT means that the message is rejected. The text of the rejection is fetched from the BAD_CONTENT mail template form, with the reason supplied as a variable called &COMMENT.
MODERATE means that the message is to be forwarded to the list editor to be manually approved or rejected.
DISCARD means that the message is to be discarded without further processing; any text following DISCARD is echoed to the LISTSERV log file.
ALLOW means that the message is allowed and all remaining rules are ignored. This could be used in moderated lists to allow certain posters to bypass certain filters, for instance:
In the example above, messages with Subject: lines containing "Out of office" are rejected. Messages containing the text "Click here to be removed" are also rejected UNLESS it came From: joe@example.com.
Note: A compilation of commonly used Internet message headers is available in RFC 2076.

The CONTENT_FILTER is a data template. None of the usual mail template substitutions or commands are valid.
4.3.4 Probes
The Probes tab allows you to configure probing and auto-deletion of bad addresses.
LISTSERV offers very flexible ways to automatically remove address that bounce (produce delivery errors) based on how many times they bounced or how long they have been bouncing. It also offers a mechanism to force subscribers to renew their subscription or be removed. Probing allows LISTSERV to send specially formatted messages so that bounces are handled even if the recipient's mail server is not sending standard bounces.
4.3.4.1 What is Probing?
Probing an address involves sending a unique message to that address (and that address only) to test if the address is valid or if the address generates bounces (messages that are returned to LISTSERV because the address is bad).
Probing is more reliable than other types of bounce collection because sometimes bounces from regular mailing list traffic do not include enough information to determine which subscription was responsible for the bounce.
When LISTSERV probes an address, it generally uses a unique address in its return path; therefore, if LISTSERV receives any mail to the probe address, it is certain that it is a bounce for the probed address.
4.3.4.2 What is Active Probing?
With active probing, a probe message is explicitly sent to the subscribers informing them that their addresses is being probed and usually instructing them to just discard the message. If a probe message bounces, depending on the mailing list's setup, the address may be immediately removed or additional probe messages may be sent to make sure that the address is actually bad.
Generally, if active probes are enabled, then they are sent to subscribers whose subscriptions have been inactive for some time. This allows the list owner to ensure that there are not many old bad addresses set to NOMAIL subscribed to the mailing list.
The PROBE1 mail template contains the initial active probe message. Sometimes list owners will modify the message sent by the active probe mechanism to send information about the mailing list, such as a FAQ, a mailing list charter, or instructions on how to subscribe and sign off.
The follow-up message that may be sent if the initial probe fails can also be modified. It is contained in the PROBE2 template.
4.3.4.3 What is Passive Probing?
Passive probing is another option for testing subscriber email addresses. With passive probing, normal messages that are sent to the mailing list are used as the medium of the probe.
Essentially, when a message is sent to the mailing list, a certain percentage (determined by the Auto-Delete Probe setting) of the mailing list subscribers are sent individual copies of the message with customized return paths. These messages look just like regular mailing list messages, but any bounces generated by them go to the customized probe return addresses. This allows LISTSERV to automatically determine which address each bounce is for, even if the bounce is otherwise in a format that LISTSERV does not understand.
Depending on the setup of the Auto-Delete keyword, the bouncing address may be removed immediately or additional probes may be sent. As with active probes, any additional probe messages that are sent will contain the language in the PROBE2 template.
4.3.5 Digesting and Indexing
The Digest tab guides you through providing digest and index versions of the list, in addition to the usual individual postings.
Normally, LISTSERV sends messages out to subscribers as soon as it receives them, so that the subscribers receive the mailing list messages throughout the day. Some may prefer to get all of the messages at the same time, combined into a single piece of email. Such a collection of messages is called a digest.
Another option, similar to the digest, is for LISTSERV to send the subscriber a list of what messages have been distributed to the mailing list recently, along with information about when the message was posted, how big it is, and who sent it. This is referred to as an index.
4.3.5.1 What is a Digest?
Normally, LISTSERV sends mailing list messages out to subscribers as soon as it receives them, so that the subscribers get messages throughout the day.
Some may prefer to get all of the messages at the same time, combined into a single piece of email. Such a collection of messages is called a digest.
Depending on the volume of messages that go out over a mailing list, it may make sense to have the digest go out once a day, once a week, or once a month.
LISTSERV allows subscribers to get digests in three formats: HTML, MIME, and NOMIME NOHTML. Subscribers can individually choose the format that works best in their email clients. Each email client is different, so subscribers should experiment with the different digest styles to find the one they prefer.
4.3.5.2 What is an Index?
An index, similar to the digest, is another option for receiving one message that summarizes a collection of messages from LISTSERV. LISTSERV sends the subscriber a list of what messages have been distributed to the mailing list recently, along with information about when the message was posted, how big it is, and who sent it.
Indexes are only available for archived mailing lists that have digests enabled. Indexes are sent out at the same time as the digests.
Indexes are available in HTML and NOHTML formats. If HTML is used, the index includes a link to each message in the Archive Interface. If NOHTML is used, the index includes instructions on how to retrieve the messages the subscriber wants.
4.3.5.3 What is a Plain Text Digest?
Plain text is the simplest form of digest. All email programs should be able to read plain text digests without any difficulty. The basic form of this type of digest is given in RFC 1153.
At the beginning of a plain text digest there is a list of the subjects of the messages in the digest:
1. Request for comments
2. Another subject, another ruler (3)
3. Project deadline on Thursday
Note: If the mailing list is used for discussions, typically there will be multiple messages for each subject.
After the topics list, the contents of the DIGEST-H template (if any) will be displayed:
This mailing list is sponsored by XYZ Industries. If you would prefer to receive this mailing list as individual messages instead of as a digest, send a "SET MYLIST MAIL NODIGEST" to listserv@lists.example.com.
After the contents of the DIGEST-H template (if any), the messages will appear in the order LISTSERV received them, separated by lines consisting of 30 hyphens.
Since the digest is plain text, any HTML messages will appear uninterpreted (the raw HTML code will appear) and any attachments will appear in their encoded form. Additionally, any special characters (smart quotes or accented letters, for example) may not display correctly in plain text digests.
4.3.5.4 What is an HTML Digest?
Recipients of an HTML digest who have email programs that are programmed to handle such digests will see an index of the day's messages followed by the contents of the DIGEST-H template (if any).
Clicking on a subject in the table of contents takes you down to the relevant message or messages in the index. Clicking on any of the messages will then take you to the message in question.
HTML digests include information about the content of each message (through MIME); therefore, each message should display normally.
Note: Since the digest includes all of the messages as MIME attachments, all of the links in the HTML digest index are of the form: "cid: content-id" (see RFC 2111 for more information about this type of URL). Unfortunately, some email clients, even some that otherwise support HTML, do not handle such references correctly. For this reason, some subscribers may not be able to use HTML digests.
Figure 4-9 Example of an HTML Digest
4.3.5.5 What is a MIME Digest?
A MIME digest is midway in complexity between a plain text digest and an HTML digest. It contains a table of contents of the topics discussed in the digest:
There are 4 messages totalling 86 lines in this issue.
Topics of the day:
1. Request for comments (3)
2. Another subject, another ruler
Each message in the digest is then included as a MIME attachment. The subscribers access the messages as they would any other type of attachment. And, since MIME standards require that the type of content of each attachment is identified, all messages should appear normally, without the sort of display problems that plain text digests can have.
4.3.6 Subject Tags
The Subject Tags tab guides you through defining a Subject-Tag and setting your list members' subscription options to use the Subject-Tag.
Some mailing list subscribers like to have list mailings easily identified by a "subject tag", which is a string within square brackets added to the beginning of the "Subject" line in the email headers.
4.3.6.1 How do I make SUBJECTHDR a default option?
SUBJECTHDR may be abbreviated to SUBJ. If "SUBJECTHDR" or "SUBJ" is already part of your Default-Options setting, it already is the default. Otherwise, add SUBJ or SUBJECTHDR to the Default-Options text box. If the text box already has something in it, separate SUBJ from the the other settings with a comma (",").
You cannot combine SUBJECTHDR with any of the other header options. If any other "header" setting is in Default-Options, it must be removed from the Default-Options string before adding SUBJECTHDR. The other mail header options are:
4.3.6.2 Why would a subscriber want a subject tag?
Some subscribers like list mail to be easily recognizable as soon as it is received. Others like to set filters in their email software to move list mail into a special folder based on the subject line.
In contrast, other subscribers prefer not to tie up valuable "real estate" in the subject line with extra text, and therefore do not like it.
The preference is often based on what email software the subscriber is using, but often it is just a matter of taste. That is why this is a setting that can be set differently for each subscriber.
Note that even if you set SUBJECTHDR as the default for all subscribers, any subscriber can change their own subscription to their preferred header setting.
4.3.6.3 Why specify a different Subject-Tag?
You do not have to set the Subject-Tag list keyword in order to make it available to your subscribers. If you do not provide a subject tag, the list name will be used for any subscription set to SUBJECTHDR.
The primary reason for setting the Subject-Tag keyword is to provide a short text string to be used instead of the list name. Some email client programs limit the number of characters they display in the subject line. Long list names in a subject tag may take up most or all of the space provided for display by these email clients.
4.3.6.4 Why would you make SUBJECTHDR the default?
When you specify a "default option" you are telling LISTSERV to use this setting for all new subscribers. Specifying a new default option will not change the options for current subscribers.
Set default options because you specifically want new subscribers to have those options, or you believe that most subscribers would want those options and you want to save them the trouble of setting options themselves.
When deciding whether to set SUBJECTHDR as a default option, you may want to consider the technical sophistication of your typical subscriber. People with little technical experience are not likely to experiment with their subscription settings. They are unlikely to know that SUBJECTHDR is available, unless they are on a list where it is the default. If they do find out about it, they are more likely to ask the list owner to set it for them than to set it themselves.
Set SUBJECTHDR as the default if you think it will be welcome by most of your future subscribers. They can always change it to something else if they do not like it.
4.3.6.5 Why set the SUBJECTHDR tag for all subscribers?
If your list already has subscribers, and you think that most of the current subscribers would prefer this setting, you might consider changing all subscriptions to this setting.
Before doing so, you may want to check your subscribers' current settings. Some subscribers may have specific reasons for wanting a different header setting. Their preferences may be based on the email client they are using to read the list mail.
It may be appropriate, depending on the nature of the list, to warn your subscribers if the appearance of the list messages is about to change.
If you decide you want to notify your subscribers of the change, consider how you want them notified. If you choose to have LISTSERV notify the subscribers, they will receive a standard message from LISTSERV, which they may or may not understand. Depending on the technical sophistication of your subscribers, you may want to change the settings "quietly" (without automatic notification) and then send a message of your own to the list explaining the change you just made.
4.3.7 CataList
The CataList tab shows all the options available for cataloguing your list in CataList.
Listing in CataList makes it easier for prospective subscribers to find your list. CataList is known for keeping an up-to-date record of lists. It is updated several times a day, so the listings are generally never more than a few hours out of date.
4.3.7.1 Why List in CataList?
Listing in CataList makes it easier for prospective subscribers to find your list. CataList is known for keeping an up-to-date record of lists. It is updated several times a day, so the listings are generally never more than a few hours out of date.
For an example of a CataList entry, see the entry for the LSTOWN-L list.
4.3.7.2 Missing Listing in CataList
If you can not find the entry for your list in CataList, there are a number of possible causes:
The list is set to Confidential=Yes or Confidential=Service. Confidential=Yes prevents the list from being publicized automatically anywhere. Confidential=Service prevents the list from being listed in CataList, but allows the list archives (if they exist) to be listed on the server's index page.
The list is new or was changed to Confidential=No only recently. Wait a day to make sure you have allowed time for database updates, and then check again.
The LISTSERV server is set to "standalone" runmode. Only "networked" LISTSERV servers benefit from CataList listings, spam and spoof warnings, and other advantages. If neither of the first two bullets applies, check if DRAGONFLY.DC.LSOFT.COM is in CataList. If not, you may want to ask your LISTSERV site administrator whether it would be possible to set up the server to run in "networked" or "tableless" runmode.
4.3.7.3 HTML Description in CataList
An HTML description of your list is optional. If provided, it will be used by CataList, the online catalog of LISTSERV lists. If a text-based list description is not provided, the HTML description will also be used on the list's home page or archive index. If a text-based list description and an HTML description are both provided, the text-based list description will be displayed by default. This default behavior can be changed by editing the list's OBJECT-A0-LISTDESC template.
To delete an existing HTML description, check the Delete HTML Description checkbox and click [Submit].
4.3.7.4 Hide Header from CataList
The CataList entry for each list contains a link to "Take a look at the list's configuration", that is, the list header. Even if the list is not in CataList, it is possible for anyone to request a copy of your list header by sending the REVIEW command to LISTSERV. If there are parts of your list header that you consider to be sensitive information, you should hide these parts by using the .HH (hide header) directives.
You do so by adding .HH ON on a line by itself before the lines you want to hide, and .HH OFF on a line by itself after the lines you want to hide. You can also intersperse hidden lines and non-hidden lines.
If you want to hide the entire configuration, you can add .HH ON directly after the list title and .HH OFF directly before the list description.
Figure 4-10 Hiding a Header from CataList
4.3.8 Banners
The Banners tab guides you through changing all the banners that may be added to messages. LISTSERV provides several templates that can be inserted at the top and bottom of the individual messages that are sent to the list, as well as on digests and index mailings.
4.3.8.1 What is a Banner?
As a mailing list administrator, sometimes you want all messages distributed to a mailing list to include a specific piece of information. For instance, you might want to have instructions on how to sign off the mailing list at the bottom of each message, or to have a copyright notice at the top of the messages. LISTSERV's banner templates allow you to do this.
The top banner is typically used for information that is deemed to be critical and requires prominent placement, for example copyright notices.
The bottom banner is typically used for general information.
4.3.8.2 HTML vs. Text Banners
It is usually desirable to specify both a plain text and an HTML version of any banner you add to messages. That way the HTML version, including any formatting or markup you specified, will be added to any HTML messages distributed to the mailing list, and the plain text version will be added to any non-HTML messages. If you only specify a plain text banner, then LISTSERV will use it on both HTML and plain text messages. Since the plain text banner will not contain any HTML formatting, it may not look the way you want when added to an HTML message.
The HTML banners should contain HTML formatting tags so that they look "right" when added to an HTML message. The banners are included into the "body" of the HTML part of the mail message, and so should include only tags that are appropriate in the "body" part of an HTML document. For example, if you use a Web design tool to create the banner, you should open the HTML file that it produces in a text editor (Notepad, for example), and then cut and paste only the lines of HTML code that are between the <body> and </body> tags into the template. You may also want to add <br> tags at the beginning and at the end of the template to make sure that there is always a line break between the banner and the rest of the email.
If you do not want to use a Web design tool, it is easy to make a very basic HTML banner by taking the text banner and adding some simple HTML tags. For example:
4.3.9 Mail Templates
The Mail Templates tab introduces you to a few mail templates that many list owners choose to customize. LISTSERV provides a large number of templates that control the contents of email messages automatically sent to subscribers (and others) by LISTSERV under various circumstances. This tab lists a few of the most popular ones.
For detailed instructions, see the online help by clicking the Help icon associated with the Mail Templates tab or click on the Template Commands or Template Variables tip at the top of the tab.
4.4 Subscriber Management
The Subscriber Management screen allows the list owner to examine or delete a subscription and add a new subscriber to the list.
To open the Subscriber Management screen, click on the List Management menu, and then select Subscriber Management.
Figure 4-11 Subscriber Management
4.4.1 Adding a New Subscriber to the List
To add a new subscriber, click on the List Management menu, and then select Subscriber Management. The Subscriber Management screen opens. On the Single Subscriber tab, click the Select List drop-down menu to select the list you want to add the subscriber to. In the Add New Subscriber section, enter the email address and name of the new subscriber.
Figure 4-12 Adding a New Subscriber
Then, select whether or not to send an email notification to this subscriber, and click the [Add to List] button.
Note: The full name of the subscriber is optional. If omitted, then the user will be added anonymously to the list.
4.4.2 Examining or Deleting a Subscription
To add a new subscriber, click on the List Management menu, and then select Subscriber Management. The Subscriber Management screen opens. From the Single Subscriber tab, you can view or delete a subscription. This works very much like the "SCAN" command. Simply enter your criteria in the text box and click the [Search in List] button.
Figure 4-13 Examining or Deleting a Subscription
If there is no match for your entry, then you will get back the same page but with a Scan: No match message at the top. If, on the other hand, your search is successful, one of two things will happen.
If there are multiple matches for your criteria, a screen will be displayed with a scrollable list box containing all of the matches
Figure 4-14 Select Subscriber to Examine or Delete
Next, simply choose the user you want to examine or delete and click on the appropriate button. If you did not find what you were looking for, you can press the [New Search] button to get a new search screen.
If there was only a single match to your query, then the preceding screen will be bypassed and you will go directly to the next screen, which is the Subscriber Management screen for the subscription. It displays the values of all the settings for that subscription, including the subscription date and name. From this screen, you can delete the subscription or change the name, the email address, or the subscription options associated with the subscription.
The following settings are available in the Subscription Type section:
Regular – With a "regular" subscription, you receive individual postings immediately as they are processed by LISTSERV.
Digest (Traditional), Digest (MIME format), and Digest (HTML format) – With a "digest" subscription, you receive larger messages (called "digests") at regular intervals, usually once per day or once per week. These "digests" are collections of individual list postings. Some lists are so active that they produce several digests per day.
Digests are a good compromise between reading everything as it is posted and feeling like the list is clogging your mailbox with a multitude of individual postings.
There are three digest formats: a "traditional", text-only format; a MIME format, which (with mail clients that understand MIME digests) "bursts" the individual messages out of the digest so that you can read them separately; and an HTML format, which requires an HTML mail clients.
Index (Traditional) or Index (HTML format) – With an "index" subscription, you receive short "index" messages at regular intervals, usually once per day or once per week. These "indexes" show you what is being discussed on the list, without including the text of the individual postings. For each posting, the date, the author's name and address, the subject of the message, and the number of lines is listed. You can then download messages of interest from the server (the index contains instructions on how to do that).
An index subscription is ideal if you have a slow connection and only read a few hand-picked messages. The indexes are very short and you do not have to worry about long download times. The drawback of course is that you need to reconnect to retrieve messages of interest from the server.
You can choose to have the index sent to you in either a traditional format (plain text) or in HTML format with hyperlinks.
The following settings are available in the Mail Header Style section:
Normal LISTSERV-style header – "Full" mail headers (normally the default), containing Internet routing information, MIME headers, and so forth. The ('To:') header contains the address of the list.
LISTSERV-style, with list name in subject – "Full" mail headers (like the default) except that a "subject tag" is added to the subject line of mail coming from the list. If there is no subject tag defined in the list's configuration, the name of the list will be used. This can be very useful for sorting and filtering mail.
"Dual" (second header in mail body) – Dual headers are regular short headers followed by a second header inside the message body. This second header shows what list the message is coming from ('Sender:'), the name and address of the person who posted it ('Poster:'), the poster's organization, if present, and the message subject. Dual headers are helpful if your mail client does not preserve the original return email address.
sendmail-style (advanced option) – This option selects sendmail-style headers, i.e. an exact copy of the original, incoming mail header with the addition of a ('Received:') line and a ('Sender:') field. Some technical people prefer this type of header.
Normal LISTSERV-style (RFC 822 Compliant) – (For Advanced Use Only) "Full" mail headers (like the default) except that the ('To:') header contains the recipient's email address instead of the list address.
The following settings are available in the Acknowledgements section:
No acknowledgements – LISTSERV will not send any acknowledgement at all when you post to the list. This is probably not a good setting unless you really do not want any feedback from LISTSERV as to whether or not your posting was received and distributed.
Short message confirming receipt – Typically, this is the default setting, although it can be overridden by the list owner. If you choose this setting, LISTSERV will send you a short message whenever you post to the list, confirming the distribution of your message and telling you how many people it was sent.
Receive copy of own postings – Some people prefer this setting over the short acknowledgement message. It tells LISTSERV to send you a copy of your own postings so that you can see exactly how it appeared on the list (useful if you are behind an unreliable gateway or firewall).
The following settings are available in the Miscellaneous section:
Mail delivery disabled temporarily – This option toggles the receipt of mail from the list. You may want to disable mail delivery if you will be away from your mail for an extended period of time.
Address concealed from REVIEW listing – This option conceals you from the list of subscribers shown by the REVIEW command. Note that the list owner and the LISTSERV administrator can always get the complete list of subscribers, regardless of this setting. Nowadays, most lists are configured so that only the list owner can use the REVIEW command, but some lists still allow subscribers to get a listing of all the other participants.
User is exempt from renewal/probing – The user will not receive renewal reminders, if enabled for the list. In addition, the user will be exempt from address probing, which is used to determine if the address is valid or if the address generates bounces.
User may bypass moderation – The user may post to the list without having the message approved by the moderator.
All postings sent to the list owner for review – All postings to the list will be sent to the list owner for review before it is officially posted on the list.
User may not post to the list – This options simply means that the user can not post to the list.
Figure 4-15 Subscriber Management Screen
If you are deleting a subscription or changing/updating its options, the two options at the top of the screen allow you to choose whether or not a notification should be sent to the subscriber about the change or deletion. The two options when used with the [Delete] button are strictly equivalent to "DELETE listname userid@host" and "QUIET DELETE listname userid@host", respectively, and the other equivalent commands are formatted identically. Send Email Notification is the default.
The [Delete From All Lists] button is strictly equivalent to the command "DELETE * userid@host" and is used to delete the user from all lists on the local server (for site managers) or from all lists on the local server that are owned by the invoker (for list owners).
If you are making changes to the user's name field, address, or user options, use the [Update] button to commit the changes. If you make changes to both the options and the identification fields, user option settings are updated first, and then changes are made to the name and address fields.
Following either a [Delete] or an [Update] operation, the main Subscriber Management screen is displayed along with a message indicating the success or failure of your operations.
4.4.3 Bulk Operations
The Bulk Operations tab allows a list owner to upload an input file containing email addresses and (optionally) names, one address per line, and either add all the email addresses in the file to the list (optionally replacing the current subscribers) or remove them from the list.
To access, click List Management, and then select Subscriber Management. The Subscriber Management screen opens. Click on the Bulk Operations tab.
Figure 4-16 The Bulk Operations Tab
The input file is created on your own machine with an ASCII text editor. After clicking the [Import] button you will see a command response similar to the following:
If the Add the imported address to “List”; do not remove any subscribers option is selected:
ADD: no error, 202 recipients added, no entry changed, no duplicate, none forwarded.
If the Remove all subscribers from “List”, and add the imported address option is selected:
DELETE: 14 subscribers removed.
ADD: no error, 38 recipients added, no entry changed, no duplicate, none forwarded.
(If this option is selected, but no input file is specified, then you will only get the DELETE message.)
If the Remove the imported addresses from “List”; do not add any subscribers option is selected:
DELETE: 93 subscribers removed.
If the Remove the imported addresses from all lists option is selected:
DELETE: 243 subscribers removed.
DELETE: 109 subscribers removed.
Global deletion process complete, 352 entries removed.
If you do not supply an upload file where required, or if your browser does not support the RFC1867 file upload extension, you get the following message:
Your browser did not upload any file during the transfer. Assuming you did fill in the file input box, the most likely cause is that your browser does not support the file upload extension (RFC1867).
Notes: Bulk operations are not enabled by default. The site manager must enable this functionality explicitly. If you get an error 2 when you click on the [Import] button, this means that the "upload" directory has not been created. If you get an error 13 when you click on the [Import] button, this means that the "upload" directory has been created but the CGI program user does not have write permission in that directory. In addition, the input file must be a plain text file (not a word processor document or spreadsheet) and must contain one address per line, optionally followed with a space (or TAB) and the subscriber's name. In addition, the subscribers being added or deleted will not be notified.
4.5 Submitting LISTSERV Commands
The LISTSERV Command Interface is used for submitting LISTSERV commands that are not otherwise facilitated by the Web Interface. See Appendix A: Command Reference Card for a listing of all commands.
For some commands, the response is automatically displayed by the Web Interface. For others, a special command parameter must be used in order to display the response in the browser, otherwise the response is sent by email. In addition, other commands are only able to respond by email.
To access the LISTSERV Command Interface, click on the List Management menu, and then select LISTSERV Command.
Figure 4-17 The Command Interface
The Command Interface can only be used for single line commands. In particular, the PUT command will not work through the Web Interface. Multi-line commands must be sent by email.
A selection of frequently used commands is available at the bottom of the screen.