Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
On 12/06/11 11:17, Murray S. Kucherawy wrote:
It depends on your expectations. If there's an expectation that the author's signature will/should/must persist through a mailing list, then I agree that they're largely incompatible. If on the other hand you intend for lists to re-sign mail and for receivers to evaluate the message based on the list signature rather than the author signature, then it's entirely workable. Of course, sometimes the author signature will indeed survive, and then you have two domains to evaluate instead of one. Bonus!
There were a lot of "it depends" in your email, so maybe I've mis-read, but it sounds to me like the long-term path of least user/list admin hassle for Mailman probably is to just re-sign the messages. Except that there's no standard for third parties doing re-signing, and no one's sure how to interpret it if we do?
As a developer, this sounds the makings of one of those life-sucking projects you shouldn't touch with a 10-foot pole unless you're getting paid to define and defend a standard. There's no guarantee that anything we choose to do will ever be considered correct, and it could wind up being a lot of arguing and wasted effort at a time when I think we're better off just getting mailman 3 out the door.
Which is a pity, because this seems like a great opportunity for us to trailblaze and help correct a mistaken assumption in DKIM. Maybe the other developers are a lot more excited about that than I am and willing to take the risk of implementation, but maybe we should just keep an eye on the expansion of DKIM and revisit this issue after Mailman 3 is released?
It sounds like our best option for the near future is to write up a nice little document describing the issue, Monica's fix for lists where DKIM is essential, and leave it at that as far as code goes until things move a bit closer to consensus on how DKIM should handle mailing lists long-term. As a bonus, a nice little document could also be usable with 2.1! If anyone needs wiki author permissions to do this, let me know.
Terri
-----Original Message----- From: mailman-developers-bounces+msk=cloudmark.com@python.org [mailto:mailman-developers-bounces+msk=cloudmark.com@python.org] On Behalf Of Terri Oda Sent: Tuesday, December 06, 2011 11:36 AM To: mailman-developers@python.org Subject: Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
There were a lot of "it depends" in your email, so maybe I've mis-read, but it sounds to me like the long-term path of least user/list admin hassle for Mailman probably is to just re-sign the messages. Except that there's no standard for third parties doing re-signing, and no one's sure how to interpret it if we do?
Right, except for the last bit. The common practice at the moment is to evaluate (the reputation of) any DKIM domain whose signatures survive transit. They are the only bits of the message guaranteed to be "true" in some way (except maybe the details of the last Received: field, because it's yours). In the case of author-signed mail transiting a list that re-signs, it's most likely I'll get the latter, but I might also get the former. This is basically what RFC6377 says.
There is some automatic, intuitive desire to evaluate the message's author domain rather than the message's re-signer domain(s). That's why there's all this pressure to tweak MLMs and other components of the infrastructure to permit author domain signatures to survive to the ultimate recipient. DKIM doesn't require this, but intuition would really like it to be so.
It's not really true that "it depends" permeates DKIM's definition. It's pretty clear what DKIM does and doesn't do. But there's a lot of need for stuff just outside the edges of what DKIM does. That's what's creating all this activity around MLMs, reputation, and other adjacent topics.
Which is a pity, because this seems like a great opportunity for us to trailblaze and help correct a mistaken assumption in DKIM.
Which assumption is that?
-MSK
On Dec 06, 2011, at 12:36 PM, Terri Oda wrote:
As a developer, this sounds the makings of one of those life-sucking projects you shouldn't touch with a 10-foot pole unless you're getting paid to define and defend a standard. There's no guarantee that anything we choose to do will ever be considered correct, and it could wind up being a lot of arguing and wasted effort at a time when I think we're better off just getting mailman 3 out the door.
I agree completely. (he says, still struggling with REST authentication/authorization :).
Which is a pity, because this seems like a great opportunity for us to trailblaze and help correct a mistaken assumption in DKIM. Maybe the other developers are a lot more excited about that than I am and willing to take the risk of implementation, but maybe we should just keep an eye on the expansion of DKIM and revisit this issue after Mailman 3 is released?
What Mailman 3, and to some lesser extent MM2 can do today, is to provide a framework for experimentation, for those folks who are motivated to improve the current situation. Fortunately, I think MM3 has everything you'd need to do that. A team working on improving things should be able to distribute a plug-in that implemented their experiment for sites that wanted to participate.
-Barry
Hi Terri,
On Tue, Dec 6, 2011 at 11:36 AM, Terri Oda terri@zone12.com wrote:
There were a lot of "it depends" in your email, so maybe I've mis-read, but it sounds to me like the long-term path of least user/list admin hassle for Mailman probably is to just re-sign the messages. Except that there's no standard for third parties doing re-signing, and no one's sure how to interpret it if we do?
I came up with something for groups that we host and would love to see another MLM implement it. It is a header that stores a copy the original authentication results as received by the MLM (or any forwarder, really) before destroying the signature. Respecting this header requires the expanded message to be re-signed by a trusted forwarder (easy in my case, since googlegroups.com uses its own DKIM key) -- so long as this header exists and is signed by a trusted forwarder, then on inbound we trust the original authentication results and don't care if the message is signed with a DKIM key that doesn't match the From.
Maintaining the list of trusted forwarders then becomes a problem for receivers, but it's one that's a lot more manageable than today's situation because as Murray points out, many reputation systems have already been developed around DKIM.
As a developer, this sounds the makings of one of those life-sucking projects you shouldn't touch with a 10-foot pole unless you're getting paid to define and defend a standard.
That is not out of the question.
It sounds like our best option for the near future is to write up a nice little document describing the issue, Monica's fix for lists where DKIM is essential, and leave it at that as far as code goes until things move a bit closer to consensus on how DKIM should handle mailing lists long-term. As a bonus, a nice little document could also be usable with 2.1! If anyone needs wiki author permissions to do this, let me know.
Would that go here? http://wiki.list.org/display/DOC/3+List+administrator+tasks I'm highly motivated to help :)
Thanks, Monica
participants (4)
-
Barry Warsaw -
Monica Chew -
Murray S. Kucherawy -
Terri Oda