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.