* Barry Warsaw <[email protected]>: > 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@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 _______________________________________________ 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
