On Fri, Nov 20, 2015 at 08:05:48PM +1100, Russell Coker wrote:
On Fri, 20 Nov 2015 03:08:05 PM Joel W. Shea wrote:
On Fri, Nov 20, 2015 at 07:29:04AM +1100, Brian May wrote:
IIRC I think somebody said that Mailman breaks the DKIM on the original message.
I was referring to the mailing list making its own signatures [...]
[...] The previous version of Mailman that we used (from Debian/Wheezy) would reformat the DKIM header to use spaces instead of tabs which for some reason broke all the Linux DKIM software I tested with.
Thanks, I'd forgotten about <201510172046.45136.russell@coker.com.au> http://lists.luv.asn.au/pipermail/luv-main/2015-October/008489.html
Ideally we would have the DKIM checking handle this [...]
libmail-dkim-perl behaves correctly in that scenario, since the header specified "c=simple/simple", where any change in that header will also break the signature, IIRC. Perhaps using "c=relaxed/relaxed" (as Google does) would resolve that issue? However, that would depend on the sender's signing policy (over which not all authors will have control), so the following...
[...] It would also be possible for Mailman to have special case code for DKIM headers [...]
...seems to be the ideal solution.
But I don't expect that anything will happen in this regard as the new version of Mailman in Debian/Jessie now base64 encodes message bodies for no good reason and with no apparent way to disable it.
Even if that weren't the case; it seems like the previous header mangling issue *might* be because of the Python standard library, and I'm unsure how easily it can be fixed.
It MIGHT be possible to make Mailman forward mail without breaking DKIM if the sender uses base64 encoding,
Assuming the header issue was also fixed...
but if the sender doesn't (as my favourite MUA doesn't) then that seems impossible.
...or there were also a way to disable it (or revert the change that introduced it)
Which provokes the question - why not fix Mailman so it doesn't break the DKIM on the original message?
I'll take a *guess*, and assume it's to avoid shaving a yak; the 2.1.x maintainers don't have the time (or can justify) working around DKIM edge cases by also having to work around the Python standard library.
Mailman can already sensibly handle DKIM signatures.
No it seems to be broken and becoming more broken. If you think this can be solved then please tell me how.
I agree, where "sensibly handle" means "preserve" (rather than "remove") In which case, I don't think there's a solution that doesn't require at least a DKIM aware mailing list manager (of which it appears Mailman 2.1.x is not)
IIRC this is because of the design of Mailman; it interprets the headers and writes them out again, so it can't write them back exactly the same as they were before.
In using the standard library to parse the message, that's exactly what appears to be happening.
I don't have the references handy, I apologise in advance if I got the above wrong.
No, seems you were right, on both counts.
[...]
[...]
Which seems to be saying we need to mangle the From: header due to poor design decisions in Mailman.
Only if we want forwarded mail to pass DMARC policy, which is a seperate issue (the second one on my original post)
If we want to support Gmail recipients then we have to do that.
Yes, unless DKIM signatures could be preserved; but again, only for those messages sent from a domain publishing a restrictive DMARC policy