Re: MoreOn: Attempts at establishing harmful conventions

> The "[listname]" insertion is clearly the "sore point" case.  This is 
> natural because it seems to defy the otherwise reasonable-sounding 
> rule that i myself proposed, which is that the Subject field is for 
> human beings.  However, I'm not sure that this is really as bad a 
> layering violation as it might seem.  While the list processor is 
> indeed inserting something into the "human" part of the stream, it is 
> (at least in theory) doing so in accord with a policy set by a list 
> owner.  A list owner should be able to choose to insert any strings he 
> wants to in messages that go through his list, to convey a meaning 
> that he wants to convey.  The fact that list processors make it so 
> easy to insert such strings may be simply a reflection of the fact 
> that so many list owners want to be able to do that.  But they want it 
> for its human meaning, not for any intended protocol consequences.
I see (at least) two distinct kinds of badness associated with 
[listname] tags.  One is that they get in the way of searches, 
comparisons, display, etc. so there's a temptation to remove or ignore 
them just as with Re:, Fwd: and similar tags.
The other is the harm to transparency - these tags alter the message 
content from what the original author intended.  Footers added by lists 
cause the same kinds of problems.  This begs the question - is the 
purpose of the list to be a transparent multicast channel or is it an 
original source of content?  In many cases the same content that is 
submitted to a list is also transmitted to other recipients, who will 
think they're all receiving the same message - but they're not.
While a case can probably be made that at least a few lists should be 
content sources, IMHO lists that alter subject fields or message bodies 
should also alter other portions of the message to avoid confusion with 
the message as originally written by the author.  For instance, the 
message-id should be changed, in-reply-to and references fields should 
be cleared or altered, etc.
As for the "dog" analogy:  we can scarcely prevent any kind of protocol 
violation.  But we can at least point out that some practices are 
undesirable and try to discourage them.