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-header.nisto.com>
List-Id: <commonspace-users.list-id.within.com>
List-Id: "Lena's Personal Joke List"
<lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
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.
Follow-Ups:
|
|
