From msk at cloudmark.com Wed Oct 12 23:46:00 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Wed, 12 Oct 2011 14:46:00 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs Message-ID: Hi all, The IETF recently issued an RFC, with BCP status, regarding interaction between DKIM and MLMs. It seems like this community might be interested. http://www.ietf.org/rfc/rfc6377.txt Long ago I mentioned on this list that the IETF was undertaking this effort; this is the final product. I hope it's helpful. Thanks, -MSK From barry at list.org Thu Oct 13 17:30:12 2011 From: barry at list.org (Barry Warsaw) Date: Thu, 13 Oct 2011 11:30:12 -0400 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: Message-ID: <20111013113012.35438eee@limelight.wooz.org> On Oct 12, 2011, at 02:46 PM, Murray S. Kucherawy wrote: >The IETF recently issued an RFC, with BCP status, regarding interaction >between DKIM and MLMs. It seems like this community might be interested. > >http://www.ietf.org/rfc/rfc6377.txt > >Long ago I mentioned on this list that the IETF was undertaking this effort; >this is the final product. I hope it's helpful. It is, and thanks very much for sending us the reference. I found myself nodding my head quite a bit as I read it, often thinking "yeah, we do that". I'm in general agreement with the recommendations, so just a few notes here. $3.3 "In general, absent a general movement by MLM developers and operators toward more DKIM-friendly practices, an MLM subscriber cannot expect signatures applied before the message was processed by the MLM to be valid on delivery to a Receiver. Such an evolution is not expected in the short term due to general development and deployment inertia. Moreover, even if an MLM currently passes messages unmodified such that Author signatures validate, it is possible that a configuration change or software upgrade to that MLM will cause that no longer to be true." For Mailman, I think we'd like to, and would generally be able to be more DKIM-friendly, if we actually knew what to do. Short of not modifying the incoming message at all, and absent clear guidelines in this or any other RFC, we're just flailing in the dark. I think the RFC makes it clear though that there really are no good answers. It's a minor point that has no practical effect, but I think it states our project's general policy of wanting to be as RFC-compliant as possible. I do agree with the RFC's point that the output of a resending MLM (such as Mailman) is a new message, i.e. it is the originator. The original message has been received, and its existence in the mail infrastructure is complete. $4.4 points to what I think is the right solution for us, and which we already largely implement. If a site running Mailman wants to verify signatures on incoming posts, it should do this in the receiving MTA that feeds messages to Mailman. And if they want to sign outgoing messages, again this is done in the outgoing MTA that Mailman feeds messages to ($5.8). Mailman should not verify or DKIM sign anything. Mailman's is moderately DKIM aware, in that it will simply remove DKIM headers if configured to do so, and this should be the default (backed up by $5.7 as I read it). $5.2 "A resending MLM SHOULD reject outright any mail from an Author whose domain posts such a policy, as those messages are likely to be discarded or rejected by any ADSP-aware recipients." Within Mailman's architecture, this would be the prerogative of the incoming MTA feeding messages to Mailman. $5.3 Interesting that they recommend checking ADSP at subscription time, with periodic rechecks. Given that discardable is not a recommended policy, I can't see the value of Mailman doing this; the extra code and complexity isn't worth it. It would be useful though to make sure that a plugin could be written to add such verifications should some site decide they want it. $5.6 is interesting too (using DKIM as input to posting privileges). I put this in the same general category as using OpenPGP signatures to verify posting permissions. Again, probably not something we'd support out of the box, but certainly we'd provide hooks for those who want it (and Mailman's internal OpenPGP verifier, which I hope we'll gain at some point, would use the same API). $5.11 indicates possible enhancements to Mailman's bounce policy. Again, thanks. It's nice to see specific guidelines published as an RFC which we can then refer to for justification of Mailman's policy and features. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From msk at cloudmark.com Thu Oct 13 20:21:14 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Thu, 13 Oct 2011 11:21:14 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111013113012.35438eee@limelight.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> Message-ID: > -----Original Message----- > From: Barry Warsaw [mailto:barry at list.org] > Sent: Thursday, October 13, 2011 8:30 AM > To: Murray S. Kucherawy > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > For Mailman, I think we'd like to, and would generally be able to be > more DKIM-friendly, if we actually knew what to do. Short of not > modifying the incoming message at all, and absent clear guidelines in > this or any other RFC, we're just flailing in the dark. I think the > RFC makes it clear though that there really are no good answers. It's > a minor point that has no practical effect, but I think it states our > project's general policy of wanting to be as RFC-compliant as possible. The document does point out that the "friendly" approach is to put stuff like URLs for querying archives and unsubscription instructions up in the header using the List-* fields specified in RFC2919 and RFC2369 rather than as body suffixes, and don't tag Subject: fields (or, at least, have that off-by-default). Essentially to be "DKIM-friendly" you're free to make any changes you want to the message so long as they are confined to those parts of the message not "covered" by the DKIM signature. So if a signature doesn't cover Subject:, you're fine. Obviously there are many MUAs out there that filter/sort based on the Subject: tags that will be affected to some degree, but they could also take the same action on a List-ID: field just as easily. And any MUA that orders a mailbox based on threading using References: and In-Reply-To: won't be affected at all. > Again, thanks. It's nice to see specific guidelines published as an > RFC which we can then refer to for justification of Mailman's policy > and features. Glad we could be of service! -MSK From stephen at xemacs.org Fri Oct 14 03:48:44 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 14 Oct 2011 10:48:44 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> Message-ID: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> Murray S. Kucherawy writes: > Essentially to be "DKIM-friendly" you're free to make any changes > you want to the message so long as they are confined to those parts > of the message not "covered" by the DKIM signature. So if a > signature doesn't cover Subject:, you're fine. Obviously there are > many MUAs out there that filter/sort based on the Subject: tags > that will be affected to some degree, but they could also take the > same action on a List-ID: field just as easily. That's not true for Mailman topics, though. I guess we can add an X-Mailman-Topic field to handle that. From msk at cloudmark.com Fri Oct 14 08:41:37 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Thu, 13 Oct 2011 23:41:37 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > -----Original Message----- > From: Stephen J. Turnbull [mailto:stephen at xemacs.org] > Sent: Thursday, October 13, 2011 6:49 PM > To: Murray S. Kucherawy > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > That's not true for Mailman topics, though. I guess we can add an > X-Mailman-Topic field to handle that. There's movement afoot to deprecate use of "X-" in header field names. Just call it "Mailman-Topic". And if it's worthwhile, consider registering it with IANA. From barry at list.org Fri Oct 14 20:37:28 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 14 Oct 2011 14:37:28 -0400 Subject: [Mailman-Developers] [Bug 869317] Re: Mailman startup script missing --force option. In-Reply-To: <20111014182102.30342.1048.malone@soybean.canonical.com> References: <20111006162028.11515.35600.malonedeb@gac.canonical.com> <20111014182102.30342.1048.malone@soybean.canonical.com> Message-ID: <20111014143728.1ab92430@limelight.wooz.org> On Oct 14, 2011, at 06:21 PM, Stephen A. Goss wrote: >The patch I uploaded doesn't really fix the problem. With that patch, >if there is a stale lock file, it raises an AttributeError, then if you >run with --force, you get a different error, and then if you try again >without the --force option it starts up normally :/ I think I have a fix in my local copy, but I'm currently hung up on one particularly nasty test failure. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From iane at sussex.ac.uk Mon Oct 24 16:00:13 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 24 Oct 2011 14:00:13 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> Message-ID: <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> On 13 Oct 2011, at 19:21, Murray S. Kucherawy wrote: > > The document does point out that the "friendly" approach is to put stuff like URLs for querying archives and unsubscription instructions up in the header using the List-* fields specified in RFC2919 and RFC2369 rather than as body suffixes, and don't tag Subject: fields (or, at least, have that off-by-default). Of course, that's DKIM friendly. But, while most mail clients don't expose those headers to the users, it isn't user-friendly. And, in most of Europe, for many lists, it isn't legal to hide an unsubscribe address in the headers. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From msk at cloudmark.com Mon Oct 24 16:02:00 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Mon, 24 Oct 2011 07:02:00 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> Message-ID: > -----Original Message----- > From: Ian Eiloart [mailto:iane at sussex.ac.uk] > Sent: Monday, October 24, 2011 7:00 AM > To: Murray S. Kucherawy > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > Of course, that's DKIM friendly. But, while most mail clients don't > expose those headers to the users, it isn't user-friendly. And, in most > of Europe, for many lists, it isn't legal to hide an unsubscribe > address in the headers. Isn't "hide" a function of the MUA, not the MLM or MTA? From iane at sussex.ac.uk Mon Oct 24 16:24:25 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 24 Oct 2011 14:24:25 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> Message-ID: On 24 Oct 2011, at 15:02, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Ian Eiloart [mailto:iane at sussex.ac.uk] >> Sent: Monday, October 24, 2011 7:00 AM >> To: Murray S. Kucherawy >> Cc: mailman-developers at python.org >> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs >> >> Of course, that's DKIM friendly. But, while most mail clients don't >> expose those headers to the users, it isn't user-friendly. And, in most >> of Europe, for many lists, it isn't legal to hide an unsubscribe >> address in the headers. > > Isn't "hide" a function of the MUA, not the MLM or MTA? No. "Display" or "Expose" might be a function of the MUA. "Find" might be something that the user does. To hide something is to put it in a location where it's unlikely to be found. As long as you know that people aren't looking there (and they're not), putting information in a header (other than to, from subject and date) is "hiding". -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From msk at cloudmark.com Mon Oct 24 16:31:58 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Mon, 24 Oct 2011 07:31:58 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> Message-ID: > -----Original Message----- > From: Ian Eiloart [mailto:iane at sussex.ac.uk] > Sent: Monday, October 24, 2011 7:24 AM > To: Murray S. Kucherawy > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > > Isn't "hide" a function of the MUA, not the MLM or MTA? > > No. "Display" or "Expose" might be a function of the MUA. "Find" might > be something that the user does. To hide something is to put it in a > location where it's unlikely to be found. > > As long as you know that people aren't looking there (and they're not), > putting information in a header (other than to, from subject and date) > is "hiding". My point is that if using header fields is the right way to encode this information in a protocol sense, then the issue is really that the MUAs need to expose that information somehow. I have some trouble with the assertion that making the MLM and MTA do what we all agree is the right thing to do constitutes "hiding". From Richard at Damon-Family.org Mon Oct 24 17:17:40 2011 From: Richard at Damon-Family.org (Richard Damon) Date: Mon, 24 Oct 2011 11:17:40 -0400 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> Message-ID: <4EA58194.7090108@Damon-Family.org> On 10/24/11 10:31 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Ian Eiloart [mailto:iane at sussex.ac.uk] >> Sent: Monday, October 24, 2011 7:24 AM >> To: Murray S. Kucherawy >> Cc: mailman-developers at python.org >> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs >> >>> Isn't "hide" a function of the MUA, not the MLM or MTA? >> No. "Display" or "Expose" might be a function of the MUA. "Find" might >> be something that the user does. To hide something is to put it in a >> location where it's unlikely to be found. >> >> As long as you know that people aren't looking there (and they're not), >> putting information in a header (other than to, from subject and date) >> is "hiding". > My point is that if using header fields is the right way to encode this information in a protocol sense, then the issue is really that the MUAs need to expose that information somehow. > > I have some trouble with the assertion that making the MLM and MTA do what we all agree is the right thing to do constitutes "hiding". > The problem is that the Core Mail RFCs (822/2822) doesn't say that the headers are the right place to put this info, and thus it can't be assumed that MUA should display such a header. The LIST_UNSUBSCRIBE header is only defined in RFC 2369, but not the core RFC 2822 (Internet message format), as such the existence of MUA that don't understand it can be reasonable expected (as is seen in practice). The conflict in needs between DKIM and MLM becomes a legal issue is some jurisdictions. The LAW (which trumps any RFC) demands a conspicuous notice, so the MLM must provide it. The header provided in RFC 2369 is not sufficient due to too many MUAs not complying with it. This makes DKIM suggestion to only use it (and not add the link to the message) actually illegal in some places. Since the MLM were around first (and the law), this becomes a defect in DKIM. From stephen at xemacs.org Mon Oct 24 19:37:53 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 25 Oct 2011 02:37:53 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> Message-ID: <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> Murray S. Kucherawy writes: > My point is that if using header fields is the right way to encode > this information in a protocol sense, then the issue is really that > the MUAs need to expose that information somehow. The success of the IETF RFC process is due to the fact that protocol is built on existing practice, and compatible with it. Asking that reality serve the needs of your spec is neither workable[1] nor compatible with the philosophy of the RFC process. > I have some trouble with the assertion that making the MLM and MTA > do what we all agree is the right thing to do constitutes "hiding". But we *don't* agree that displaying the header is the right thing. MUAs might very well provide buttons or menu items or keystrokes to implement the corresponding function, rather than display the header. I doubt this satisfies the requirements of such laws. Footnotes: [1] Good luck getting Joe Average to give up his Outlook, and even better luck getting Microsoft to expose protocol headers in a sane way. From barry at python.org Tue Oct 25 03:04:03 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 24 Oct 2011 21:04:03 -0400 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20111024210403.1395d359@resist.wooz.org> On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: >There's movement afoot to deprecate use of "X-" in header field names. Just >call it "Mailman-Topic". And if it's worthwhile, consider registering it >with IANA. I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of ones we still add or recognize (some might be used only in the test suite): X-Message-ID-Hash X-Mailman-Rule-Hits X-Mailman-Rule-Misses X-BeenThere X-Mailman-Version X-Mailman-Approved-At X-Archive X-No-Archive X-Ack X-No-Ack X-Peer X-MailFrom X-RcptTo X-Originally-To X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version X-Mailman-Copy X-List-Administrivia X-Content-Filtered-By X-Topics X-Mailer X-List-Received-Date X-Approve X-Approved -Barry From Pidgeot18 at gmail.com Tue Oct 25 03:55:23 2011 From: Pidgeot18 at gmail.com (Joshua Cranmer) Date: Mon, 24 Oct 2011 20:55:23 -0500 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111024210403.1395d359@resist.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> Message-ID: <4EA6170B.8020903@gmail.com> On 10/24/2011 8:04 PM, Barry Warsaw wrote: > On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: > >> There's movement afoot to deprecate use of "X-" in header field names. Just >> call it "Mailman-Topic". And if it's worthwhile, consider registering it >> with IANA. > I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of > ones we still add or recognize (some might be used only in the test suite): I believe the rule of thumb is you're supposed to use the X- prefix if it's not registered, so until the header is registered at IANA, I would vote that the X- prefix stays retained. -- Joshua Cranmer News submodule owner DXR coauthor From stephen at xemacs.org Tue Oct 25 09:47:19 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 25 Oct 2011 16:47:19 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <4EA6170B.8020903@gmail.com> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <4EA6170B.8020903@gmail.com> Message-ID: <87mxcp5x88.fsf@uwakimon.sk.tsukuba.ac.jp> Joshua Cranmer writes: > On 10/24/2011 8:04 PM, Barry Warsaw wrote: > > On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: > >> There's movement afoot to deprecate use of "X-" in header field > >> names. Just call it "Mailman-Topic". And if it's worthwhile, > >> consider registering it with IANA. > > > > I wonder if we should remove the X- prefixes for Mailman 3. > > Here's a list of ones we still add or recognize (some might be > > used only in the test suite): I would say that anything that is used only in the test suite should still get an X-, although I suppose you could use Mailman-Test- too. > I believe the rule of thumb is you're supposed to use the X- prefix if > it's not registered, so until the header is registered at IANA, I would > vote that the X- prefix stays retained. What Murray is saying is that the rule of thumb is changing in response to experience. What has happened is that the experience with promoting an X-Foo header to just Foo has been poor, and the attendant confusion often hinders adoption. So many people have been in the habit of ignoring the X- namespace anyway (the most widespread example I know of is the adoption of Mail-Followup-To in mail, which has no[1] sanction in the RFCs, although it's a long-standard header in news). Footnotes: [1] Last I checked, anyway, a couple years ago, but widespread usage dates back to at least 2003. From msk at cloudmark.com Tue Oct 25 10:47:46 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 25 Oct 2011 01:47:46 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > -----Original Message----- > From: Stephen J. Turnbull [mailto:stephen at xemacs.org] > Sent: Monday, October 24, 2011 10:38 AM > To: Murray S. Kucherawy > Cc: Ian Eiloart; mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > The success of the IETF RFC process is due to the fact that protocol > is built on existing practice, and compatible with it. Asking that > reality serve the needs of your spec is neither workable[1] nor > compatible with the philosophy of the RFC process. I don't have a reality suspension field in effect on this topic. I was simply disputing the claim that complying with the List-Unsubscribe RFC constitutes "hiding" of those details. I understand the legal issues, and so I suggest that bringing them to the attention of MUA vendors might be a better solution given the pressures of the current evolution of the email environment. I don't claim MLMs are broken in this regard, but I do think some more modern thinking by all components is in order. > Footnotes: > [1] Good luck getting Joe Average to give up his Outlook, and even > better luck getting Microsoft to expose protocol headers in a sane way. Microsoft, for example, appears to be paying a little more attention to this stuff than they used to as they (quietly) begin supporting things like DKIM. Thus, I'm ever so slightly more hopeful than I used to be. From stephen at xemacs.org Tue Oct 25 11:50:26 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 25 Oct 2011 18:50:26 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87fwih5rj1.fsf@uwakimon.sk.tsukuba.ac.jp> Murray S. Kucherawy writes: > I don't have a reality suspension field in effect on this topic. I > was simply disputing the claim that complying with the > List-Unsubscribe RFC constitutes "hiding" of those details. It's not deliberate, let alone malicious, but it does conceal the details from the user's view, both in current practice (where few MUAs -- at least weighted by user count -- implement reasonable handling of those headers) and in reasonable implementations of the RFC (as in the part of my post that you snipped). > I don't claim MLMs are broken in this regard, but I do think some > more modern thinking by all components is in order. I agree, and have no objection to advocacy, or to RFCs that take advantage of more modern thinking. But that's very different from arguing that a defect in the DKIM RFC is really a problem of the implementations. From msk at cloudmark.com Tue Oct 25 12:00:30 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 25 Oct 2011 03:00:30 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <87fwih5rj1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwih5rj1.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > -----Original Message----- > From: Stephen J. Turnbull [mailto:stephen at xemacs.org] > Sent: Tuesday, October 25, 2011 2:50 AM > To: Murray S. Kucherawy > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > I agree, and have no objection to advocacy, or to RFCs that take > advantage of more modern thinking. But that's very different from > arguing that a defect in the DKIM RFC is really a problem of the > implementations. Well, I also don't agree with characterizing this as a defect in the DKIM RFC. From p at state-of-mind.de Tue Oct 25 13:04:16 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 25 Oct 2011 13:04:16 +0200 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <87mxcp5x88.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <4EA6170B.8020903@gmail.com> <87mxcp5x88.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20111025110415.GB3282@state-of-mind.de> * Stephen J. Turnbull : > Joshua Cranmer writes: > > On 10/24/2011 8:04 PM, Barry Warsaw wrote: > > > On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: > > > >> There's movement afoot to deprecate use of "X-" in header field > > >> names. Just call it "Mailman-Topic". And if it's worthwhile, > > >> consider registering it with IANA. > > > > > > I wonder if we should remove the X- prefixes for Mailman 3. > > > Here's a list of ones we still add or recognize (some might be > > > used only in the test suite): > > I would say that anything that is used only in the test suite should > still get an X-, although I suppose you could use Mailman-Test- too. Is it possible to register a prefix (namespace) such as mailman-. Anything below would be mailman related. Stupid idea? 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 From stephen at xemacs.org Tue Oct 25 15:04:10 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 25 Oct 2011 22:04:10 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111025110415.GB3282@state-of-mind.de> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <4EA6170B.8020903@gmail.com> <87mxcp5x88.fsf@uwakimon.sk.tsukuba.ac.jp> <20111025110415.GB3282@state-of-mind.de> Message-ID: <87bot55ik5.fsf@uwakimon.sk.tsukuba.ac.jp> Patrick Ben Koetter writes: > Is it possible to register a prefix (namespace) such as mailman-. Anything > below would be mailman related. Stupid idea? Very plausible, but I suspect there are good reasons not to allow it in the RFC 822/1036 messaging series. In any case, no, it's not possible. There is a way to do it in other namespaces though, eg, in MIME media types you have the vnd.* space. From msk at cloudmark.com Tue Oct 25 15:41:02 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 25 Oct 2011 06:41:02 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <87bot55ik5.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <4EA6170B.8020903@gmail.com> <87mxcp5x88.fsf@uwakimon.sk.tsukuba.ac.jp> <20111025110415.GB3282@state-of-mind.de> <87bot55ik5.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org > [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On > Behalf Of Stephen J. Turnbull > Sent: Tuesday, October 25, 2011 6:04 AM > To: Patrick Ben Koetter > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > Patrick Ben Koetter writes: > > > Is it possible to register a prefix (namespace) such as mailman-. Anything > > below would be mailman related. Stupid idea? > > Very plausible, but I suspect there are good reasons not to allow it > in the RFC 822/1036 messaging series. In any case, no, it's not > possible. > > There is a way to do it in other namespaces though, eg, in MIME media > types you have the vnd.* space. I agree. The best you could do is just claim the "Mailman-*" space de facto by starting to use it, and then start registering the ones that appear to be useful and popular. From Richard at Damon-Family.org Tue Oct 25 16:26:37 2011 From: Richard at Damon-Family.org (Richard Damon) Date: Tue, 25 Oct 2011 10:26:37 -0400 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwih5rj1.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4EA6C71D.20309@Damon-Family.org> On 10/25/11 6:00 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Stephen J. Turnbull [mailto:stephen at xemacs.org] >> Sent: Tuesday, October 25, 2011 2:50 AM >> To: Murray S. Kucherawy >> Cc: mailman-developers at python.org >> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs >> >> I agree, and have no objection to advocacy, or to RFCs that take >> advantage of more modern thinking. But that's very different from >> arguing that a defect in the DKIM RFC is really a problem of the >> implementations. > Well, I also don't agree with characterizing this as a defect in the DKIM RFC. > I would consider an RFC that tells some people they need to violate the laws of their country to follow it to have a defect. Their are places, like Germany has been mentioned, where bulk mailers, like Mailing Lists, need to place in a prominent place unsubscription instructions. It is a fact, that in the current state of software, the LIST-UNSUBSCRIBE header is not likely to be seen by a typical user. Therefore, the only legal place to put the required notice is in the body of the message. Now, if 90+% of people would see the LIST-UNSUBSCRIBE header someone might be able to make a case that the few who didn't should have been able to see it, but with Current MUAs it isn't seen. I suspect that (way) less than 10% of people would see the LIST-UNSUBSCRIBE header unless they went looking for it. Is there even an MUA that by default will show it? How many people have MUAs that can even be easily configured to show this header and not all headers? I can think of a few that can be configured to add arbitrary headers to the default show list, but these are not the ones used by most people, but I am not sure if I can think of one that knows about this header so you can add it without having to personally know about it. From msk at cloudmark.com Tue Oct 25 16:53:08 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 25 Oct 2011 07:53:08 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <4EA6C71D.20309@Damon-Family.org> References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwih5rj1.fsf@uwakimon.sk.tsukuba.ac.jp> <4EA6C71D.20309@Damon-Family.org> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org > [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On > Behalf Of Richard Damon > Sent: Tuesday, October 25, 2011 7:27 AM > To: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > > Well, I also don't agree with characterizing this as a defect in the > > DKIM RFC. > > I would consider an RFC that tells some people they need to violate the > laws of their country to follow it to have a defect. The RFC doesn't say you have to do that. What it says is the list should re-sign if it modifies the message (or, in general, re-sign anyway). So append whatever you want, just re-sign the message. Are you insisting that advice is defective? What it also says is if you want author signatures to survive MLMs, then you have to re-think those practices. But nobody really expects that right now, I think. From stephen at xemacs.org Tue Oct 25 18:13:27 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 26 Oct 2011 01:13:27 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwih5rj1.fsf@uwakimon.sk.tsukuba.ac.jp> <4EA6C71D.20309@Damon-Family.org> Message-ID: <878vo959so.fsf@uwakimon.sk.tsukuba.ac.jp> Murray S. Kucherawy writes: > What it says is the list should re-sign if it modifies the message > (or, in general, re-sign anyway). So append whatever you want, > just re-sign the message. Are you insisting that advice is > defective? Defective, maybe not. But I don't think I would follow it for my own lists. I'd rather remove the signature and tell people who are using anal-retentive ISPs that refuse to pass unsigned messages to switch, because there are too many people out there who will report you as a spammer rather than unsubscribe. I don't want my signature associated with any such thing. From Pidgeot18 at gmail.com Tue Oct 25 18:20:49 2011 From: Pidgeot18 at gmail.com (Joshua Cranmer) Date: Tue, 25 Oct 2011 11:20:49 -0500 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <87mxcp5x88.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <4EA6170B.8020903@gmail.com> <87mxcp5x88.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4EA6E1E1.2000609@gmail.com> On 10/25/2011 2:47 AM, Stephen J. Turnbull wrote: > Joshua Cranmer writes: > > On 10/24/2011 8:04 PM, Barry Warsaw wrote: > > > On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: > > > >> There's movement afoot to deprecate use of "X-" in header field > > >> names. Just call it "Mailman-Topic". And if it's worthwhile, > > >> consider registering it with IANA. > > > > > > I wonder if we should remove the X- prefixes for Mailman 3. > > > Here's a list of ones we still add or recognize (some might be > > > used only in the test suite): > > I would say that anything that is used only in the test suite should > still get an X-, although I suppose you could use Mailman-Test- too. > > > I believe the rule of thumb is you're supposed to use the X- prefix if > > it's not registered, so until the header is registered at IANA, I would > > vote that the X- prefix stays retained. > > What Murray is saying is that the rule of thumb is changing in > response to experience. What has happened is that the experience with > promoting an X-Foo header to just Foo has been poor, and the attendant > confusion often hinders adoption. So many people have been in the > habit of ignoring the X- namespace anyway (the most widespread example > I know of is the adoption of Mail-Followup-To in mail, which has no[1] > sanction in the RFCs, although it's a long-standard header in news). There is a formal procedure in place for the creation of new headers (RFC 3864); if you're going to drop the X-, you might as well at least attempt to get them provisionally accepted... -- Joshua Cranmer News submodule owner DXR coauthor From benedict.stein at googlemail.com Tue Oct 25 18:58:35 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Tue, 25 Oct 2011 18:58:35 +0200 Subject: [Mailman-Developers] Update on UI development Message-ID: <1319561915.3388.11.camel@benste-vpc-sb1c5e.home> Dear Mailman fellows, just a short update in terms of the WebUI - we all know that the targeted release date is now only a little bit more than two weeks to go - @Barry 11.11.2011 is still the target ? Regarding the WebUI development we promissed you to show of at least the results from GSOC this year, but unfortuneatly during some business related time issues we weren't able to do this yet. To be honest - at least for me it's the first day really taking a look at mailman after finishing GSOC, but I'm sure we'll all do our best to get this thing up and running. Florian tries to repair the tests for some tweaks which have been made in a8. And I start working on the UI as well again - at least in the evenings - (South African Time ~ CET) I've heard about one more fellow who wanted to step in - I'm sure we'll find time and place to organize some kind of small meeting - but that's up to Flo :) SUMMARY: Back to work ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: face-wink.png Type: image/png Size: 919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: face-smile.png Type: image/png Size: 925 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From barry at list.org Tue Oct 25 19:32:31 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 25 Oct 2011 13:32:31 -0400 Subject: [Mailman-Developers] Fw: [uds-announce] Design Theater Design sessions at UDS Message-ID: <20111025133231.45aedc09@resist.wooz.org> Is there any particular design issue you'd like me to raise for the Mailman 3 web ui or archive ui? There isn't much time to put this together, but I'm willing to do that if there's something worthwhile to have them discuss. If not, I might bring up a MM2 archive issue perhaps. -Barry Begin forwarded message: Date: Tue, 25 Oct 2011 13:42:11 -0300 From: Charline To: uds-announce at lists.ubuntu.com Subject: [uds-announce] Design Theater Design sessions at UDS Hello, The design team is planning to run design "theater" sessions at UDS. As a general rule, the design works on Canonical projects. It is our opportunity and pleasure during UDS to dedicate some time to help with other free open source software. * What is Design Theater?* During these sessions, we explore a design issue that you submit to us and take it through our design process. *Why should you come? *We hope to take you through the design process with real life examples, so we can share our design thinking and problem solving with you and propose any solution you might like. *How can you participate? *You have a choice: As an /observer/: come an look over our shoulders as we discuss applications design issues and join in the discussion. As a /participant/: bring us your free software application for which you need design guidance or user experience input. We'll try to fix it for you and show you how to approach this particular problem the design way. If you are thinking of joining us as a participant, please, send us your design question in advance, if you can, so we can get the ball rolling. Send it to: charline.poirier at canonical .com *Who will be there from the Design team? *At each session, you will find a user researcher, a brand designer, a user experience specialist, an interaction designer and a visual designer, *Come find about our process and challenge us!* -- *CHARLINE POIRIER* *Acting Head of Design* *Canonical* *27th floor, 21-24 Millbank Tower* *London SW1P 4QP UK* *Tel: +44 (0) 20 7630 2491* *Mob: +44 (0) 78 8695 4514* *www.Ubuntu.com * *www.Canonical.com* -------------- next part -------------- -- uds-announce mailing list uds-announce at lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/uds-announce -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From terri at zone12.com Tue Oct 25 23:32:46 2011 From: terri at zone12.com (Terri Oda) Date: Tue, 25 Oct 2011 15:32:46 -0600 Subject: [Mailman-Developers] Fw: [uds-announce] Design Theater Design sessions at UDS In-Reply-To: <20111025133231.45aedc09@resist.wooz.org> References: <20111025133231.45aedc09@resist.wooz.org> Message-ID: <4EA72AFE.5010106@zone12.com> Anything they can do with mm2 archives will help us make the mm3 ones better! I'd say they're highest priority since it affects the most people, but I'd also like to see better design applied to our admin pages, which can be quite painful to navigate... On 10/25/11 11:32, Barry Warsaw wrote: > Is there any particular design issue you'd like me to raise for the Mailman 3 > web ui or archive ui? There isn't much time to put this together, but I'm > willing to do that if there's something worthwhile to have them discuss. > > If not, I might bring up a MM2 archive issue perhaps. > > -Barry > > Begin forwarded message: > > Date: Tue, 25 Oct 2011 13:42:11 -0300 > From: Charline > To: uds-announce at lists.ubuntu.com > Subject: [uds-announce] Design Theater Design sessions at UDS > > > > Hello, > > The design team is planning to run design "theater" sessions at UDS. As a general rule, the design works on Canonical projects. It is our opportunity and pleasure during UDS to dedicate some time to help with other free open source software. > * > What is Design Theater?* > > During these sessions, we explore a design issue that you submit to us and take it through our design process. > > *Why should you come? > > *We hope to take you through the design process with real life examples, so we can share our design thinking and problem solving with you and propose any solution you might like. > > *How can you participate? > > *You have a choice: > > As an /observer/: come an look over our shoulders as we discuss applications design issues and join in the discussion. > > As a /participant/: bring us your free software application for which you need design guidance or user experience input. We'll try to fix it for you and show you how to approach this particular problem the design way. > > If you are thinking of joining us as a participant, please, send us your design question in advance, if you can, so we can get the ball rolling. Send it to: charline.poirier at canonical .com > > *Who will be there from the Design team? > > *At each session, you will find a user researcher, a brand designer, a user experience specialist, an interaction designer and a visual designer, > > *Come find about our process and challenge us!* > > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/terri%40zone12.com > > Security Policy: http://wiki.list.org/x/QIA9 From adam-mailman at amyl.org.uk Wed Oct 26 01:20:29 2011 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Wed, 26 Oct 2011 00:20:29 +0100 Subject: [Mailman-Developers] Update on UI development In-Reply-To: <1319561915.3388.11.camel@benste-vpc-sb1c5e.home> References: <1319561915.3388.11.camel@benste-vpc-sb1c5e.home> Message-ID: <20111025232029.GE21421@hendricks.amyl.org.uk> On Tue, Oct 25, 2011 at 06:58:35PM +0200, Benedict Stein wrote: > To be honest - at least for me it's the first day really taking a look > at mailman after finishing GSOC, but I'm sure we'll all do our best to > get this thing up and running. Thanks! It'll be appreciated. -- If you see a long line of rats streaming off of a ship, the correct assumption is not "Gosh, I bet that's a real nice boat now that those rats are gone". -- Mike Sphar From iane at sussex.ac.uk Wed Oct 26 14:43:46 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 26 Oct 2011 12:43:46 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111024210403.1395d359@resist.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> Message-ID: <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> On 25 Oct 2011, at 02:04, Barry Warsaw wrote: > On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: > >> There's movement afoot to deprecate use of "X-" in header field names. Just >> call it "Mailman-Topic". And if it's worthwhile, consider registering it >> with IANA. > > I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of > ones we still add or recognize (some might be used only in the test suite): > > X-Message-ID-Hash This could be replaced with DKIM sigs, I guess. > X-Mailman-Rule-Hits > X-Mailman-Rule-Misses This might be useful for diagnostics, but probably wants to be off in general. My view is that Mailman should not be doing message filtering. > X-BeenThere I guess that's useful for avoiding list loops, perhaps? > X-Mailman-Version I think this should be replaced with X-Mailer, or even User-Agent. That's not currently an SMTP header, but I think it should be. And it is in quite widespread use. > X-Mailman-Approved-At > X-Archive Does this do the same as List-Archive? > X-No-Archive What does this mean? > X-Ack > X-No-Ack > X-Peer > X-MailFrom > X-RcptTo Isn't that usually in the Received header? > X-Originally-To Doesn't that do the same thing as List-post? > X-Original-CC What's the purpose of including this? > X-Original-Content-Transfer-Encoding > X-MIME-Version > X-Mailman-Copy > X-List-Administrivia List-help? > X-Content-Filtered-By > X-Topics > X-Mailer I think we should use User-Agent here. Thunderbird does, as do some other mail clients. Or, we should push for introduction of a List-Agent header. > X-List-Received-Date Don't the Received headers carry this information? > X-Approve > X-Approved > > -Barry Generally, I think we should avoid the use of headers that duplicate other existing headers. Where we want to add more information, then extend the List-* header set if the information might be generally useful for mailing list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people know where the header came from. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From CNulk at scu.edu Wed Oct 26 17:00:15 2011 From: CNulk at scu.edu (C Nulk) Date: Wed, 26 Oct 2011 08:00:15 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> Message-ID: <4EA8207F.6000201@scu.edu> On 10/26/2011 5:43 AM, Ian Eiloart wrote: > On 25 Oct 2011, at 02:04, Barry Warsaw wrote: > >> On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: >> >>> There's movement afoot to deprecate use of "X-" in header field names. Just >>> call it "Mailman-Topic". And if it's worthwhile, consider registering it >>> with IANA. If registering headers is to be pursued, perhaps a standardized list of headers should be discussed with other MLM's and then put forth to IANA. The standardized headers should be able to handle generic list information along with MLM specific. My thought would be for List-* are generic headers all MLM's and MUA's can refer to for information. List-Mailman-* would be Mailman specific headers List-ListServ-* would be ListServ specific headers >> I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of >> ones we still add or recognize (some might be used only in the test suite): >> >> X-Message-ID-Hash > This could be replaced with DKIM sigs, I guess. > >> X-Mailman-Rule-Hits >> X-Mailman-Rule-Misses > This might be useful for diagnostics, but probably wants to be off in general. My view is that Mailman should not be doing message filtering. > >> X-BeenThere > I guess that's useful for avoiding list loops, perhaps? > >> X-Mailman-Version > I think this should be replaced with X-Mailer, or even User-Agent. That's not currently an SMTP header, but I think it should be. And it is in quite widespread use. I agree and disagree. I may be wrong but I see the X-Mailer specifying the MTA and User-Agent specifying the MUA. Perhaps a different header added by the MLM called List-Agent or List-ListAgent. > >> X-Mailman-Approved-At >> X-Archive > Does this do the same as List-Archive? > >> X-No-Archive > What does this mean? > >> X-Ack >> X-No-Ack >> X-Peer >> X-MailFrom >> X-RcptTo > Isn't that usually in the Received header? > >> X-Originally-To > Doesn't that do the same thing as List-post? > >> X-Original-CC > What's the purpose of including this? > >> X-Original-Content-Transfer-Encoding >> X-MIME-Version >> X-Mailman-Copy >> X-List-Administrivia > List-help? > >> X-Content-Filtered-By >> X-Topics >> X-Mailer > I think we should use User-Agent here. Thunderbird does, as do some other mail clients. Or, we should push for introduction of a List-Agent header. List-Agent header is my vote (see above :)) > >> X-List-Received-Date > Don't the Received headers carry this information? Maybe. They certainly contain the date the MTA received the message but not necessarily when the MLM received the message. Consider a message to be posted to a list. The MTA receives it and it is passed on to a Spam/AntiVirus device. The message is held at the device because is fails whatever checks are in place. Five days later, the device administrator goes through the held queue on the device, sees the message as okay and releases it. The MLM then receives the message to be posted. Now, when did the MLM really receive the message? When the MTA received it or five days later. I think there is enough of a possibility that keeping Received headers different from say a List-Received-Date header. > >> X-Approve >> X-Approved >> >> -Barry > Generally, I think we should avoid the use of headers that duplicate other existing headers. Where we want to add more information, then extend the List-* header set if the information might be generally useful for mailing list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people know where the header came from. I agree. Reduce and avoid duplication. Discussions should also occur with other MLM's to come up with a generic List-* header set. > -- > Ian Eiloart > Postmaster, University of Sussex > +44 (0) 1273 87-3148 Hope I made sense, Thanks, Chris > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/cnulk%40scu.edu > > Security Policy: http://wiki.list.org/x/QIA9 From p at state-of-mind.de Wed Oct 26 17:33:45 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Wed, 26 Oct 2011 17:33:45 +0200 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> Message-ID: <20111026153344.GD18712@state-of-mind.de> I searched mailman 2.1.14 sources and changelog to find out what they stand for. Read below. Which could/should we replace with already existing standardized headers? * Ian Eiloart : > On 25 Oct 2011, at 02:04, Barry Warsaw wrote: > > > On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: > > > >> There's movement afoot to deprecate use of "X-" in header field names. Just > >> call it "Mailman-Topic". And if it's worthwhile, consider registering it > >> with IANA. > > > > I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of > > ones we still add or recognize (some might be used only in the test suite): > > > > X-Message-ID-Hash > > This could be replaced with DKIM sigs, I guess. > > > X-Mailman-Rule-Hits > > X-Mailman-Rule-Misses > > This might be useful for diagnostics, but probably wants to be off in > general. My view is that Mailman should not be doing message filtering. Are they related to SpamAssassin filtering that can take place in MM? > > X-BeenThere > > I guess that's useful for avoiding list loops, perhaps? >From Mailman/Handlers/CookHeaders.py: # Mark message so we know we've been here, but leave any existing # X-BeenThere's intact. > > X-Mailman-Version > > I think this should be replaced with X-Mailer, or even User-Agent. That's > not currently an SMTP header, but I think it should be. And it is in quite > widespread use. >From Mailman/Handlers/CookHeaders.py: msg['X-Mailman-Version'] = mm_cfg.VERSION Seems to add the product version and not the User-Agent. > > X-Mailman-Approved-At >From Mailman/ListAdmin.py: # Queue the file for delivery by qrunner. Trying to deliver the # message directly here can lead to a huge delay in web # turnaround. Log the moderation and add a header. msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1) > > X-Archive > > Does this do the same as List-Archive? Looks like a control feature for senders: >From doc/mailman-admin.txt: Note that senders can control whether their own posts are archived, on an individual per-message basis. If the posted message has a X-No-Archive: header (regardless of value), or a X-Archive: header with a value of No (case insensitive), then the message will not be archived, although it will be treated as normal in all other ways. >From the changelog: o When a moderated message is approved for the list, add an X-Mailman-Approved-At: header which contains the timestamp of the approval action (changed from X-Moderated: with a different format). - Honor "X-Archive: No" header by not putting this message in the archive. > > X-No-Archive > > What does this mean? Seems like a dupe from X-Archive: >From the changelog: o Just the mere presence of an X-No-Archive: is enough to inhibit archiving for this message; the value of the header is now ignored. > > X-Ack >From the changelog: - Autoresponses, -request command responses, and posting hold notifications are inhibited for any message that has a Precedence: {bulk|list|junk} header. This is to avoid mail loops between email 'bots. If the original message has an X-Ack: yes header, the response is sent. > > X-No-Ack Is this still being used? Nothing in the changelog Nothing in the mailman-2.1.14 sources. > > X-Peer Is this still being used? Nothing in the changelog Nothing in the mailman-2.1.14 sources. > > X-MailFrom Is this still being used? Nothing in the changelog Nothing in the mailman-2.1.14 sources. > > X-RcptTo Is this still being used? Nothing in the changelog Nothing in the mailman-2.1.14 sources. > Isn't that usually in the Received header? > > > X-Originally-To > > Doesn't that do the same thing as List-post? Seems like a copy of Postfix' X-Original-To-header. Is it? >From cron/gate_news: del msg['X-Originally-To'] msg['X-Originally-To'] = msg['To'] > > X-Original-CC > What's the purpose of including this? >From Mailman/Defaults.py.in: # Next, these headers are left alone, unless there are duplicates in the # original message. Any second and subsequent headers are rewritten to the # second named header (case preserved). NNTP_REWRITE_DUPLICATE_HEADERS = [ ('to', 'X-Original-To'), ('cc', 'X-Original-Cc'), ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), ('mime-version', 'X-MIME-Version'), ] > > X-Original-Content-Transfer-Encoding >From Mailman/Defaults.py.in: # Next, these headers are left alone, unless there are duplicates in the # original message. Any second and subsequent headers are rewritten to the # second named header (case preserved). NNTP_REWRITE_DUPLICATE_HEADERS = [ ('to', 'X-Original-To'), ('cc', 'X-Original-Cc'), ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), ('mime-version', 'X-MIME-Version'), ] > > X-MIME-Version >From Mailman/Defaults.py.in: # Next, these headers are left alone, unless there are duplicates in the # original message. Any second and subsequent headers are rewritten to the # second named header (case preserved). NNTP_REWRITE_DUPLICATE_HEADERS = [ ('to', 'X-Original-To'), ('cc', 'X-Original-Cc'), ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), ('mime-version', 'X-MIME-Version'), ] > > X-Mailman-Copy Nothing in the changelog >From templates/en/options.html: Avoid duplicate copies of messages? When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select Yes to avoid receiving copies from the mailing list; select No to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. >From Mailman/Handlers/SMTPDirect.py: # We can flag the mail as a duplicate for each member, if they've # already received this message, as calculated by Message-ID. See # AvoidDuplicates.py for details. del msgcopy['x-mailman-copy'] if msgdata.get('add-dup-header', {}).has_key(recip): msgcopy['X-Mailman-Copy'] = 'yes' > > X-List-Administrivia >From the changelog: o X-List-Administrivia: is only added to messages Mailman creates and sends out of its own accord. >From Mailman/Handlers/CookHeaders.py: # For internally crafted messages, we also add a (nonstandard), # "X-List-Administrivia: yes" header. For all others (i.e. those coming # from list posts), we add a bunch of other RFC 2369 headers. > List-help? > > > X-Content-Filtered-By Nothing in the changelog >From Mailman/Handlers/MimeDel.py: # If we're left with only two parts, an empty body and one attachment, # recast the message to one of just that part > > X-Topics Nothing in the changelog >From Mailman/Handlers/Tagger.py: # For each regular expression in the topics list, see if any of the lines # of interest from the message match the regexp. If so, the message gets # added to the specific topics bucket. > > X-Mailer > > I think we should use User-Agent here. Thunderbird does, as do some other mail clients. Or, we should push for introduction of a List-Agent header. Nothing in the changelog Some references to code in Mailman/Bouncers/* Dunno what it does. > > X-List-Received-Date > > Don't the Received headers carry this information? >From the changelog: The archived copy of messages grows an X-List-Received-Date: header indicating the time the message was received by Mailman. # Always put an indication of when we received the message. Seems to decide where messages should be archived > > > X-Approve Nothing in the changelog >From Mailman/Handlers/Approve.py: # See if the message has an Approved or Approve header with a valid # list-moderator, list-admin. Also look at the first non-whitespace line # in the file to see if it looks like an Approved header. We are # specifically /not/ allowing the site admins password to work here # because we want to discourage the practice of sending the site admin # password through email in the clear. > > X-Approved Nothing in the changelog X-Approve dupe? > Generally, I think we should avoid the use of headers that duplicate other > existing headers. Where we want to add more information, then extend the > List-* header set if the information might be generally useful for mailing > list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people > know where the header came from. +1 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 From iane at sussex.ac.uk Thu Oct 27 16:29:28 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 27 Oct 2011 14:29:28 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111026153344.GD18712@state-of-mind.de> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> Message-ID: On 26 Oct 2011, at 16:33, Patrick Ben Koetter wrote: > I searched mailman 2.1.14 sources and changelog to find out what they stand > for. Read below. Which could/should we replace with already existing > standardized headers? > > * Ian Eiloart : >> On 25 Oct 2011, at 02:04, Barry Warsaw wrote: >> >>> On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: >>> >>>> There's movement afoot to deprecate use of "X-" in header field names. Just >>>> call it "Mailman-Topic". And if it's worthwhile, consider registering it >>>> with IANA. >>> >>> I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of >>> ones we still add or recognize (some might be used only in the test suite): >>> >>> X-Message-ID-Hash >> >> This could be replaced with DKIM sigs, I guess. >> >>> X-Mailman-Rule-Hits >>> X-Mailman-Rule-Misses >> >> This might be useful for diagnostics, but probably wants to be off in >> general. My view is that Mailman should not be doing message filtering. > > Are they related to SpamAssassin filtering that can take place in MM? > > >>> X-BeenThere >> >> I guess that's useful for avoiding list loops, perhaps? > > From Mailman/Handlers/CookHeaders.py: > > # Mark message so we know we've been here, but leave any existing > # X-BeenThere's intact. The message that I'm replying to carried this header: X-Beenthere: mailman-developers at python.org I guess that should stay, then. Unless we find a different place to put it. Moving it to a different place probably would not cause problems, depending on how it's used. If the header means "don't relay the message to this address", then there would be problems. If it means "drop this message, if you are mailman-developers at python.org" then it can be moved. > >>> X-Mailman-Version >> >> I think this should be replaced with X-Mailer, or even User-Agent. That's >> not currently an SMTP header, but I think it should be. And it is in quite >> widespread use. > > From Mailman/Handlers/CookHeaders.py: > > msg['X-Mailman-Version'] = mm_cfg.VERSION > > Seems to add the product version and not the User-Agent. Yes, but a User-Agent, header would have the product and the product version. A List-Agent header should do the same. >>> X-Mailman-Approved-At > > From Mailman/ListAdmin.py: > > # Queue the file for delivery by qrunner. Trying to deliver the > # message directly here can lead to a huge delay in web > # turnaround. Log the moderation and add a header. > msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 So, I guess that the web moderation works by adding this header, so that the message can be delivered when the queue runner sees it. It looks like useful trace information, so it should stay. This also looks like a candidate for, say, a List-Approved-Date header. > >>> X-Archive >> >> Does this do the same as List-Archive? > > Looks like a control feature for senders: > > From doc/mailman-admin.txt: > > Note that senders can control whether their own posts are > archived, on an individual per-message basis. If the posted > message has a X-No-Archive: header (regardless of value), or a > X-Archive: header with a value of No (case insensitive), then > the message will not be archived, although it will be treated > as normal in all other ways. > > > From the changelog: > > o When a moderated message is approved for the list, add an > X-Mailman-Approved-At: header which contains the timestamp > of the approval action (changed from X-Moderated: with a > different format). > > - Honor "X-Archive: No" header by not putting this message in the > archive. Ah, well that's also a feature that various lists might want to implement. However, List-Archive says where archives are kept. Also, I guess an MUA is never going to have a guarantee that an MLM will honour a request. To use a List-* header might confuse, since all other List-* headers are added by the MLM. Actually, I think that perhaps it and X-No-Archive could be deprecated. Does anyone actually use them? >>> X-No-Archive >> >> What does this mean? > > Seems like a dupe from X-Archive: > From the changelog: > > o Just the mere presence of an X-No-Archive: is enough to > inhibit archiving for this message; the value of the header > is now ignored. > See above. > >>> X-Ack > > From the changelog: > - Autoresponses, -request command responses, and posting hold > notifications are inhibited for any message that has a > Precedence: {bulk|list|junk} header. This is to avoid mail > loops between email 'bots. If the original message has an > X-Ack: yes header, the response is sent. >>> X-No-Ack > > Is this still being used? > > Nothing in the changelog > Nothing in the mailman-2.1.14 sources. I think X-Ack and X-No-Ack could be deprecated. Just advise people to use the correct precedence. >>> X-Peer > > Is this still being used? > > Nothing in the changelog > Nothing in the mailman-2.1.14 sources. I guess that should be deprecated, then! >>> X-MailFrom > > Is this still being used? > > Nothing in the changelog > Nothing in the mailman-2.1.14 sources. I guess that should be deprecated, then! > >>> X-RcptTo > > Is this still being used? > > Nothing in the changelog > Nothing in the mailman-2.1.14 sources. I guess that should be deprecated, then! >> Isn't that usually in the Received header? >> >>> X-Originally-To >> >> Doesn't that do the same thing as List-post? > > Seems like a copy of Postfix' X-Original-To-header. Is it? > > From cron/gate_news: > > del msg['X-Originally-To'] > msg['X-Originally-To'] = msg['To'] Does Mailman 3 gate news? > >>> X-Original-CC >> What's the purpose of including this? > > From Mailman/Defaults.py.in: > > # Next, these headers are left alone, unless there are duplicates in the > # original message. Any second and subsequent headers are rewritten to the > # second named header (case preserved). > NNTP_REWRITE_DUPLICATE_HEADERS = [ > ('to', 'X-Original-To'), > ('cc', 'X-Original-Cc'), > ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), > ('mime-version', 'X-MIME-Version'), > ] So, this is about tracking original message headers. Why do we want to do that? Why not leave them intact? >>> X-Original-Content-Transfer-Encoding > > From Mailman/Defaults.py.in: > > # Next, these headers are left alone, unless there are duplicates in the > # original message. Any second and subsequent headers are rewritten to the > # second named header (case preserved). > NNTP_REWRITE_DUPLICATE_HEADERS = [ > ('to', 'X-Original-To'), > ('cc', 'X-Original-Cc'), > ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), > ('mime-version', 'X-MIME-Version'), > ] > > >>> X-MIME-Version > > From Mailman/Defaults.py.in: > > # Next, these headers are left alone, unless there are duplicates in the > # original message. Any second and subsequent headers are rewritten to the > # second named header (case preserved). > NNTP_REWRITE_DUPLICATE_HEADERS = [ > ('to', 'X-Original-To'), > ('cc', 'X-Original-Cc'), > ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), > ('mime-version', 'X-MIME-Version'), > ] > > >>> X-Mailman-Copy > > Nothing in the changelog > > From templates/en/options.html: > > Avoid duplicate copies of messages? > > When you are listed explicitly in the To: or Cc: headers of a list > message, you can opt to not receive another copy from the mailing > list. Select Yes to avoid receiving copies from the mailing list; > select No to receive copies. > > If the list has member personalized messages enabled, and you elect to > receive copies, every copy will have a X-Mailman-Copy: yes header > added to it. > > From Mailman/Handlers/SMTPDirect.py: > > # We can flag the mail as a duplicate for each member, if they've > # already received this message, as calculated by Message-ID. See > # AvoidDuplicates.py for details. > del msgcopy['x-mailman-copy'] > if msgdata.get('add-dup-header', {}).has_key(recip): > msgcopy['X-Mailman-Copy'] = 'yes' This seems to be redundant. The Received headers will tell me which copy was processed by Mailman. > >>> X-List-Administrivia > > From the changelog: > o X-List-Administrivia: is only added to messages Mailman > creates and sends out of its own accord. > > From Mailman/Handlers/CookHeaders.py: > > # For internally crafted messages, we also add a (nonstandard), > # "X-List-Administrivia: yes" header. For all others (i.e. those coming > # from list posts), we add a bunch of other RFC 2369 headers. This seems like a candidate for a (collection?) of new List-* headers. It could assist MUAs, for example, in identifying the nature of messages generated by lists. >> List-help? >> >>> X-Content-Filtered-By > > Nothing in the changelog > > From Mailman/Handlers/MimeDel.py: > > # If we're left with only two parts, an empty body and one attachment, > # recast the message to one of just that part > >>> X-Topics > > Nothing in the changelog > > From Mailman/Handlers/Tagger.py: > > # For each regular expression in the topics list, see if any of the lines > # of interest from the message match the regexp. If so, the message gets > # added to the specific topics bucket. So, is this used by Mailman to decide who to send the message to? Or is it supposed to help recipients to build filters. Either way, it might be useful for the latter purpose. Perhaps it's a candidate for List-Topics? > >>> X-Mailer >> >> I think we should use User-Agent here. Thunderbird does, as do some other mail clients. Or, we should push for introduction of a List-Agent header. > > Nothing in the changelog > > Some references to code in Mailman/Bouncers/* > Dunno what it does. The message that I'm replying to doesn't seem to contain an X-mailer header. >>> X-List-Received-Date >> >> Don't the Received headers carry this information? > > From the changelog: > The archived copy of messages grows an X-List-Received-Date: > header indicating the time the message was received by > Mailman. > > > # Always put an indication of when we received the message. > > Seems to decide where messages should be archived I think that's a candidate for a List-Archived-Date header. Because that's potentially helpful for people looking to find the message in an archive. >>> X-Approve > > Nothing in the changelog > > From Mailman/Handlers/Approve.py: > > # See if the message has an Approved or Approve header with a valid > # list-moderator, list-admin. Also look at the first non-whitespace line > # in the file to see if it looks like an Approved header. We are > # specifically /not/ allowing the site admins password to work here > # because we want to discourage the practice of sending the site admin > # password through email in the clear. > > >>> X-Approved > > Nothing in the changelog > > X-Approve dupe? > >> Generally, I think we should avoid the use of headers that duplicate other >> existing headers. Where we want to add more information, then extend the >> List-* header set if the information might be generally useful for mailing >> list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people >> know where the header came from. > > +1 > > 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 > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/iane%40sussex.ac.uk > > Security Policy: http://wiki.list.org/x/QIA9 -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From mark at msapiro.net Fri Oct 28 00:55:31 2011 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 27 Oct 2011 15:55:31 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> Message-ID: <4EA9E163.2030808@msapiro.net> On 10/27/2011 7:29 AM, Ian Eiloart wrote: > > On 26 Oct 2011, at 16:33, Patrick Ben Koetter wrote: >> [...] > The message that I'm replying to carried this header: > X-Beenthere: mailman-developers at python.org > > I guess that should stay, then. Unless we find a different place to put it. Moving it to a different place probably would not cause problems, depending on how it's used. If the header means "don't relay the message to this address", then there would be problems. If it means "drop this message, if you are mailman-developers at python.org" then it can be moved. It means the latter - "drop this message, if you are mailman-developers at python.org". [...] >>>> X-Mailman-Approved-At >> >> From Mailman/ListAdmin.py: >> >> # Queue the file for delivery by qrunner. Trying to deliver the >> # message directly here can lead to a huge delay in web >> # turnaround. Log the moderation and add a header. >> msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 > > So, I guess that the web moderation works by adding this header, so that the message can be delivered when the queue runner sees it. It looks like useful trace information, so it should stay. It has nothing to do with delivery. Approval for delivery is noted by flags in the message's metadata. The X-Mailman-Approved-At: header is added solely for documentation to explain delays to message recipients. > This also looks like a candidate for, say, a List-Approved-Date header. Yes. [...] >>>> X-Peer >> >> Is this still being used? >> >> Nothing in the changelog >> Nothing in the mailman-2.1.14 sources. > > I guess that should be deprecated, then! This header is used in MM 3. >>>> X-MailFrom >> >> Is this still being used? >> >> Nothing in the changelog >> Nothing in the mailman-2.1.14 sources. > > I guess that should be deprecated, then! This header is used in MM 3. >>>> X-RcptTo >> >> Is this still being used? >> >> Nothing in the changelog >> Nothing in the mailman-2.1.14 sources. > > I guess that should be deprecated, then! It is only in the headers of of some test bounce messages. It is not in the code. It is a header added to the headers of a bounce notification (DSN) from (I'll refrain from giving my opinion) the Windows MTA SMTPD32. You'd have to ask ipswitch if you want to know what it means, but it appears to duplicate the To: header. [...] >>>> X-Topics >> >> Nothing in the changelog >> >> From Mailman/Handlers/Tagger.py: >> >> # For each regular expression in the topics list, see if any of the lines >> # of interest from the message match the regexp. If so, the message gets >> # added to the specific topics bucket. > > So, is this used by Mailman to decide who to send the message to? Or is it supposed to help recipients to build filters. Either way, it might be useful for the latter purpose. Perhaps it's a candidate for List-Topics? If Topics are enabled for a list, Mailman decides the topics of a post by matching the defining topic regexps against the Subject: and any Keywords: header or pseudo-header. The X-Topics: header is added to the message and contains the names of all matching topics, but this is informational only. Delivery to those users subscribed to matching topics is controlled by an equivalent list of matching topics in the message's metadata. >>>> X-Mailer >>> >>> I think we should use User-Agent here. Thunderbird does, as do some other mail clients. Or, we should push for introduction of a List-Agent header. >> >> Nothing in the changelog >> >> Some references to code in Mailman/Bouncers/* >> Dunno what it does. > > The message that I'm replying to doesn't seem to contain an X-mailer header. The header is added by some mailers to identify themselves. It is used by some of Mailman's heuristic bounce recognizers as part of their recognition of non-standard DSNs. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Fri Oct 28 11:39:45 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 28 Oct 2011 18:39:45 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <4EA9E163.2030808@msapiro.net> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <4EA9E163.2030808@msapiro.net> Message-ID: <87wrbp315q.fsf@uwakimon.sk.tsukuba.ac.jp> Mark Sapiro writes: > SMTPD32. You'd have to ask ipswitch if you want to know what it means, > but it appears to duplicate the To: header. I would guess that it actually copies the envelope recipient. From iane at sussex.ac.uk Wed Oct 26 14:29:45 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 26 Oct 2011 12:29:45 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <878vo959so.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <6A6B786A-327D-4FAB-A0DD-BF6D7A4E88FF@sussex.ac.uk> <87sjmi5lzi.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwih5rj1.fsf@uwakimon.sk.tsukuba.ac.jp> <4EA6C71D.20309@Damon-Family.org> <878vo959so.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On 25 Oct 2011, at 17:13, Stephen J. Turnbull wrote: > Murray S. Kucherawy writes: > >> What it says is the list should re-sign if it modifies the message >> (or, in general, re-sign anyway). So append whatever you want, >> just re-sign the message. Are you insisting that advice is >> defective? > > Defective, maybe not. > > But I don't think I would follow it for my own lists. I'd rather > remove the signature I think the advice is to NOT remove the signature. The DKIM spec says that a broken signature is equivalent to the absence of a signature. However, leaving the signature in place can help administrators to diagnose problems with the transmission chain. > and tell people who are using anal-retentive ISPs > that refuse to pass unsigned messages to switch, because there are too > many people out there who will report you as a spammer rather than > unsubscribe. I don't want my signature associated with any such > thing. I've not come across any such ISPs. I suppose they may exist. In my view, all message senders (including list owners) should publish SPF records and DKIM sign messages. Recipients should be satisfied with either an SPF PASS or a good DKIM sig, to give them a reliable domain name to apply reputation tests to. Most legitimate messages would be identifiable by one of those mechanisms. MLMs would be OK by virtue of the fact that they use their own sender domains. Traditional forwarders usually would not be breaking DKIM signatures, and would not have to worry about SPF breakage. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From barry at list.org Fri Oct 28 19:17:30 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 28 Oct 2011 13:17:30 -0400 Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs) In-Reply-To: <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> Message-ID: <20111028131730.7cb9c5f5@limelight.wooz.org> Right, sorry. I was in a hurry when I wrote my follow up, so let me provide more detail about the headers, and my thoughts about the X-iness. In general, Mailman should "play nice" but I also think it's not unreasonable to claim the Mailman-* prefix and just start using it for Mailman-specific headers. If the header has some more general utility, then keeping the X- for now and registering them may make more sense. On Oct 26, 2011, at 12:43 PM, Ian Eiloart wrote: >> X-Message-ID-Hash > >This could be replaced with DKIM sigs, I guess. Actually, no, this one comes from here: http://wiki.list.org/display/DEV/Stable+URLs I think there was a discussion about this ages ago, although it might have been (partly) a private discussion with the Mail Archive folks. The idea is that given only the List-Archive or RFC 5064 Archived-At header and Message-ID header, you should be able to calculate a stable url for an archived message. If you only know the Message-ID then using the hash should allow you to search an archive for the message. X-Message-ID-Hash is essentially just a convenience, since it can be calculated from the Message-ID. I think it's still appropriate to leave this one an X- header, although it might be interesting to register it, and even more interesting to propose an RFC as an extension of RFC 5064. >> X-Mailman-Rule-Hits >> X-Mailman-Rule-Misses > >This might be useful for diagnostics, but probably wants to be off in >general. My view is that Mailman should not be doing message filtering. Mailman's always done some form of message filtering, so this is just MM3's way of recording the results of the various tests for acceptance. In MM2, the processing pipeline contained both moderation handlers (e.g. "is this administrivia") and modification handlers (e.g. "futz with the headers"), but this has been refactored in MM3 so that there are different processing subsystems for moderation and modification. The headers above will contain a list of the moderations rules that matched or missed, so their inclusion in the outgoing message is *mostly* diagnostics. Since they'll probably be hidden anyway, I think it's useful to keep these on by default. They could certainly lose the X- prefix. >> X-BeenThere > >I guess that's useful for avoiding list loops, perhaps? Right, but MM3 uses List-Post for that now, so this is legacy. I think this can be eradicated from the MM3 source, since I think it makes no sense to recognize the MM2 loop-detection header in MM3. https://bugs.launchpad.net/mailman/+bug/883158 >> X-Mailman-Version > >I think this should be replaced with X-Mailer, or even User-Agent. That's not >currently an SMTP header, but I think it should be. And it is in quite >widespread use. This is just the version of Mailman that sent the message. It can lose the X- prefix. >> X-Mailman-Approved-At This is a time stamp, so it'll help you understand why a message you sent to a list a year ago is only showing up now . It can lose the X- prefix. >> X-Archive >> X-No-Archive These are Postel's law headers which control whether a message is archived or not. Yeah, we've seen them both. MM3 doesn't set them, so ignore these for the purposes of this discussion. >What does this mean? > >> X-Ack >> X-No-Ack Similarly, these control whether an acknowledgment of a post is sent to the original author. MM3 does set this to "no" when a user's noack flag is set. These should keep the X- prefix. >> X-Peer Ignore this, it's used in the test suite only. lazr.smtptest sets it based on the host:port of the connecting socket. >> X-MailFrom >> X-RcptTo These are also primarily used in the test suite. Again, lazr.smtptest sets them, however MM3's LMTP server does add this header based on the RFC 5321 MAIL FROM value. It's mostly used as a diagnostic though. I think we could probably rename this to Mailman-LMTP-MailFrom if we still wanted to keep it. >> X-Originally-To Mailman only sets this in gate_news.py when it needs to rewrite the To: header. Probably not worth changing. >> X-Original-CC >> X-Original-Content-Transfer-Encoding >> X-MIME-Version Ignore these. They are used in the news gating code when it has to rewrite duplicate headers. E.g. if a message destined for NNTP has more than one CC header, MM3 collapses this into a single X-Original-CC and deletes all of the original CC headers. At least at one point, NNTP software did not accept messages with multiple CC headers. >> X-Mailman-Copy This one is used when VERP is enabled. When a message is posted to the list, personalization is enabled, and a user wants to receive duplicates (i.e. they have not enabled list-copy suppression), the copy of the message coming from Mailman will have X-Mailman-Copy: yes set. This is probably a fairly useless redundancy, since I always tend to use one of the List-* headers to determine whether a copy comes from the list or not. It also probably does no harm. It can either be removed or lose the X- prefix. >> X-List-Administrivia Honestly, I don't remember what the purpose of this header is. It used to be used when reduced RFC 2369 header were requested by the list administrator, e.g. because they had users with, um, unhelpful mail clients and got complaints about all the List-* headers. Now we don't support reduced headers so X-List-Administrivia is just useless and should be removed. >> X-Content-Filtered-By This is an identification header added when MIME contents of the original message are filtered. I'm not sure how useful it is, except that it does signal to the recipient that the message they received via the list has been modified. I think this should be renamed to (X-)Mailman-Content-Filter. >> X-Topics This contains a list of all the topic names that matched the message. >> X-Mailer > >I think we should use User-Agent here. Thunderbird does, as do some other >mail clients. Or, we should push for introduction of a List-Agent header. Mailman's autoresponder is the only thing that adds this, and it only contains an identity string. It may or may not be useful to keep this or change it. I'm not sure User-Agent would be right though. >> X-List-Received-Date This only gets added when the message is sent to the archive. It's consumed by the scrubber to help calculate the directory that attachments are saved in. >> X-Approve >> X-Approved These are used for admin bypass of the posting rules. We could change these to Mailman-* headers, but we'd still need to keep the above two for backward compatibility, so I'm not sure it's worth it. >Generally, I think we should avoid the use of headers that duplicate other >existing headers. Where we want to add more information, then extend the >List-* header set if the information might be generally useful for mailing >list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people >know where the header came from. I generally agree. https://bugs.launchpad.net/mailman/+bug/883193 -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Oct 28 19:27:13 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 28 Oct 2011 13:27:13 -0400 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> Message-ID: <20111028132713.23d2a395@limelight.wooz.org> On Oct 27, 2011, at 02:29 PM, Ian Eiloart wrote: >The message that I'm replying to carried this header: >X-Beenthere: mailman-developers at python.org Note that I responded in the context of Mailman 3. We have an opportunity there to clean that all up, but it probably isn't a good idea to radically change these for MM2. >> From Mailman/Handlers/CookHeaders.py: >> >> msg['X-Mailman-Version'] = mm_cfg.VERSION >> >> Seems to add the product version and not the User-Agent. > >Yes, but a User-Agent, header would have the product and the product version. >A List-Agent header should do the same. List-Agent is not a bad idea. >>>> X-Mailman-Approved-At >> >> From Mailman/ListAdmin.py: >> >> # Queue the file for delivery by qrunner. Trying to deliver the >> # message directly here can lead to a huge delay in web >> # turnaround. Log the moderation and add a header. >> msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 > >So, I guess that the web moderation works by adding this header, so that the >message can be delivered when the queue runner sees it. It looks like useful >trace information, so it should stay. > >This also looks like a candidate for, say, a List-Approved-Date header. That would make sense too. >> From cron/gate_news: >> >> del msg['X-Originally-To'] >> msg['X-Originally-To'] = msg['To'] > >Does Mailman 3 gate news? It's supposed to. :) >> From Mailman/Defaults.py.in: >> >> # Next, these headers are left alone, unless there are duplicates in the >> # original message. Any second and subsequent headers are rewritten to the >> # second named header (case preserved). >> NNTP_REWRITE_DUPLICATE_HEADERS = [ >> ('to', 'X-Original-To'), >> ('cc', 'X-Original-Cc'), >> ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), >> ('mime-version', 'X-MIME-Version'), >> ] > >So, this is about tracking original message headers. Why do we want to do >that? Why not leave them intact? Since this is a configuration option, they're under the control of the site administrator. We can certainly discuss whether it makes sense to change or extend the defaults. The values are the same in MM3, even if they're expressed differently in the configuration file. >> From Mailman/Handlers/Tagger.py: >> >> # For each regular expression in the topics list, see if any of the lines >> # of interest from the message match the regexp. If so, the message gets >> # added to the specific topics bucket. > >So, is this used by Mailman to decide who to send the message to? Or is it >supposed to help recipients to build filters. Either way, it might be useful >for the latter purpose. Perhaps it's a candidate for List-Topics? Are there any other MLMs that support topics in a way that would make that header generally useful? >> From the changelog: >> The archived copy of messages grows an X-List-Received-Date: >> header indicating the time the message was received by >> Mailman. >> >> >> # Always put an indication of when we received the message. >> >> Seems to decide where messages should be archived > >I think that's a candidate for a List-Archived-Date header. Because that's >potentially helpful for people looking to find the message in an archive. Possibly so, if it's a header added by the MLM. E.g. an archiver might have its own "archive date" value so it would either have to chose a different header, or use multiple instances (with the loss of fidelity). -Barry From iane at sussex.ac.uk Mon Oct 24 15:58:56 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 24 Oct 2011 13:58:56 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111013113012.35438eee@limelight.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> Message-ID: <038A197F-29DD-4DDA-B6EF-2BF00BA302A8@sussex.ac.uk> On 13 Oct 2011, at 16:30, Barry Warsaw wrote: > > For Mailman, I think we'd like to, and would generally be able to be more > DKIM-friendly, if we actually knew what to do. Short of not modifying the > incoming message at all, and absent clear guidelines in this or any other RFC, > we're just flailing in the dark. I think the RFC makes it clear though that > there really are no good answers. It's a minor point that has no practical > effect, but I think it states our project's general policy of wanting to be as > RFC-compliant as possible. Not modifying the message would work just fine. Other than that: Don't modify the body, unless the DKIM signature specifies that it's signed only part of the body. In this case, it's OK to append to the body. Don't modify any headers that are signed. Adding headers is usually OK, but one should be careful not to add headers that already exist. For example, don't add a second "Subject" line. Generally, there are three things that a list might do to break a signature: a. Append text to the message. In the UK, though, this is essential for most mailing lists, since they're usually promoting something (Eg, this list is promoting Mailman), and therefore required to include an easy to use opt-out address. If only more mail clients would present List-Unsubscribe headers usefully, this might be avoided. b. Prepend text to the subject line. This isn't really necessary at all, but would be easier to avoid if mail filtering systems offered better access to the List-ID headers. c. Alter the "From:" header. Again, lists don't have to do this. However, this can get tricky with ADSP. If a domain publishes ADSP "discardable", then the list should probably reject messages with From: header addresses in that domain, if it's about to break the DKIM signature. Of course, if there's no good DKIM signature on the message, then the list should discard the message. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From p at state-of-mind.de Fri Oct 28 22:36:02 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Fri, 28 Oct 2011 22:36:02 +0200 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111028132713.23d2a395@limelight.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> Message-ID: <20111028203601.GA2311@state-of-mind.de> I've begun to sort the various comments into a list that sorts all changes in categories like 'decide', 'delete', 'modify', 'keep'. I will send it to mailman-developers at python.org once I've clarified a few header fields. As a reference I looked for existing list-relevant header fields in RFC 2369 , which doesn't seem to have seen an update in a while. All my comments to List-* headers refer to RFC 2369. Please find them below including some minor nitpicking at the end. * Barry Warsaw : > On Oct 27, 2011, at 02:29 PM, Ian Eiloart wrote: > Note that I responded in the context of Mailman 3. We have an opportunity > there to clean that all up, but it probably isn't a good idea to radically > change these for MM2. ACK. I'd keep MM2 as it is and introduce changes for MM3 only. > >> From Mailman/Handlers/CookHeaders.py: > >> > >> msg['X-Mailman-Version'] = mm_cfg.VERSION > >> > >> Seems to add the product version and not the User-Agent. > > > >Yes, but a User-Agent, header would have the product and the product version. > >A List-Agent header should do the same. > > List-Agent is not a bad idea. It's not available in RFC 2369. We will have to propose 'List-Agent' as a new standard. Should we? > >>>> X-Mailman-Approved-At > >> > >> From Mailman/ListAdmin.py: > >> > >> # Queue the file for delivery by qrunner. Trying to deliver the > >> # message directly here can lead to a huge delay in web > >> # turnaround. Log the moderation and add a header. > >> msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 > > > >So, I guess that the web moderation works by adding this header, so that the > >message can be delivered when the queue runner sees it. It looks like useful > >trace information, so it should stay. > > > >This also looks like a candidate for, say, a List-Approved-Date header. It's not available in RFC 2369. We will have to propose 'List-Approved-Date' as a new standard. Should we? > >> From Mailman/Handlers/Tagger.py: > >> > >> # For each regular expression in the topics list, see if any of the lines > >> # of interest from the message match the regexp. If so, the message gets > >> # added to the specific topics bucket. > > > >So, is this used by Mailman to decide who to send the message to? Or is it > >supposed to help recipients to build filters. Either way, it might be useful > >for the latter purpose. Perhaps it's a candidate for List-Topics? > > Are there any other MLMs that support topics in a way that would make that > header generally useful? Not that I am aware of. But maybe we could give it a more generic view. I could imagine calling them 'Tags', which would make them usable in any protocol that sends headers. > >> From the changelog: > >> The archived copy of messages grows an X-List-Received-Date: > >> header indicating the time the message was received by > >> Mailman. > >> > >> > >> # Always put an indication of when we received the message. > >> > >> Seems to decide where messages should be archived > > > >I think that's a candidate for a List-Archived-Date header. Because that's > >potentially helpful for people looking to find the message in an archive. > > Possibly so, if it's a header added by the MLM. E.g. an archiver might have > its own "archive date" value so it would either have to chose a different > header, or use multiple instances (with the loss of fidelity). When I read 'List-Archived-Date' I understand it specifies the date the message had been archived by some archival software and not the date is was sent to the archive by an MLM. That makes a difference to me because copying the message to an archive might not be the only way to transport it there. The MLM might as well use an LMTP transport and queue it up for delivery. The queued message might get stuck in a delivery queue for hours. Being able to tell the difference between 'sent off to' and 'stored at' might be very useful to a postmaster when debugging archival problems. Choosing a more specific header field would probably also avoid getting into an archivers way when it creats an "archive date" value as Barry mentioned above. Not sure. Am I overly pedantic on this? 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 From barry at list.org Sat Oct 29 00:43:28 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 28 Oct 2011 18:43:28 -0400 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111028203601.GA2311@state-of-mind.de> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> Message-ID: <20111028184328.68379aa6@limelight.wooz.org> On Oct 28, 2011, at 10:36 PM, Patrick Ben Koetter wrote: >> >> From Mailman/Handlers/CookHeaders.py: >> >> >> >> msg['X-Mailman-Version'] = mm_cfg.VERSION >> >> >> >> Seems to add the product version and not the User-Agent. >> > >> >Yes, but a User-Agent, header would have the product and the product version. >> >A List-Agent header should do the same. >> >> List-Agent is not a bad idea. > >It's not available in RFC 2369. We will have to propose 'List-Agent' as a new >standard. Should we? I think it makes sense to have a header identifying the MLM that the message flowed through, and List-Agent seems like a good choice. >> >>>> X-Mailman-Approved-At >> >> >> >> From Mailman/ListAdmin.py: >> >> >> >> # Queue the file for delivery by qrunner. Trying to deliver the >> >> # message directly here can lead to a huge delay in web >> >> # turnaround. Log the moderation and add a header. >> >> msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 >> > >> >So, I guess that the web moderation works by adding this header, so that >> >the message can be delivered when the queue runner sees it. It looks like >> >useful trace information, so it should stay. >> > >> >This also looks like a candidate for, say, a List-Approved-Date header. > >It's not available in RFC 2369. We will have to propose 'List-Approved-Date' >as a new standard. Should we? I also think it makes sense to have a date header marking the time when the message was approved. This implies of course that the message was held for moderation. Would there be a L-A-D header if the posting was automatically accepted? Maybe the header should be List-Posted-Date, although there some subtly different semantics implied by that. E.g. if the date the message was approved isn't quite the date the message was posted (idk, some delay from moderator acceptance to actually posting through the MLM). Another header that might be useful here would be List-Approved-By which could be the name or email address of the moderator who approved it. Right now, MM3 doesn't fill that in, and it could of course be filled in by say list-owner at example.com, but in MM3 it could be potentially filled in with the preferred address for the moderator that approved it. >> >> From Mailman/Handlers/Tagger.py: >> >> >> >> # For each regular expression in the topics list, see if any of the lines >> >> # of interest from the message match the regexp. If so, the message gets >> >> # added to the specific topics bucket. >> > >> >So, is this used by Mailman to decide who to send the message to? Or is it >> >supposed to help recipients to build filters. Either way, it might be useful >> >for the latter purpose. Perhaps it's a candidate for List-Topics? >> >> Are there any other MLMs that support topics in a way that would make that >> header generally useful? > >Not that I am aware of. But maybe we could give it a more generic view. I >could imagine calling them 'Tags', which would make them usable in any >protocol that sends headers. Hmm, adopting a hash-tags format here would be kind of interesting for interop with social networking sites. It wouldn't have to be reflected in the name of the header, but it could be SHOULD in the spec. I ought to be pretty trivial for MM3 generate hash-tags here. What's interesting of course is that the Mailman module that fills this information in is the tagger handler. >> >> From the changelog: >> >> The archived copy of messages grows an X-List-Received-Date: >> >> header indicating the time the message was received by >> >> Mailman. >> >> >> >> >> >> # Always put an indication of when we received the message. >> >> >> >> Seems to decide where messages should be archived >> > >> >I think that's a candidate for a List-Archived-Date header. Because that's >> >potentially helpful for people looking to find the message in an archive. >> >> Possibly so, if it's a header added by the MLM. E.g. an archiver might have >> its own "archive date" value so it would either have to chose a different >> header, or use multiple instances (with the loss of fidelity). > >When I read 'List-Archived-Date' I understand it specifies the date the >message had been archived by some archival software and not the date is was >sent to the archive by an MLM. Yep, to me too. >That makes a difference to me because copying the message to an archive might >not be the only way to transport it there. The MLM might as well use an LMTP >transport and queue it up for delivery. The queued message might get stuck in >a delivery queue for hours. Being able to tell the difference between 'sent >off to' and 'stored at' might be very useful to a postmaster when debugging >archival problems. Agreed. >Choosing a more specific header field would probably also avoid getting into >an archivers way when it creats an "archive date" value as Barry mentioned >above. > >Not sure. Am I overly pedantic on this? No, I think it's an important distinction. Also note that in MM3 you can actually have any number of archivers, so I think you want a field that clearly describes the actions of the MLM. I'm not sure what that would be other than List-Archived-Date though. :/ Suggestions? -Barry From stephen at xemacs.org Sat Oct 29 02:42:53 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Oct 2011 09:42:53 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111028184328.68379aa6@limelight.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> Message-ID: <87pqhg4ohe.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > I think it makes sense to have a header identifying the MLM that the message > flowed through, and List-Agent seems like a good choice. Are lists the only agents that forward-with-changes? (Obviously MTAs forward, and they do in fact make changes to the headers, but those changes are restricted to those mandated by RFCs. And they don't touch bodies, ever, AFAIK, with the exception of From-stuffing.) What about the case of iterated lists (eg, internal aggregators used by an organization)? From stephen at xemacs.org Sat Oct 29 02:45:56 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Oct 2011 09:45:56 +0900 Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs) In-Reply-To: <20111028131730.7cb9c5f5@limelight.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111028131730.7cb9c5f5@limelight.wooz.org> Message-ID: <87obx04ocb.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > >> X-Mailman-Version > > > >I think this should be replaced with X-Mailer, or even User-Agent. That's not > >currently an SMTP header, but I think it should be. And it is in quite > >widespread use. > > This is just the version of Mailman that sent the message. It can lose the X- > prefix. I think that's a bad idea. The version string should go in a *-Agent header, along with the agent's identity. While I disagree with having Mailman be a User-Agent, I can't actually say there are useful semantics to having a separate List-Agent. Nor do I see a real problem with having multiple User-Agent headers, if multiple agents have handled the message. From Richard at Damon-Family.org Sat Oct 29 03:06:09 2011 From: Richard at Damon-Family.org (Richard Damon) Date: Fri, 28 Oct 2011 21:06:09 -0400 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <87pqhg4ohe.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <87pqhg4ohe.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4EAB5181.2050301@Damon-Family.org> On 10/28/11 8:42 PM, Stephen J. Turnbull wrote: > Barry Warsaw writes: > > > I think it makes sense to have a header identifying the MLM that the message > > flowed through, and List-Agent seems like a good choice. > > Are lists the only agents that forward-with-changes? (Obviously MTAs > forward, and they do in fact make changes to the headers, but those > changes are restricted to those mandated by RFCs. And they don't > touch bodies, ever, AFAIK, with the exception of From-stuffing.) > Actually, MTAs might adjust the body, in specific ways if needed to change 8 bit encoded messages into a 7 bit safe encoding if needed for transport. -- Richard Damon From p at state-of-mind.de Sat Oct 29 06:39:22 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sat, 29 Oct 2011 06:39:22 +0200 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111028184328.68379aa6@limelight.wooz.org> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> Message-ID: <20111029043922.GC2272@state-of-mind.de> * Barry Warsaw : > On Oct 28, 2011, at 10:36 PM, Patrick Ben Koetter wrote: > > >> >> From Mailman/Handlers/CookHeaders.py: > >> >> > >> >> msg['X-Mailman-Version'] = mm_cfg.VERSION > >> >> > >> >> Seems to add the product version and not the User-Agent. > >> > > >> >Yes, but a User-Agent, header would have the product and the product version. > >> >A List-Agent header should do the same. > >> > >> List-Agent is not a bad idea. > > > >It's not available in RFC 2369. We will have to propose 'List-Agent' as a new > >standard. Should we? > > I think it makes sense to have a header identifying the MLM that the message > flowed through, and List-Agent seems like a good choice. Let me merge Stephen's comment from <87obx04ocb.fsf at uwakimon.sk.tsukuba.ac.jp> to stick with a more generic term such as 'User-Agent'. While I disagree with having Mailman be a User-Agent, I can't actually say there are useful semantics to having a separate List-Agent. Nor do I see a real problem with having multiple User-Agent headers, if multiple agents have handled the message. I agree with Stephen that List-Agent is too specific leaving no semantic room for other types of message processing software. At the same time I think User-Agent is not apt, because RFC 1945 defines a User-Agent as originator, which is not the case with any MLM - it distributes a message which originated somewhere else: The User-Agent request-header field contains information about the user agent originating the request. -- http://www.ietf.org/rfc/rfc1945.txt I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 instead: A Mediator attempts to preserve the original Author's information in the message it reformulates but is permitted to make meaningful changes to the message content or envelope. A Mediator's role is complex and contingent, for example, modifying and adding content or regulating which Users are allowed to participate and when. The common example of this role is a group Mailing List. (see section "2.1.4. Mediator" and also section "5. Mediators") A 'Mediator' would leave the original User-Agent intact AND tell the message had been processed by another mail handling service AND it would allow for other Mediators to be added in case more mail processing was done after an MLM's (here: Mailman) job. > >> >>>> X-Mailman-Approved-At > >> >> > >> >> From Mailman/ListAdmin.py: > >> >> > >> >> # Queue the file for delivery by qrunner. Trying to deliver the > >> >> # message directly here can lead to a huge delay in web > >> >> # turnaround. Log the moderation and add a header. > >> >> msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 > >> > > >> >So, I guess that the web moderation works by adding this header, so that > >> >the message can be delivered when the queue runner sees it. It looks like > >> >useful trace information, so it should stay. > >> > > >> >This also looks like a candidate for, say, a List-Approved-Date header. > > > >It's not available in RFC 2369. We will have to propose 'List-Approved-Date' > >as a new standard. Should we? > > I also think it makes sense to have a date header marking the time when the > message was approved. This implies of course that the message was held for > moderation. Would there be a L-A-D header if the posting was automatically > accepted? Maybe the header should be List-Posted-Date, although there some > subtly different semantics implied by that. E.g. if the date the message was > approved isn't quite the date the message was posted (idk, some delay from > moderator acceptance to actually posting through the MLM). Hmm, if there are no intermediate processes between receiving a message and approving it a List-Approved-Date seems fine. But if there are we run into the same problem as described below with List-Archived-Date - you can't tell when it was queued and when processing took place. Adding a second header might make the useful distinction: List-Received-Date RFC 2822 date timestamp when message was received by MLM List-Approved-Date RFC 2822 date timestamp when message was approved by moderator > Another header that might be useful here would be List-Approved-By which could > be the name or email address of the moderator who approved it. Right now, MM3 > doesn't fill that in, and it could of course be filled in by say > list-owner at example.com, but in MM3 it could be potentially filled in with the > preferred address for the moderator that approved it. I see the benefit because it helps if you moderate in a team. But I fear the anger of people whose postings we decline. They search for moderator identities and then start molesting them e.g. by subscribing them to mailing lists that don't require opt-in. (Happend to me python.org postmaster. The angry person subscribed my address to various pr0n mailing lists and it took me weeks to get unsubscribed.) All this said, I'd say the policy should be to add it as an optional header field. > >> >> From Mailman/Handlers/Tagger.py: > >> >> > >> >> # For each regular expression in the topics list, see if any of the lines > >> >> # of interest from the message match the regexp. If so, the message gets > >> >> # added to the specific topics bucket. > >> > > >> >So, is this used by Mailman to decide who to send the message to? Or is it > >> >supposed to help recipients to build filters. Either way, it might be useful > >> >for the latter purpose. Perhaps it's a candidate for List-Topics? > >> > >> Are there any other MLMs that support topics in a way that would make that > >> header generally useful? > > > >Not that I am aware of. But maybe we could give it a more generic view. I > >could imagine calling them 'Tags', which would make them usable in any > >protocol that sends headers. > > Hmm, adopting a hash-tags format here would be kind of interesting for interop > with social networking sites. It wouldn't have to be reflected in the name of ACK with the notion that hashtag seems to closely realted with twitter and a more general 'tag' would stay away from that. Is there or should there be a distinction between 'tag' and http 'keywords' ? Should we use 'keywords' instead? > the header, but it could be SHOULD in the spec. I ought to be pretty trivial > for MM3 generate hash-tags here. > > What's interesting of course is that the Mailman module that fills this > information in is the tagger handler. There you go ... ;) > >> >> From the changelog: > >> >> The archived copy of messages grows an X-List-Received-Date: > >> >> header indicating the time the message was received by > >> >> Mailman. > >> >> > >> >> > >> >> # Always put an indication of when we received the message. > >> >> > >> >> Seems to decide where messages should be archived > >> > > >> >I think that's a candidate for a List-Archived-Date header. Because that's > >> >potentially helpful for people looking to find the message in an archive. > >> > >> Possibly so, if it's a header added by the MLM. E.g. an archiver might have > >> its own "archive date" value so it would either have to chose a different > >> header, or use multiple instances (with the loss of fidelity). > > > >When I read 'List-Archived-Date' I understand it specifies the date the > >message had been archived by some archival software and not the date is was > >sent to the archive by an MLM. > > Yep, to me too. > > >That makes a difference to me because copying the message to an archive might > >not be the only way to transport it there. The MLM might as well use an LMTP > >transport and queue it up for delivery. The queued message might get stuck in > >a delivery queue for hours. Being able to tell the difference between 'sent > >off to' and 'stored at' might be very useful to a postmaster when debugging > >archival problems. > > Agreed. > > >Choosing a more specific header field would probably also avoid getting into > >an archivers way when it creats an "archive date" value as Barry mentioned > >above. > > > >Not sure. Am I overly pedantic on this? > > No, I think it's an important distinction. Also note that in MM3 you can > actually have any number of archivers, so I think you want a field that > clearly describes the actions of the MLM. I'm not sure what that would be > other than List-Archived-Date though. :/ > > Suggestions? List-Archive-Send-Date 'List-Archive-Send-Date' sounds pretty clumsy and overly long. OTOH we needn't care, as it will only be added to messages that go to the archive, right? Archive-Transmit-Date, Archive-Transfer-Date, Archiv-Transfer Marks the beginning in opposition to Archive-Received-Date or Archive-Received. But then again an archiver could simply add a Received:-header! Not an easy one. 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 From msk at cloudmark.com Sat Oct 29 08:45:12 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Fri, 28 Oct 2011 23:45:12 -0700 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111028184328.68379aa6@limelight.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Barry Warsaw > Sent: Friday, October 28, 2011 3:43 PM > To: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > >> >This also looks like a candidate for, say, a List-Approved-Date > >> >header. > > > >It's not available in RFC 2369. We will have to propose 'List-Approved-Date' > >as a new standard. Should we? I've got a separate draft that adds to Received: fields a tag that indicates transitions of messages into administrative hold states (quarantining, timed delivery and list moderation are included in the initial list of reasons) ready to go. I just missed the -00 submission deadline prior to the next IETF meeting in November, so it's not in the IETF datatracker but it is here: http://www.blackops.org/~msk/draft-kucherawy-received-state.txt. Comments welcome. The idea: When the MLM selects a message for moderation it would a Received: field with such a tag, and then on release the next MTA in the chain adds another Received: as per normal which, presumably, completes the handling chain in a way that the end user can see what happened (i.e., when it entered the hold and when it came out). This doesn't include a mechanism for tracking who did the approval, but you've got that separately on your list anyway. -MSK From msk at cloudmark.com Sat Oct 29 08:53:02 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Fri, 28 Oct 2011 23:53:02 -0700 Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs) In-Reply-To: <87obx04ocb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111028131730.7cb9c5f5@limelight.wooz.org> <87obx04ocb.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org > [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On > Behalf Of Stephen J. Turnbull > Sent: Friday, October 28, 2011 5:46 PM > To: Barry Warsaw > Cc: mailman-developers at python.org > Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using > DKIM with MLMs) > > I think that's a bad idea. The version string should go in a *-Agent > header, along with the agent's identity. Agreed. > While I disagree with having Mailman be a User-Agent, I can't actually > say there are useful semantics to having a separate List-Agent. Nor > do I see a real problem with having multiple User-Agent headers, if > multiple agents have handled the message. I think having a message with User-Agent and List-Agent is less confusing than one with two User-Agents. From stephen at xemacs.org Sat Oct 29 09:50:21 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Oct 2011 16:50:21 +0900 Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs) In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111028131730.7cb9c5f5@limelight.wooz.org> <87obx04ocb.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87mxck44oy.fsf@uwakimon.sk.tsukuba.ac.jp> Murray S. Kucherawy writes: > I think having a message with User-Agent and List-Agent is less > confusing than one with two User-Agents. Who's going to be confused? Not end users.[1] I would think the real application is for an administrator or software to look at them and go, "Uh-oh, it's another Outlook|fml|... message" and deal with that agent's peculiarities. As long as there's only one set of foibles associated with Outlook, and another with fml (perhaps not disjoint from Outlook and perhaps associated with several fml-wannabes as well, but consistent across those MLMs that emulate fml), you probably don't need to distinguish -- "MLM" vs. "end-user client" is something (ie, a foible) you can deduce from the agent's name and version string. While I'm not terribly happy with calling an MLM a *user* agent, it's not entirely farfetched, especially in the case of something like Mailman. First, the MLM functions as an agent for the list owner, filtering out evile posts and protecting archives from the eyes of the unwashed. Second, it functions as the agent of each subscriber, avoiding dupes, suspending delivery during vacations, digesting the posts, etc. Footnotes: [1] As the late great George Carlin's alter ego Al Sleet the Hippy Dippy Weatherman put it, "It's 29 degrees at the airport ... which is stupid, 'cause nobody I know lives at the airport." And nobody I know (except me) looks at User-Agent/X-Mailer headers. The-exception-that-proves-the-rule-ly y'rs, From msk at cloudmark.com Sat Oct 29 11:37:01 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Sat, 29 Oct 2011 02:37:01 -0700 Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs) In-Reply-To: <87mxck44oy.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111028131730.7cb9c5f5@limelight.wooz.org> <87obx04ocb.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxck44oy.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > -----Original Message----- > From: Stephen J. Turnbull [mailto:stephen at xemacs.org] > Sent: Saturday, October 29, 2011 12:50 AM > To: Murray S. Kucherawy > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] Mailman headers (was Re: New RFC on > using DKIM with MLMs) > > Who's going to be confused? Not end users.[1] I would think the real > application is for an administrator or software to look at them and > go, "Uh-oh, it's another Outlook|fml|... message" and deal with that > agent's peculiarities. As long as there's only one set of foibles > associated with Outlook, and another with fml (perhaps not disjoint > from Outlook and perhaps associated with several fml-wannabes as well, > but consistent across those MLMs that emulate fml), you probably don't > need to distinguish -- "MLM" vs. "end-user client" is something (ie, a > foible) you can deduce from the agent's name and version string. So your perspective is "why bother", basically? That's fair, I guess, but at the same time, what's the harm in making the distinction? If for some reason something down the road wants to indicate the two separately, this would make it easy. If your concern is the cost of the process of registering "List-Agent", I'll do it for you. From stephen at xemacs.org Sat Oct 29 12:31:01 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Oct 2011 19:31:01 +0900 Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs) In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111028131730.7cb9c5f5@limelight.wooz.org> <87obx04ocb.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxck44oy.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87d3dgozru.fsf@uwakimon.sk.tsukuba.ac.jp> Murray S. Kucherawy writes: > So your perspective is "why bother [distinguishing List-Agent from > User-Agent]", basically? If you put it that way, yes. There sure does need to be a reason to bother. > That's fair, I guess, but at the same time, what's the harm in > making the distinction? Maybe there is no distinction to be made, in which case making an artificial distinction is creating confusion where there was none before. Eg, I can just see someone arguing that when Mailman generates a message (a rejection, a password reminder, whatever) it's a User-Agent, while when it simply relays it's a List-Agent. > If for some reason something down the road wants to indicate the > two separately, this would make it easy. Let that "something" write the RFC, then, when it's got a reason for increasing congestion of the namespace. From p at state-of-mind.de Sun Oct 30 20:04:03 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sun, 30 Oct 2011 20:04:03 +0100 Subject: [Mailman-Developers] Mailman headers roundup Message-ID: <20111030190403.GG6534@state-of-mind.de> 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 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 From msk at cloudmark.com Sun Oct 30 23:08:47 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Sun, 30 Oct 2011 15:08:47 -0700 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111030190403.GG6534@state-of-mind.de> References: <20111030190403.GG6534@state-of-mind.de> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at 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. From p at state-of-mind.de Mon Oct 31 00:37:32 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 31 Oct 2011 00:37:32 +0100 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: References: <20111030190403.GG6534@state-of-mind.de> Message-ID: <20111030233732.GA20250@state-of-mind.de> * Murray S. Kucherawy : > > -----Original Message----- > > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at 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! Thanks. > 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. My impression is we need to settle User-Agent, List-Agent and/or Mediator first. Then, at least that's my plan, I would start to collect/write descriptions, syntax, ABNF etc. 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 From stephen at xemacs.org Mon Oct 31 05:32:30 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 31 Oct 2011 13:32:30 +0900 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111030190403.GG6534@state-of-mind.de> References: <20111030190403.GG6534@state-of-mind.de> Message-ID: <87zkghok69.fsf@uwakimon.sk.tsukuba.ac.jp> 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.