[Mailman-Developers] Mailman headers roundup

[Patrick Ben Koetter]

* Barry Warsaw <barry at list.org>:
> 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.

As a sidenote: Postfix 2.9 will introduce longer Message-IDs because a
Message-ID is only stable while the message is in the server (queue), but it
may be reused immediately after the first message had been delivered - that's
RFC compliant. This has caused problems with long time log analysis software
and archival and that's why Postfix 2.9 will offer longer Message-IDs (read
also: Queue-IDs).


> >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.

One last attempt: Using List-Agent only creates an agent instance that can be
used by MLM software. Using Mediator will creat an Agent that can be used by
any software that processes mail.


> >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,

+1


> 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.

Lets settle for List-Topics. If someone wants to compare e.g. with their
social network, forum ... they will have to create a mapping. This will work
too.

> 
> >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.

Okay.


> >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

To a postmaster debugging a problem knowing instead of assuming the message
had been altered can make all the difference.

I expect an MLM to add some headers and add a footer, but I don't expect it to
rip out MIME parts - allthough I know it can do. I personally think MM should
add a notice if it removes or replaces MIME parts.


> 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?

Maybe saying what the MLM did would be more meaningful? It could give a hint
what was done:

List-Message-Modified: Removed|Replaced ...

p at rick

-- 
state of mind ()

http://www.state-of-mind.de

Franziskanerstraße 15      Telefon +49 89 3090 4664
81669 München              Telefax +49 89 3090 4666

Amtsgericht München        Partnerschaftsregister PR 563