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
IIRC I think somebody said that Mailman breaks the DKIM on the
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
Thanks, I'd forgotten about <201510172046.45136.russell(a)coker.com.au>
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
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
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
...or there were also a way to disable it (or revert the change that
> > 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.
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
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