> L-Soft has implemented support for several of the list-specific message headers
> described in RFC 4021 <http://www.rfc-editor.org/rfc/rfc4021.txt>,
> however, it does not appear that the List-ID: header is supported.

We have implemented RFC2369, which does not include "List-ID:". That header is defined in RFC2919, an independent RFC written by different people.

Having read RFC2919, my spontaneous reaction is:

1. I cannot think of any use of this header, in practice and in the case of a full-featured product like LISTSERV, that cannot be achieved through existing means. I will concede that it is possible to craft lab scenarios where the header would provide functionality not otherwise available. I will also concede that the header could be useful for a product typically used on laptops or other scenario where hostnames change frequently (DHCP, etc), but LISTSERV is not used in this kind of environment.

2. The use of the traditional mailbox format, but with a different, non-mailbox syntax is really asking for trouble!

3. This header has a very high implementation cost:

   a. Configuration rules for the generation of the non-mailbox-syntax ID must be created, along with web interface support for entering the rules.

   b. A list header keyword must be added to override the default site rule.

   c. Code must be added to validate the new, non-mailbox-syntax ID in the list header keyword in question, especially since everyone will tend to intuitively use the mailbox format.

   d. The header must be generated not only in postings, but in "command responses to individual users" and in "messages where the message clearly applies to this particular distinct list."

   e. Code must be added to identify command responses associated with particular lists, but only in the case where the command response "clearly applies to this particular distinct list." For instance, a SIGNOFF * that deletes you from XYZ-L does not qualify, except in the special case where this is the only list you were removed from.

   f. Code must be added to remove prior "List-ID:" keywords from incoming messages.

   g. Code must be added to identify the special and tortuous case of nested lists, where rules d and f must be disabled.

   All told, about the same amount of effort as implementing an HTML editor and HTML templates in LISTSERV. It is a major undertaking.

4. Admirably, and in spite of all the hassle implementers are required to go through for essentially no practical benefit, it did not occur to the RFC authors to support multiple IDs for a given list, for instance when a list is being renamed or merged with another one or migrated. That is the one thing that could potentially have justified the hassle of implementing this tag.

> The List-ID: header provides a reliable method of
> identifying list messages. The 'To:' line is not reliable filter
> fodder.

But for any given subscriber, it is. This is exactly how I filter my list mail and it works 100% of the time! I the 10+ years I have been filtering list mail, I never misfiled one message. But if filtering on 'To:' or 'Sender:' is difficult, you can use one of the List-* tags from RFC2369. Frankly, if the only benefit is to avoid having to change a mailbox filtering rule in the rare case when a list is renamed, it is not worth the implementation effort.

  Eric