Table of Contents Previous Next Index

Section 17 Other Features and Functions

Section 17 Other Features and Functions
17.1 Setting Up National Language Mail Templates
While LISTSERV is not shipped with non-English language mail templates, it is possible to create such "national language" templates and make them available on a list-by-list basis by using the "Language=" list header keyword. The procedure to use national-language templates is as follows:
Call the translated template file idiom.MAILTPL, where "idiom" is replaced by the name of the language, for example, FRANCAIS.MAILTPL, ESPANOL.MAILTPL, etc.
For lists that will use the national language template, code "Language= idiom" in the list header. For instance, if the national language template is called FRANCAIS.MAILTPL, code "Language= Francais". If you’ve called it FRENCH.MAILTPL instead, then code "Language= French".
Note: LISTSERV's hard-coded messages will continue to be issued in English, and any editable template not present in your national language template will be pulled from DEFAULT.MAILTPL (or the list's own MAILTPL file, if it exists) when needed.
See Section 9 Creating and Editing Mail and Web Templates for more information on creating and editing LISTSERV's mail templates. L-Soft does not provide national language mail templates.
17.2 Translating Control Characters Included in List Mail
LISTSERV removes control characters from mail messages by default and expands tabs in the process. Control characters usually have undesirable and unexpected results, as they seldom survive the double ASCII->EBCDIC->ASCII translation and cause the recipient's terminal to execute sequences different from the ones meant by the message sender - not to mention the case of ASCII control characters on EBCDIC terminals. Furthermore, certain combinations of control characters were found to create problems with IBM's SMTP (due to unexpected CRLF sequences appearing in the middle of a record after translation). Lists that absolutely require control characters must have a "Translate= No" keyword added to their header.
17.3 Communicating with List Owners
The LISTSERV maintainer may have occasion to communicate with some or all of the list owners who run lists on his server. This does not require that the LISTSERV maintainer keep a "super-list" of list owners, but only that he or she use certain addresses when communicating with list owners.
17.3.1 The Listname-REQUEST Alias
If you need to communicate with all of the list owners of a single list, simply address your mail to listname-REQUEST. This special address will be expanded by LISTSERV to include all non-quiet list owners of the specified list. For instance, mail to the list owners of the PEKINESE list on LISTSERV.SIRIUS.NET would be addressed to PEKINESE-REQUEST@LISTSERV.SIRIUS.NET.
To limit the possibility of random spam being sent to listname-REQUEST addresses, all persons sending mail to them will be required to respond to an OK confirmation request before the mail is forwarded to the appropriate person(s).
17.3.2 The ALL-REQUEST Alias
If you need to communicate with all of the non-quiet list owners on your server, simply write to the special ALL-REQUEST alias. ALL-REQUEST is expanded by LISTSERV to include all non-quiet list owners of all the lists on your server.
Note: ALL-REQUEST should only be used in emergencies, or when all non-quiet list owners need to be informed that something is happening, such as a migration from one server to another.
For general news it is probably better to create an administrative mailing list for your list owners rather than to use ALL-REQUEST.
The ability to post to the ALL-REQUEST alias, which expands to all non-quiet list owners, is restricted as follows:
The site configuration variable, ALL_REQUEST_ALLOWED_USERS, can be used to specify who can mail to ALL-REQUEST. This variable uses the same syntax as POSTMASTER=, in other words, a space-separated list of userid@host specifications.
This avoids dealing with header errors. Header error = don't know who sent this = discard silently = unhappy admin who had to send an urgent notice to all his owners.
The main point of this change is to block spammers, and spammers typically have non-working or null MAIL FROM: addresses. Needless to say, null doesn't pass the test.
In addition, all persons sending mail to the ALL-REQUEST alias will be required to respond to an OK confirmation request before the mail is forwarded to the appropriate person(s).
Although a further request was considered for a way to disable ALL-REQUEST entirely, it was decided not to implement it, as the main concern was to block spammers and general users from posting to the alias at random.
17.3.3 Required Configuration for Unix and VMS Servers Running PMDF
Note: VM servers, VMS servers running MX, and Windows servers do not require that any special aliasing be added for these aliases. This functionality is built-in for those installations.
You should already have coded "listname-request" aliases into your /etc/aliases file (unix) or your PMDF aliases file (VMS running PMDF) for each list on your server. See Section 7 Creating and Maintaining Lists for more information on coding these aliases.
If you are running a unix server, or a VMS server running PMDF, you will probably have to code an alias for "all-request" into your aliases file, as this is not normally done at install time. See your installation guide for information on how to code the base-level "listserv", "owner-listserv", and "listserv-request" aliases and follow those instructions to add an alias for "all-request".
17.3.4 Other Aliases Used by LISTSERV
The following aliases need to be added for lists running on VMS (with PMDF) and unix. All other configurations handle them automatically.
In addition to the aliases for "listname" and "listname-request", LISTSERV also uses the following aliases for specific purposes:
This alias is placed by LISTSERV in the RFC821 MAIL FROM: header. The expectation is that, per RFC821 et seq., remote hosts will send any delivery errors back to the RFC821 MAIL FROM: address. LISTSERV considers anything sent to the "owner-listname" address as a delivery error (which can cause a problem with some older mail clients, such as Microsoft Mail, which use the RFC821 MAIL FROM: rather than the RFC822 From: header as the originator of the mail). This alias maps to the value in the "Errors-To=" list header keyword. In general this address should not be used to communicate with the list owner (listname-request is the preferred alias for contacting list owners) as mail sent to this address is always handled as an error.
This alias is an artefact from the days when it was not always clear what the name of the account running the mailing list manager was. In general, if you had forgotten if the list was running on LISTSERV or Majordomo or whatever, you could write to listname-server@host and your commands would reach the server. For LISTSERV's purposes, this alias maps to LISTSERV@host. While this alias is not absolutely required, we recommend that it be made available because old documentation may still indicate that this is a legitimate way to write to the mailing list manager.
This alias handles search requests coming from INDEX mode subscriptions and must be present for each list for INDEX to work properly.
listname-signoff-request and listname-unsubscribe-request
Mail sent to these aliases will cause a signoff event for the userid in the From: line (no command is required and the body of the message is discarded).
Mail sent to this alias will cause a subscribe event for the userid in the From: line (no command is required and the body of the message is discarded).