[Mailman-Developers] Mailman headers roundup

[Stephen J. Turnbull]

Patrick Ben Koetter writes:

 > X-Mailman-Approved-At
 > 	lose the X-prefix
 > 	Modify to: List-Approved-Date
 > 	Next Step: Create RFC or Extend RFC 2369?

New RFC.  Once you get to the RFC stage, you don't modify them (even
for typos, they publish errata).

 > X-Topics
 > 	This contains a list of all the topic names that matched the message.
 > 	Are there any other MLMs that support topics in a way that
 > 	would make that header generally useful?

"Topics" is way too general a word, and easily confused with Summary
(an existing standard header) or perhaps a digest table of contents.

 > 	Modify to: Tag

That's horrible, given the number of different uses for "Tag" in the
email-using community (mostly in other contexts).  Also, "tag" is
generally connotes filtering by the client, while Mailman does the
filtering at the server.

Both of those words need at least a "List-" qualifier, and probably a
"Mailman-" qualifier given their Mailman-specific usage.

 > 	Next Step: Create RFC

No, the next step is to talk to other MLM developers.  If they don't
support it, I doubt any RFC will fly.

 > X-Mailman-Rule-Hits
 > 	They could certainly lose the X- prefix.
 > 	Modify to: Mailman-Rule-Hits
 > 	Next Step: Create RFC
 > 
 > X-Mailman-Rule-Misses
 > 	They could certainly lose the X- prefix.
 > 	Modify to: Mailman-Rule-Misses
 > 	Next Step: Create RFC

I don't see any need for RFCs for either of those, or any need for a
name change, for that matter.

 > X-Content-Filtered-By
 > 	I think this should be renamed to (X-)Mailman-Content-Filter.
 > 	Modify to: Mailman-Content-Filter
 > 	Next Step: Create RFC

I don't see a purpose to this.  User-Agent, Mediator can be used to
identify the agent.  If you're going to be specific about what was
filtered, that information should go into Rule-Hist.

 > X-Originally-To
 > 	Probably not worth changing.
 > 	Next Step: Ignore
 > 
 > X-Original-CC
 > X-Original-Content-Transfer-Encoding
 > X-MIME-Version
 > 	Ignore these.
 > 	Next Step: Ignore
 > 
 > X-Ack
 > X-No-Ack
 > 	These should keep the X- prefix.
 > 	Next Step: Ignore
 > 
 > X-Approve
 > X-Approved
 > 	need to keep the above two for backward compatibility
 > 	Next Step: Ignore

AFAIK all of the above are incoming headers.  We cannot change them,
only decide whether to interpret them and if so, how.

 > X-BeenThere
 > 	legacy
 > 	Next Step: Remove from code

This needs discussion.  The proposal to remove it depends on whether
the issue about header spam has really been resolved, or if we're just
not hearing complaints because people whose subscribers use mailers
that display the List-* headers have turned them off.

 > X-Archive
 > X-No-Archive
 > 	deprecated
 > 	Next Step: Remove from code

These are originator headers, and I don't see any harm in respecting
them (or providing the option to list owners), even if many other
agents do not.