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. _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
