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 <[EMAIL PROTECTED]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
