The List Management menu on the Toolbar gives you a variety of features for working on and maintaining your lists and subscribers.
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.
|
•
|
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.
|
|
•
|
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].
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.
|
•
|
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].
|
•
|
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.
|
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.
|
|
•
|
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.
|
|
•
|
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.
|
•
|
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.
|
|
•
|
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).
|
|
•
|
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.
|
•
|
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.
|
|
•
|
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.
|
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.
|
|
•
|
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!
|
•
|
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.
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.
|
•
|
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).
|
|
•
|
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.
|
|
•
|
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.
|
|
•
|
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.
|
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.
|
|
•
|
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".
|
|
•
|
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.
|
|
•
|
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.
|
|
•
|
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.
|
|
•
|
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).
|
|
•
|
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.
|
|
•
|
Confirm-Delay – Use this keyword to define the number of hours to hold subscription requests awaiting confirmation.
|
|
•
|
Default-Options – Use this keyword to define the subscriber options that will be the default for all new subscribers. Separate options with commas.
|
|
•
|
Default-Topics – Use this keyword to specify which of the currently defined topics should be assigned to new subscribers by default.
|
|
•
|
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.
|
|
•
|
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.
|
•
|
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.
|
|
•
|
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.
|
|
•
|
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.
|
|
•
|
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.
|
To configure a list manually, click on the List Management menu, select
List Configuration, and then select
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.
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:
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:
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:
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:
|
•
|
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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:
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=.
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.
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.
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
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.
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.
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.
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).
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.
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.
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.
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.
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.
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*".
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Note: If the mailing list is used for discussions, typically there will be multiple messages for each subject.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
|
•
|
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.
|
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].
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.
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.
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.
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.
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.
To open the Subscriber Management screen, click on the List Management menu, and then select
Subscriber Management.
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.
Note: The full name of the subscriber is optional. If omitted, then the user will be added anonymously to the list.
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.
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.
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.
|
•
|
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.
|
|
•
|
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).
|
|
•
|
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.
|
|
•
|
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).
|
|
•
|
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.
|
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.
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.
|
•
|
If the Add the imported address to “List”; do not remove any subscribers option is selected:
|
|
•
|
If the Remove all subscribers from “List”, and add the imported address option is selected:
|
|
•
|
If the Remove the imported addresses from “List”; do not add any subscribers option is selected:
|
|
•
|
If the Remove the imported addresses from all lists option is selected:
|
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.
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.
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.
