[Mailman-Developers] Mailman headers roundup

[Barry Warsaw]

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