Great Circle Associates List-Managers
(October 2000)
 

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

Subject: Re: elist address or your address in message TO header
From: Chuq Von Rospach <chuqui @ plaidworks . com>
Date: Tue, 24 Oct 2000 14:52:05 -0700
To: James M Galvin <galvin @ acm . org>, Chuq Von Rospach <chuqui @ plaidworks . com>
Cc: list-managers @ GreatCircle . COM
In-reply-to: <Pine.BSF.4.21.0010241603480.1795-100000@two.elistx.com>
References: <Pine.BSF.4.21.0010241603480.1795-100000@two.elistx.com>

At 4:39 PM -0400 10/24/00, James M Galvin wrote:

>At this point, the principal problem would be that the varied uses are
>incompatible.  Thus, the best path, I think, is to create new headers,
>one for each use, which, or course, has its own backward compatibility
>issues.

If it's an optional superset, it's not a huge deal. But now you start 
to see why I said I wasn't going ot fight this fight.. (grin)

>Just to be specific, and please correct me if this is not where you were
>headed, given any arbitrary message and only that message, is it
>possible to know if it is from an elist?

I do not know of a generally available MLM where you can't use a 
header to figure it out. I'm sure there are some weirdies out there, 
but most encode the Sender, MLMs are starting to use List-ID, and if 
that doesn't work, I can usually use Reply-To, Errors-to or some 
other header that has a pointer back to an admin/bounce address. One 
MLM in my filter list (I think it's ezmlm) uses "mailing-list", which 
violates the RFCs, IMHO (it ought to be X-Mailing-List, since it's 
not a formal header).

I'd say you could write a fairly reasonable procmail script to 
true/false is-a-list and be right with high accuracy.

>The List-* headers are a Proposed Standard in the IETF (the first step
>along the 3-step standardization path), and there's no reason to think
>they will not evenutally be a full Standard.  One could make the case
>that the List-* headers were a creative way around the political issues
>of a decade ago.  (And as far as I know LISTSERV does not support them.)

Mailman will in 2.0, along with List-ID. I expect as they're 
formalized, you'll see other MLMs add them. I can understand at some 
level why someone like listserv takes their time here -- because you 
run the risk of adopting something that changes. It's easier for a 
smaller MLM or an open-source system to do this than a big corporate 
entity, because the users tend to be more tolerant of "oh, the RFC 
changed, this will be incompatible in the next release" isms.

>"THIS HEADER".  Currently, the document does say that it is sufficient
>to include only the List-Help header, which suggests it should probably
>be the required header, but I think a case could be made for List-Owner
>also.

Some of that comes from expecting list-id to be what is used for 
identifying lists, which is on a separate RFC track and last I 
looked, somewhat behind. the List-* stuff wasn't designed for filter 
identification issues as much as encoding data for mail client 
automation.

So the long-term answer is List-ID, unless it gets sideracked and falters.

>On the issue of "auto-generated" email, X.400 protocols actually handled
>all this much better, but then they were much stricter about the
>envelope versus message separation issue.  There has been some
>discussion from time-to-time in the IETF among the email folk about
>standardizing an "auto-generated" id of some sort, but a constituency
>never seems to develop so it doesn't go anywhere.

I've been tempted to add an X-Loop, even if it's not procmail, simply 
because filters have a chance to worry about that. that, and 
Precedence: bulk help, because things like vacation are smart enough 
to know that if I'm sending it bulk, I don't need ot know you're on 
vacation. That probably gets half.

>The real problem with headers is the chicken and egg analogy you eluded
>to in an earlier message.  If the email clients/applications don't
>actually support them, they are doomed to failure anyway.

If you don't use them, though, the client authors have no reason to 
adopt them. Someone has to lead, and it takes time. I'm *just now* 
starting to look at CSS on my web sites, because my user population 
has finally hit a point where a large majority uses CSS compatible 
browsers. And even at that, I plan on keeping it really simple 
because of compatibility issues -- but six months ago, I wouldn't 
even consider it.....

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

Be just, and fear not.



Follow-Ups:
References:
Indexed By Date Previous: Re: elist address or your address in message TO header
From: Chuq Von Rospach <chuqui@plaidworks.com>
Next: Re: elist address or your address in message TO header
From: Russ Allbery <rra@stanford.edu>
Indexed By Thread Previous: Re: elist address or your address in message TO header
From: James M Galvin <galvin@acm.org>
Next: Re: elist address or your address in message TO header
From: James M Galvin <galvin@acm.org>

Google
 
Search Internet Search www.greatcircle.com