Mailman headers roundup
I've created a list to sum up the current discussion/threads on the mailman header work.
The list is separated in four sections:
I. CLARIFY Needs discussion.
II. MODIFY Needs to be registered with IETF or changes X- name.
III. KEEP Do not change
VI. DELETE Remove from MM3 code
Please cross-check and pickup discussion on the CLARIFY items. Once we are done I will approach IETF for the headers that need standardizing.
I. CLARIFY X-List-Received-Date This only gets added when the message is sent to the archive. Modify to: List-Archive-Sent Next Step: Discuss
X-Message-ID-Hash propose an RFC as an extension of RFC 5064 Modify to: unclear Next Step: Discuss
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
X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369?
II. MODIFY X-Mailer Only used when Mailman originates messages such as autoresponses. Modify to: User-Agent Next Step: Change code
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
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
X-Content-Filtered-By I think this should be renamed to (X-)Mailman-Content-Filter. Modify to: Mailman-Content-Filter Next Step: Create RFC
III. KEEP X-Peer X-MailFrom X-RcptTo Ignore this, it's used in the test suite only. Next Step: Ignore
X-Originally-To Probably not worth changing. Next Step: Ignore
X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version Ignore these. Next Step: Ignore
X-Ack X-No-Ack These should keep the X- prefix. Next Step: Ignore
X-Approve X-Approved need to keep the above two for backward compatibility Next Step: Ignore
VI. DELETE X-Mailman-Copy It can either be removed or lose the X- prefix. Next Step: Remove from code
X-BeenThere legacy Next Step: Remove from code
X-Archive X-No-Archive deprecated Next Step: Remove from code
X-List-Administrivia X-List-Administrivia is just useless and should be removed. Next Step: Remove from code
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
-----Original Message----- From: mailman-developers-bounces+msk=cloudmark.com@python.org [mailto:mailman-developers-bounces+msk=cloudmark.com@python.org] On Behalf Of Patrick Ben Koetter Sent: Sunday, October 30, 2011 12:04 PM To: Mailman Developers Subject: [Mailman-Developers] Mailman headers roundup
I've created a list to sum up the current discussion/threads on the mailman header work. [...]
Nice!
For the ones that are at "Create RFC", does someone have a specific syntax they should follow, especially something like ABNF? That plus a description makes crafting the RFC easy.
Patrick Ben Koetter writes:
X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369?
New RFC. Once you get to the RFC stage, you don't modify them (even for typos, they publish errata).
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.
Modify to: Tag
That's horrible, given the number of different uses for "Tag" in the email-using community (mostly in other contexts). Also, "tag" is generally connotes filtering by the client, while Mailman does the filtering at the server.
Both of those words need at least a "List-" qualifier, and probably a "Mailman-" qualifier given their Mailman-specific usage.
Next Step: Create RFC
No, the next step is to talk to other MLM developers. If they don't support it, I doubt any RFC will fly.
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
I don't see any need for RFCs for either of those, or any need for a name change, for that matter.
X-Content-Filtered-By I think this should be renamed to (X-)Mailman-Content-Filter. Modify to: Mailman-Content-Filter Next Step: Create RFC
I don't see a purpose to this. User-Agent, Mediator can be used to identify the agent. If you're going to be specific about what was filtered, that information should go into Rule-Hist.
X-Originally-To Probably not worth changing. Next Step: Ignore
X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version Ignore these. Next Step: Ignore
X-Ack X-No-Ack These should keep the X- prefix. Next Step: Ignore
X-Approve X-Approved need to keep the above two for backward compatibility Next Step: Ignore
AFAIK all of the above are incoming headers. We cannot change them, only decide whether to interpret them and if so, how.
X-BeenThere legacy Next Step: Remove from code
This needs discussion. The proposal to remove it depends on whether the issue about header spam has really been resolved, or if we're just not hearing complaints because people whose subscribers use mailers that display the List-* headers have turned them off.
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.
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
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+topicname@example.com style email addresses to create sublists (listname+new@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
On Nov 02, 2011, at 02:38 PM, Terri Oda wrote:
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.
Yes, please! :)
-Barry
On Nov 02, 2011, at 09:26 AM, William Bagwell wrote:
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?
The topics feature was funded and promoted by Control.com way back in the 2.1 alpha days (the NEWS file says it was released in 2.1a3 on 22-Oct-2001). IIRC we had quite a few discussions both internally and publicly about what Control.com needed, and how best to generalize the feature for the Mailman community.
-Barry
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
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
On Nov 02, 2011, at 11:14 AM, C Nulk wrote:
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.
I agree, but I think Mailman should be adding a Received header for that.
https://bugs.launchpad.net/mailman/+bug/885715
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.
Agreed, and this is how MM3 currently works.
Cheers, -Barry
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
On Nov 02, 2011, at 12:00 PM, Chris Clark wrote:
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 idea behind the header is to enhance RFC 5064 so that the MLM can pre-calculate Archived-At for the destination archive, without any interaction from that archiver. It also enables users to do the same.
Message-ID-Hash is primarily a convenience value which provides the last component in Archived-At. Thus Archived-At is calculated as <base_url>/<mid_hash> where <base_url> is typically the List-Archive header value and <mid_hash> is Message-ID-Hash.
The choice of Base 32 was deliberate. It's seen as a trade-off between uniqueness and (potentially <wink>) human readable.
http://wiki.list.org/display/DEV/Stable+URLs
The reason you do not want variability in the algorithm is because you want to be able to calculate the Archived-At value given only the Message-ID and the archiver base url. Having to also exchange knowledge of the algorithm used would make this less usable IMO.
Let's say I know that messages to mailman-developers are archived at mail.python.org, gmane.org and www.mail-archive.com, and I somehow know that your original message has Message-ID: <4EB1933E.9080707@actian.com>, I don't need anything else to find your message:
>>> from hashlib import sha1
>>> from base64 import b32encode
>>> mid_hash = b32encode(sha1('<4EB1933E.9080707@actian.com>').digest())
>>> mid_hash
'ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6'
>>> for base in ('gmane.org', 'mail-archive.com', 'mail.python.org'):
... print 'http://{0}/{1}'.format(base, mid_hash)
...
http://gmane.org/ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6
http://mail-archive.com/ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6
http://mail.python.org/ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6That's the compelling argument behind the *concept* of Message-ID-Hash, but as you can see, it's easy to calculate with just two pieces of information, one of which is static and the other which is fairly easy to convey.
Cheers, -Barry
- Barry Warsaw <barry@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@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
On 11/2/2011 1:31 PM, Patrick Ben Koetter wrote:
- Barry Warsaw <barry@list.org>:
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 <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----Original Message----- From: mailman-developers-bounces+msk=cloudmark.com@python.org [mailto:mailman-developers-bounces+msk=cloudmark.com@python.org] On Behalf Of Mark Sapiro Sent: Wednesday, November 02, 2011 2:57 PM To: mailman-developers@python.org Subject: Re: [Mailman-Developers] Mailman headers roundup
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.
Sometimes Message-ID includes the queue ID. That's the case with sendmail, as I recall.
The queue ID is also typically part of the Received: field already.
On 2 Nov 2011, at 15:06, Barry Warsaw wrote:
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.
Fine, but not hashtag, since there will, presumably, be no requirement to use the hash character. Hashtags were invented for inline use in Twitter. These aren't hashtags.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
- Barry Warsaw <barry@list.org>:
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.
Here's why I would prefer "Mediator":
What we want is a header field name that indicates the message has been accepted, modified and forwared by a program.
The header field name 'List-Agent' does that, but it is specific to mailing lists. The term 'Mediator' describes the same, but it is general in meaning. Any instance modifying and forwarding a message can use it.
If we use List-Agent others will have to register another header field name - 'Mediator' would fit for all.
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
On 11/10/2011 12:33 PM, Patrick Ben Koetter wrote:
- Barry Warsaw <barry@list.org>:
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. Here's why I would prefer "Mediator":
What we want is a header field name that indicates the message has been accepted, modified and forwared by a program.
The header field name 'List-Agent' does that, but it is specific to mailing lists. The term 'Mediator' describes the same, but it is general in meaning. Any instance modifying and forwarding a message can use it.
If we use List-Agent others will have to register another header field name - 'Mediator' would fit for all.
p@rick
I understand what you are saying. To me "Mediator" doesn't describe the same information specifically because it is too general in meaning. "List-Agent" as the header makes sense to me. Mailman manages whatever email distribution lists I create or manage, dealing with "lists" and the message traffic back and forth to it and subscribers. To me, it acts as a agent, thus "List-Agent" makes more sense. In addition, when I am or have to look through a messages headers to see what is happening, I want to be able to group common headers together. All the "Received" headers, all the "List-" headers so I can get a sense of things faster. The "Mediator" header doesn't lend itself to doing so. It is out on its own.
This header discussion, to me, is about identifying and registering common headers useful for Mailman in particular and Mailing List Managers in general. The "List-Agent" header works best and working with other MLMs to register the common headers is for the best.
I don't think we are trying to solve all the issues associated with email processing, only a little piece. If other software packages that may have some small interaction with email need a header, then let them build a consensus around their header and then register it. If, later in time, it turns out there is a need for a super-set of headers that includes MLMs, then maybe the "Mediator" header is appropriate which wouldn't conflict with "List-Agent".
For now, I think "List-Agent" is the best solution to provide a descriptive header for Mailman and other MLMs which when used with other proposed "List-" headers allows one to easily identify a MLM and its interactions with a message.
Sorry for the long post.
Thanks, Chris
On Nov 10, 2011, at 02:17 PM, C Nulk wrote:
I understand what you are saying. To me "Mediator" doesn't describe the same information specifically because it is too general in meaning. "List-Agent" as the header makes sense to me.
I'm torn. I see where Patrick is coming from, but I also wonder as Chris does, whether Mediator is too generic.
So I guess I'll punt for now. This bug tracks updating the headers:
https://bugs.launchpad.net/mailman/+bug/883193and it would be pretty easy to change X-Mailman-Version to List-Agent, Mediator, something else, or any of the above.
-Barry
Barry Warsaw writes:
On Nov 10, 2011, at 02:17 PM, C Nulk wrote:
I understand what you are saying. To me "Mediator" doesn't describe the same information specifically because it is too general in meaning. "List-Agent" as the header makes sense to me.
Mediator generalizes across decision-makers (human, program) and applications (news, web forum). But it's more specialized in the context of list management, IMHO applicable only when the list agent changes the content (other than prepending/appending brief "This is the XXX list" notices).
I think the two headers have different roles.
and it would be pretty easy to change X-Mailman-Version to List-Agent, Mediator, something else, or any of the above.
The replacement for X-Mailman-Version and X-Mailer and User-Agent (in Mailman usage) should be replaced by List-Agent (or folded into User-Agent, but I prefer List-Agent for this purpose).
So I guess I'll punt for now. This bug tracks updating the headers:
https://bugs.launchpad.net/mailman/+bug/883193
Should this post have gone to the bug instead? (I might not have bothered if so, but usually I'd be willing to update a bug if either a policy is in place or explicitly requested.)
Whatever you folks decide about List-Agent vs. Mediator, I'd be happy to help write up an RFC draft that registers the various header field names and descriptions and start it on its path to standardization.
However, the IETF might want to change it to the opposite name from the one you pick, or even something else. So you're quite possibly going to repeat this debate in their forum, so save (some of) your strength.
"Just saying." :-)
-MSK
participants (10)
-
Barry Warsaw -
C Nulk -
Chris Clark -
Ian Eiloart -
Mark Sapiro -
Murray S. Kucherawy -
Patrick Ben Koetter -
Stephen J. Turnbull -
Terri Oda -
William Bagwell