Comment 44 for bug 303140

It cannot be that difficult to finally solve this problem.

What I've been doing as a workaround for years is the following:
* use any tool/editor capable of manipulating the email (header), e.g., the HeaderToolsLite extension.
* Change in the "Content-Type" entry the "multipart/signed" to "multipart/mixed" and remove (or even better, rename) the "protocol" parameter, e.g.:
replace
  Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
 micalg=SHA1; boundary="----=_NextPart_000_0000_01D1D126.351C61F0"
by
  Content-Type: multipart/mixed; protocol="application/x-pkcs7-disabled-signature";
 micalg=SHA1; boundary="----=_NextPart_000_0000_01D1D126.351C61F0"
* As a result, the email is not considered signed anymore, while the signature is now treated as a regular attachment.
* Detach/detect any attachments as you want.

Note that this way there is still an indication that the email was signed originally, yet without a disturbing "broken signature" symbol being shown.

In case you later restore the signature MIME header after manipulating the attachments (or the remaining body), the signature will of course show broken.

If you did not change anything in the body including the attachments (or restore it), you can easily restore the valid signature by reverting the small header changes mentioned above.

BTW, TB apparently blocks deleting/detaching attachments as long as it finds "application/x-pkcs7-signature" as a substring(!) of the Content-Type entry, which is bad hack. It should rather check that there is a parameter with (full) name "protocol" and (full) value "application/x-pkcs7-disabled-signature"

Hope this helps as a hint how to design and implement a solution smoothly.