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:[EMAIL PROTECTED])
Apple Mail List Gnome (mailto:[EMAIL PROTECTED])
Be just, and fear not.
