In order to support the network-wide list registration feature (which will be
introduced in release 1.5n), a new list header keyword is being defined. Its
syntax is:
List-ID= netname
Where 'netname' is the network-wide identification of the list. Syntactically,
it can contain up to 32 characters from the following set:
A-Z 0-9 .;:-_#&?/+%$!|
Any other character is invalid (ie "just because it works now doesn't mean it
will always"). In particular, lowercase characters are automatically
translated to uppercase when the keyword is processed.
The purpose of this keyword, whose value defaults to the list name, is to
establish a network-wide identification for peered lists, and to provide
synonym names for other lists. Let's consider the following problem:
1. IBMPC-L@X is peered with IBMPC-L@Y and MD45@Z
2. I-IBMPC@A is peered with IBMPC-L@B and I-IBMPC@C
3. IBMPC-L@M is a non-peered list.
We have two peered lists, 1 and 2, but which one is IBMPC-L? Who would know
that MD45@Z is an IBMPC-L redistribution?
The 'network-wide id' is the name by which your list will be known to the
other LISTSERVs. It MUST verify the following condition:
--> If two lists have the same List-ID, and these two lists are peered ones
--> (ie they have a 'Peers=' keyword in their list header), then the two lists
--> are peered together. Non-peered lists do not HAVE to verify this
--> condition, although it is recommended that list-IDs be unique in the
--> network.
In our above case, the owners of lists 1 and 2 would have to come to an
agreement and select two different ids (eg INFO-IBMPC and IBMPC-DIGEST). The
owner of list 3 ought to use a different id (possibly just keeping the list
name), or he might use IBMPC-DIGEST as well, although this is not recommended.
Concretely, you need to introduce a List-ID keyword in one of the following
cases:
- Non-peered list: if you don't like the listname, you may provide a List-ID
as a synonym. This will be accepted on most LISTSERV commands, but you still
have to send mail to the listname address (for obvious reasons).
- Peered lists:
* If all the peers do not have the same listname, you MUST define a List-ID
keyword which must be the same for all the peers.
* If all the peers have the same listname, you may or may not wish to define
a List-ID as a synonym. If you do, it MUST be specified on ALL the peers.
In any case, the List-ID is the only name by which your list is known to other
servers. That is, if the owner of IBMPC-L@M defines a List-ID of
"IBMPC-FREAKS", then:
- Commands sent to his server will work with both IBMPC-L and IBMPC-FREAKS.
- Commands sent to other servers will work ONLY with IBMPC-FREAKS.
I therefore recommend not to define List-IDs for non-peered lists without
reason.
The change should be made NOW, to avoid getting into (transient) problems when
1.5n is released. 1.5m will just ignore the List-ID specification, so you
won't have any problem with this.
Eric
|