List-ID= longlistname

This keyword is not available in LISTSERV Lite, and its use is deprecated on all ports of the software except for z/VM.

Since LISTSERV 16.0, this keyword may be set or altered only by the LISTSERV administrator.

Note: This keyword DOES NOT control whether or not LISTSERV adds an RFC 2919 "List-ID:" header to the RFC822 headers.


LISTSERV does not implement RFC 2919 because L-Soft considers the "List-ID:" header to be redundant and unnecessary for the type of functionality desired by the RFC author, which in effect can be achieved by using the RFC822 "To:" field for the same purpose.

On z/VM systems, this keyword allows the list owner to specify a long list ID in addition to the normal 8-character list name. This is particularly useful for peered or gatewayed lists that have names longer than 8 characters.

On non-z/VM systems, if the normal list name is longer than 8 characters and the list is being migrated from a z/VM system, it may be a good idea to specify the first 8 characters of the list name in this keyword, at least temporarily. This way subscribers who were used to the old 8-character name can continue to use it on the new system.

Non-z/VM systems may use this keyword for aliasing. However, this use is deprecated, as it is possible to define lists on such systems with native file system names longer than 8 characters.

L-Soft's recommendation is that this keyword be used only when migrating a list from z/VM that was known by both its "short" name and its "long" List-ID= name.

Tip: On unix systems, you can avoid using List-ID= by simply specifying an extra set of aliases in /etc/aliases for the "long" name that point to the same places as do the ones for the "short" name.

In any case a value for List-ID= should not be set without first adding appropriate system mailer aliases, without which the name specified in List-ID= will not work.

Warning: List-ID= will not work properly on Windows systems because the LISTSERV SMTPL.EXE "listener" has no way to know that the list ID specified in this parameter is a valid local address, and will reject mail sent to such addresses as "no such list".


It is possible -- but not recommended -- to force SMTPL to accept mail addressed to a list using the List-ID= keyword setting.  To do this, the LISTSERV maintainer sets the value SMTP_ACCEPT_ALL=1 in LISTSERV's site configuration and restarts SMTPL.

That being said, SMTP_ACCEPT_ALL is really intended for z/VM servers (where the use of List-ID= is still fully-supported), and in a Windows LISTSERV context it simply tells SMTPL to accept all mail regardless of whether or not it is addressed to a valid LISTSERV mailbox.

This means that responsibility for rejecting mail sent to non-existent LISTSERV mailboxes falls on single-threaded LISTSERV rather than on multi-threaded SMTPL, which has negative implications for LISTSERV's throughput efficiency and could end up causing more trouble than List-ID= is worth.

Given that the use of List-ID= is deprecated for use on non-z/VM systems in any case, L-Soft does not recommend this workaround for LISTSERV running on Windows.

Under unix, it is necessary to add the appropriate aliases to the mailer's aliases file in order for List-ID= to work, since mailers such as sendmail and postfix otherwise have no way to know that the name specified in List-ID= is a valid address. This means that lists that have the List-ID= keyword specified need two complete sets of aliases defined (unless List-ID= is identical to the list name, in which case it should not be used to begin with).

If you do use List-ID= to specify a "long" name for a list with web archives, LISTSERV will create an HTML page for both the long and short names. Here again, however, on non-z/VM systems, the use of the keyword is deprecated, and L-Soft does not recommend its use.