Mailman 3 October 2011 - Mailman-Developers

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Stephen J. Turnbull 25 Oct '11

25 Oct '11

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.

2 1

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Stephen J. Turnbull 25 Oct '11

25 Oct '11

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.

2 1

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Richard Damon 24 Oct '11

24 Oct '11

On 10/24/11 10:31 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Ian Eiloart [mailto:iane@sussex.ac.uk] >> Sent: Monday, October 24, 2011 7:24 AM >> To: Murray S. Kucherawy >> Cc: mailman-developers(a)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.

1 0

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Ian Eiloart 24 Oct '11

24 Oct '11

On 24 Oct 2011, at 15:02, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Ian Eiloart [mailto:iane@sussex.ac.uk] >> Sent: Monday, October 24, 2011 7:00 AM >> To: Murray S. Kucherawy >> Cc: mailman-developers(a)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

2 1

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Ian Eiloart 24 Oct '11

24 Oct '11

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

2 1

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Barry Warsaw 24 Oct '11

24 Oct '11

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

3 2

Re: [Mailman-Developers] [Bug 869317] Re: Mailman startup script missing --force option.
by Barry Warsaw 14 Oct '11

14 Oct '11

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.

1 0

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Stephen J. Turnbull 14 Oct '11

14 Oct '11

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.

2 1

New RFC on using DKIM with MLMs
by Murray S. Kucherawy 12 Oct '11

12 Oct '11

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

1 0