Thanks for coordinating this Patrick.
On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote:
X-List-Received-Date This only gets added when the message is sent to the archive. Modify to: List-Archive-Sent Next Step: Discuss
List-Archive-Sent (maybe with -Date) makes sense to me. This really is different than Received headers IMO since it's not recording any "receiving" event in Mailman. To the extent that it's useful to know when an MLM sends the message to its archivers, getting the direction right seems important.
The question in my mind is what to do about the case where, as in MM3, we have multiple archivers. Multiple L-A-S headers should be allowed, but then I wonder whether the headers need to record which archiver the header applies to. TBH, in MM3 when we send to one archiver, we send to them all so I'm not sure the extra complexity is worth it. I also don't know whether any other MLM supports multiple archivers.
X-Message-ID-Hash propose an RFC as an extension of RFC 5064 Modify to: unclear Next Step: Discuss
As an RFC, obviously we'd drop the X- prefix, but also "Hash" might be too vague. Personally I think Message-ID-Hash is fine and the theoretical RFC shouldn't allow much leeway in implementations (i.e. only one hash algorithm is allowed). This will probably be bikeshedded to death. Still, since Message-ID must be unique (and generally is, as backed up by The Mail Archive's data), I think base-32 of SHA-1 will in practice be just fine.
X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss
I like List-Agent much more than User-Agent, since Mailman is only tenuously under any control of the user. I like having this header under the List- prefix, so I Mediator doesn't appeal to me.
X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369?
To generalize, it might be useful to have List-Moderation-Action and List-Moderation-Date headers. The former would have values like Approved, Held, Rejected, or Discarded, while the latter would have the date of the disposition. Seemingly useless actions like Discarded and Held would still be useful because even a discarded message may end up in some email graveyard for future data mining.
II. MODIFY X-Mailer Only used when Mailman originates messages such as autoresponses. Modify to: User-Agent Next Step: Change code
Similar to the above, I don't like User-Agent much here. I think this could be simply folded into List-Agent since there are probably plenty of other header clues to know that a message was originated by Mailman.
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? Modify to: Tag Next Step: Create RFC
I think someone suggested Keywords, and as much as I'd like to use that one, I don't think it's feasible. Existing Keywords headers are used as input to the topic tagger so it can't be re-used. List-Topics seems fine to me, but other possibilities include List-Tags, List-HashTags, or List-Keywords.
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
These are all pretty specific to the Mailman implementation so dropping the X- should be enough. No RFC needed.
X-Content-Filtered-By I think this should be renamed to (X-)Mailman-Content-Filter. Modify to: Mailman-Content-Filter Next Step: Create RFC
The only utility of this header is to notify the recipients that the original message has been altered by removing MIME parts. OTOH, I think it's pretty much understood that messages flowing to mailing lists are subject to considerable modification. Certainly the content of this header as it currently stands is useless. It's akin to "This film has been modified from its original version. It has been formatted to fit this screen." I don't know whether we can come up with a List-* header that actually carries some meaningful content, so maybe it should just be dropped?
Cheers, -Barry