>Precedence is not a standard insofar as it's use is not documented by a
>recognized "authority".
I'm rather suprised nobody's fought to standardize this (but no, I
don't plan on it).
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.
>However, to suggest that all elist technologies or services should set
>this value is false. For example, when the elist services of expansion
>and distribution are provided as part of the MTA, i.e., the email system
>never gives up control of the message, it would be inappropriate to set
>this value.
Good point. When I think of this stuff, I generally make the
(incorrect) assumption it's ALL MLM stuff. But it brings up an
interesting issue -- how should this be id-ed?
Which, in fact, is the same question I was asking, although I didn't
choose a particularly good context in which to ask it.
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?
If I allow myself additional information, e.g., knowing I subscribed to
an elist at a particular address, then certainly I can probably always
construct a filter that will identify such messages. However, because
there is no standard for id'ing an elist message, the question can not
be answered in general without out-of-band information.
By the way, there was an attempt many years ago, early 1990's, in the
IETF to standardize many MLM functions and features. However, back
then, BITNET was still strong enough that LISTSERV versus majordomo
(less so) versus the Internet de facto standard of "-request" split the
community and consensus was never achieved.
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.)
Sadly, none of the List-* headers are required, even if you're
supporting them. In the next iteration of the standard I'd like to see
it say that if you are going to support List-* headers you must include
"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. I'm not especially partial to either; I'd would just like one
chosen.
If this were done I think it would constitute an id for MLM stuff,
irrespective of whether it is supported by an email system or elist
application.
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.
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.
Jim
