Great Circle Associates List-Managers
(December 2001)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: List-ID
From: Tom Neff <tneff @ panix . com>
Date: Sun, 02 Dec 2001 11:13:58 -0500
To: List-Managers @ GreatCircle . COM
In-reply-to: <200112020900 . BAA05451 @ honor . greatcircle . com>
References: <200112020900 . BAA05451 @ honor . greatcircle . com>

Russ Allbery <rra @
stanford .
edu> wrote:
Tom Neff <tneff @
panix .
com> writes:
There is no big problem, that's for sure.  I merely note
parenthetically, in passing so to speak, that List-ID prevents nothing,
solves nothing, assures nothing, and simplifies nothing,

It's a nice thing to put into procmail rules rather than trying to figure
out what combination of Sender, X-Loop, Mailing-List, Resent-From, To, or
envelope sender seems unlikely to change at the whim of the list-admin and
the software they use.

Is List-ID really useful in procmail rules? First let's remember the examples of valid List-ID's given in the RFC:

	List-Id: List Header Mailing List <>
	List-Id: <>
	List-Id: "Lena's Personal Joke List"
	List-Id: "An internal CMU List" <>
	List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>

[Note to reader: Quick - without cheating - does YOUR procmail rule handle all of these?] At minimum it will be necessary to devise a carefully crafted Procmail rule and hope that it gets promulgated around and used correctly. Note that the RFC appears in run the third example onto a second like like the Received: header, although the syntactical definition doesn't appear to allow it, so some emitters will probably be misled. Also note that the RFC says "Note that there is no disadvantage to changing the description portion of the List-Id header."

Second, let's think about the likelihood of the header changing. Assuming we can get people to generate one long random ID string ONCE for the list, instead of every time (like Message-ID) which they'll probably be tempted to do, what happens when a list changes homes? The RFC contradicts itself by saying "the owner of a mailing list MUST NOT generate list identifiers in any domain namespace for which they do not have authority," but later "...the mailing list administrator SHOULD avoid changing the list identifier even when the host serving the list changes." Which means that when you move your list from GreatCircle to HIS.COM, you're supposed to do what? Continue poaching on GreatCircle's namespace to which you're no longer entitled, risking collision when some new legitimate GreatCircle member wants to create sf-news which was your list's name? Or change the string to some new value that breaks everyone's filters? That's assuming you even get to choose - many list hosters will probably have rigid ID generation schemes that will force a change when they decide (even if you aren't moving).

Third, there's content. According the the RFC, this List-ID should apply to all messages specific to the list. That means, for example, that I can't use List-ID to pull off postings for an archiver, because mixed in will be adds and drops, rosters, membership reminders, moderation notifiers, and all manner of other dripdrap. To get anything useful done, I'm going to have to apply heuristic context-type filters, exactly as I am doing now.

Fourth, say hello to the pass-through problem. When one list feeds another, the originating List-ID should survive, according to the RFC. That presumably means that in our "authorized posters sublist" scheme where, say, 20 committee members are on a read-write list and another 300 onlookers receive a subsidiary read-only list, the messages the onlookers read will have a List-ID different from the list they joined. But this only works if the sublists "know about" their parent lists, and if the software has been modified to support such knowledge. Otherwise, says the RFC, incoming List-IDs should be ignored, so that if "sh-chat" has as one of its members "Gene Wolfe Announcements," those announcements will arrive with sf-chat List-ID's. When a list moves, etc, etc, etc.

I think that List-ID is a manageable and seemingly desirable new feature for the tiny fraction of people who are currently using it, BECAUSE only a tiny fraction use it. When and if it becomes widespread, it will rocket to the top of the "troubleshooting" forums for users. managers and developers alike. But this is definitely not a problem!! Just an idle observation.

  • Re: List-ID
    From: Norbert Bollow <nb @ thinkcoach . com>
  • Re: List-ID
    From: "David W. Tamkin" <dattier @ ripco . com>
  • Re: List-ID
    From: Russ Allbery <rra @ stanford . edu>
Indexed By Date Previous: Re: @ home shutdowns.
From: Rik van Riel <riel @ conectiva . com . br>
Next: Re: List-ID
From: Russ Allbery <rra @ stanford . edu>
Indexed By Thread Previous: Re: List-ID
From: Norbert Bollow <nb @ thinkcoach . com>
Next: Re: List-ID
From: Russ Allbery <rra @ stanford . edu>

Search Internet Search