Great Circle Associates List-Managers
(December 2001)

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

Subject: Re: List-ID
From: Russ Allbery <rra @ stanford . edu>
Organization: The Eyrie
Date: 02 Dec 2001 10:58:33 -0800
To: List-Managers @ GreatCircle . COM
In-reply-to: Tom Neff's message of "Sun, 02 Dec 2001 11:13:58 -0500"
References: <200112020900 . BAA05451 @ honor . greatcircle . com> <87581031 . 1007291638 @ [192 . 168 . 0 . 4]>
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

Tom Neff <tneff @
 panix .
 com> writes:

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

Gnus mail splitting rules handle all of those fine.  I don't know about
procmail itself; I consider its syntax to be too baroque to be usable.
But surely such a widely-used filtering mechanism has something in place
to handle folded headers.

> 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,


I have a hard time imagining the sheer brain death that would be required
to think that randomly generating a new List-ID for every message was a
good idea.  I have never seen this happen, and I'm on many mailing lists
that use List-ID.  What on earth makes you think that someone would even
contemplate doing this?  It would require support in the mailing list
manager; what idiot is going to implement it that way?

> what happens when a list changes homes?

List-ID doesn't really live up to promises here; it's quite likely that
when lists change homes, the List-ID will change.

However, so does every single other header on which one can split.

So while it doesn't solve that problem really, that hardly prevents it
from being useful for the reasons I spelled out in the original message.
In my experience (and I'm on a *lot* of mailing lists and split them all
out into separate nnml groups), changes to other headers like Sender or
X-Loop are routine, happen all the time, generally happen without notice,
and happen without any change in the hosting of the list that would spark
a change in List-ID.  They change because someone rewired the majordomo
configuration to use list-owner instead of owner-list, because the list
admin switched from Smartlist to Mailman, because sendmail started
rewriting the Sender header, or for some other fragile internal reason.

> 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.

On the other hand, this makes List-ID *more* useful to me, so this will
vary depending on your application.  I expect that the number of people
who just want a list split out into a separate folder greatly exceeds the
number of people who are trying to automatically archive a foreign mailing

> 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.

That's an interesting way of setting up posting restrictions.  A good
mailing list manager should provide a lot of better ways of dealing with
that, since whether or not someone can post is really a per-user
attribute, not a property of a mailing list.

Regardless, it's a very good idea for other reasons to require mailing
lists that are operating as sublists to know that they're operating as
sublists, if for no other reason than otherwise rejecting all traffic that
seems to have gone through another mailing list is often a good idea to
avoid cross-subscription attacks.  (Still pretty hard to do this unless
you run ezmlm for all affected mailing lists, since there is no
standardized way of detecting mailing list traffic... but perhaps List-ID
will become that mechanism, and if it's used primarily for *rejection*,
then spammers definitely won't start including List-ID in everything they

Russ Allbery (rra @
 stanford .
 edu)             <>

  • Re: List-ID
    From: "David W. Tamkin" <dattier @ ripco . com>

Indexed By Date Previous: Re: List-ID
From: Tom Neff <tneff @ panix . com>
Next: Re: List-ID
From: "David W. Tamkin" <dattier @ ripco . com>
Indexed By Thread Previous: Re: List-ID
From: Tom Neff <tneff @ panix . com>
Next: Re: List-ID
From: "David W. Tamkin" <dattier @ ripco . com>

Search Internet Search