Re: [Mailman-Developers] Mailman headers roundup
On 11/2/2011 1:31 PM, Patrick Ben Koetter wrote: > * Barry Warsaw : >> Thanks for coordinating this Patrick. >> >> On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: >> >>> 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). I think the Message-ID to which you refer in the above paragraph is the Postfix queue ID and has nothing whatsoever to do with the Message-ID: header or (X-)Message-ID-Hash which is a hash of that header. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ 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
[Mailman-Developers] Topics/sublists (was Re: Mailman headers roundup)
On 11-11-02 7:26 AM, William Bagwell wrote: Many people (including more than a few list owners) have problems with Topics and using them correctly and efficiently. Can proved examples / statistics if anyone wants? Oddly, I personally have never seen a technical list that uses Topics. Have been greeted by crickets the few times I have suggested tuning them on in responce to a political flame fest. For the record, I have seen them used on a smaller technical list (which was running courses for different mostly tech topics), but the most extensive use of a topic system I've ever seen is actually the Systers "dynamic sublists" system: http://wiki.list.org/display/DEV/Dynamic+Sublists In short, it uses listname+topicn...@example.com style email addresses to create sublists (listname+...@example.com to start a new one) and allows people to subscribe/unsubscribe from those individually. Overall, it means admins don't have to go around manually setting up topics, it means subscribers don't have to try to read regexes to figure out what subject tags they need to get grouped with the right topic, and it seems to run a lot more smoothly in practice than Mailman's default topic system, having used both. One of the goals with Systers' summer of code work has been to get some of this stuff integrated with Mailman, so if we're talking about fixing the topic system, I highly recommend we take advantage of the lovely code already prepared for us. :) We may even already have copyright releases on file for this. Terri ___ 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
Re: [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. 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'
Re: [Mailman-Developers] Mailman headers roundup
Barry Warsaw wrote: On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: 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. I love painting bikesheds... or rather offering paint color/colour suggestions to painters doing the work ;-) If a header is going to contain data that is generated from non-trivial processing I think it would be good form to include the algorithm name in the header. The DKIM-Signature (RFC 4871, and was included in the email I'm replying to) itself includes the name, example extract: DKIM-Signature: a=rsa-sha256; . DKIM is using a secure hash which is arguable more processing than a simple digest hash but the same principle of self documenting seems reasonable. Admittedly there will be a need in the future for new secure algorithms to be deployed for DKIM, it is less certain if there is a need to ever change the algorithm used for X-Message-ID-Hash. Is there a clear advantage limiting the algorithm used? 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
Re: [Mailman-Developers] Mailman headers roundup
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,
Re: [Mailman-Developers] Mailman headers roundup
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 ___ 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
Re: [Mailman-Developers] Mailman headers roundup
On Monday 31 October 2011, Stephen J. Turnbull wrote: > Patrick Ben Koetter writes: > > 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? > > "Topics" is way too general a word, and easily confused with Summary > (an existing standard header) or perhaps a digest table of contents. Has been a few days and no one else has commented on this. My thoughts are strictly from an end user and list owners point of view. I happen to like Topics and find them quite usefull. You are correct however in that they are confusing. The few lists I have been on through the years that enabled Topics were all social lists with non-technical users. BTW, these lists started on ListServe and later migrated to Mailman to save money. I'm presuming that the name and function "Topics" originated with ListServe? Many people (including more than a few list owners) have problems with Topics and using them correctly and efficiently. Can proved examples / statistics if anyone wants? Oddly, I personally have never seen a technical list that uses Topics. Have been greeted by crickets the few times I have suggested tuning them on in responce to a political flame fest. Only word I can think of that more accurately describes the way Topics are used in real life is "Sub-list". Unfortunately it is also confusing and I think not strictly accurate in what they really are. Perhaps "mini-sublists" to distinguish them from true sublists? > > X-Archive > > X-No-Archive > >deprecated > >Next Step: Remove from code > > These are originator headers, and I don't see any harm in respecting > them (or providing the option to list owners), even if many other > agents do not. Yes, please keep. If and when Mailman gets a user friendly archive, then the need for this header might grow. Both KMail (Linux) and Forte Agent (Windows) support custom headers, so options exist for end users to use it. -- William ___ 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
