[Mailman-Users] Broken signature because of multipart/alternative

[Mark Sapiro]

Wilfred Gasper wrote:
>
>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"
>---
> > This is a cryptographically signed message in MIME format.
> >
> > --------------ms010705010807090202080200
> > Content-Type: multipart/alternative;
> >       boundary="------------020000020307030005020605"


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.


>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?


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 at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan