Broken signature because of multipart/alternative
Hello everybody,
I'm running Mailman 2.1.9 here at RWTH Aachen University.
Our University recently started distributing smime-certificates signed by our certificate authority. Now more and more people use our mailinglists with signed messages.
I disabled the footer and mime-filtering on my testing list and have successfully sent a signed message over this list.
But if I send an email with text/html and text/plain, there is the following problem:
The message has the content-type multipart/signed as expected, but the signature is broken because of some additional spaces in the content-type: multipart/alternative. A diff-output of a mail sent over the list and direct shows:
35c67 < This is a cryptographically signed message in MIME format. < < --------------ms010705010807090202080200 < Content-Type: multipart/alternative; < boundary="------------020000020307030005020605"
The other differences between those two mails are only in the header (other route, List-* headers). And sending only html or only text (no multipart/alternative) doesn't brake the signature.
Any ideas how i get rid of those extra spaces between multipart/alternative; and boundary=? I don't think, this is a intended behavior?
Kind regards, Wilfred Gasper
Wilfred Gasper RWTH Aachen University, Center for Computing and Communication Seffenter Weg 23, 52074 Aachen (Germany) gasper@rz.rwth-aachen.de - www.rz.rwth-aachen.de
Wilfred Gasper wrote:
I don't think those are extra spaces. This is a folded header, and I think what happens is the original header is folded with <CR><LF><SP> and it is processed by Mailman for some reason and when refolded by Mailman it is folded with <CR><LF><TAB>, thus breaking the signature.
What is the list setting for filter_content? If it is Yes, you could try changing it to No and see if that helps.
The real issue is header folding and unfolding is ambiguous in the RFCs in the first place, and both <SP> and <TAB> are allowed as the folding white space. Thus, it turns out in practice that header unfolding and refolding is something of a black art and the underlying Python email library doesn't guarantee that transformations such as you've observed do not occur.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
Mark Sapiro wrote:
you're right, it's an <TAB> instead of a <SP>. I tried an email with text/plain and image/jpeg as attachment and the result was a change from <CR><LF><SP> to <SP>.
What is the list setting for filter_content? If it is Yes, you could try changing it to No and see if that helps.
Since it's a testing list, it's already set to No because I wanted the email unchanged.
Thank you for this description. So there's nothing I can do against it like using another version of Python?
Kind regards, Wilfred Gasper
-- Wilfred Gasper RWTH Aachen University, Center for Computing and Communication Seffenter Weg 23, 52074 Aachen (Germany) gasper@rz.rwth-aachen.de - www.rz.rwth-aachen.de
Wilfred Gasper writes:
Thank you for this description. So there's nothing I can do against it like using another version of Python?
Well, another version of Python won't do. You need another version of the Internet. According to RFC 2822,
Subject: a few words
Subject: a few words
Subject: a few words
have identical semantics. So if you sign RFC 2822 headers, you need to canonicalize them before signing, and again before verifying, because any relay might change them.
See the domain keys standard www.dkim.org for a protocol that has to solve a similar problem.
Mailman intends to deal with domain keys in some future version (but implementation is not scheduled yet, don't hold your breath ... unless you want to do it yourself), so the necessary code for canonicalization will eventually be available in Mailman (presumably inherited from the standard email module in Python). But you still face breakage from all relays between signer and verifier.
HTH
Wilfred Gasper wrote:
I don't think those are extra spaces. This is a folded header, and I think what happens is the original header is folded with <CR><LF><SP> and it is processed by Mailman for some reason and when refolded by Mailman it is folded with <CR><LF><TAB>, thus breaking the signature.
What is the list setting for filter_content? If it is Yes, you could try changing it to No and see if that helps.
The real issue is header folding and unfolding is ambiguous in the RFCs in the first place, and both <SP> and <TAB> are allowed as the folding white space. Thus, it turns out in practice that header unfolding and refolding is something of a black art and the underlying Python email library doesn't guarantee that transformations such as you've observed do not occur.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
Mark Sapiro wrote:
you're right, it's an <TAB> instead of a <SP>. I tried an email with text/plain and image/jpeg as attachment and the result was a change from <CR><LF><SP> to <SP>.
What is the list setting for filter_content? If it is Yes, you could try changing it to No and see if that helps.
Since it's a testing list, it's already set to No because I wanted the email unchanged.
Thank you for this description. So there's nothing I can do against it like using another version of Python?
Kind regards, Wilfred Gasper
-- Wilfred Gasper RWTH Aachen University, Center for Computing and Communication Seffenter Weg 23, 52074 Aachen (Germany) gasper@rz.rwth-aachen.de - www.rz.rwth-aachen.de
Wilfred Gasper writes:
Thank you for this description. So there's nothing I can do against it like using another version of Python?
Well, another version of Python won't do. You need another version of the Internet. According to RFC 2822,
Subject: a few words
Subject: a few words
Subject: a few words
have identical semantics. So if you sign RFC 2822 headers, you need to canonicalize them before signing, and again before verifying, because any relay might change them.
See the domain keys standard www.dkim.org for a protocol that has to solve a similar problem.
Mailman intends to deal with domain keys in some future version (but implementation is not scheduled yet, don't hold your breath ... unless you want to do it yourself), so the necessary code for canonicalization will eventually be available in Mailman (presumably inherited from the standard email module in Python). But you still face breakage from all relays between signer and verifier.
HTH
participants (3)
-
Mark Sapiro -
Stephen J. Turnbull -
Wilfred Gasper