On 11/2/2011 8:06 AM, Barry Warsaw wrote: > 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.
I agree with having a List-Archive-Sent header for when the message is sent to one (or more archivers). However, I still think there is a need for the date and time when the List actually receives the message. Let's say Mailman is running on the same system as a spam/anti-virus software package. The message comes into the systems MTA which then routes the message to the spam/anti-virus software where it is held for approval. Two days later, someone approves the message which is returned to the MTA for delivery. The MTA passes the message to Mailman. Mailman adds the List-Received-Date header since that is when Mailman received it. A similar argument can be made about the List-Archive-Sent header. The header should not be added until the last moment, basically right before calling the archiving module. If a list is moderated or a message is held, that will affect the List-Archive-Sent header because the message can't be sent unless a disposition is known about the message. > > 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. I would much more prefer List-Agent over User-Agent. I agree Barry about Mailman tenuously under any control of the user. My experience is that users generally exercise no control over Mailman. Mediator also doesn't make much sense to me. Mailman settle any disputes for me. Nor, do I see it as an intermediate "agency". I see lists in general and Mailman in particular as a collecting point or aggregator for messages for a common "topic" which then distributes the received messages to interested parties. So, instead of a Mediator header, I can see a Collector header, or Aggregator header, or a Distributor header, and even then none of them really make sense. To me, List-Agent makes the most sense. >> 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. I can see this one both ways. Since Mailman is the "List-Agent" doing the work, add to the message the List-Agent header. And because Mailman is generating the content, add to the message the User-Agent header and make it the same information from the List-Agent header. Then when you are reading the headers, you can see the MTAs Received headers, List-Agent tells you the list the message came from and User-Agent tells you who generated and put together the content of the message. > Cheers, -Barry Thanks, Chris _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org 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