removing s/mime parts before distributing mail to list-members required?
Hi,
thank you for mailman!
More and more mails contain s/mime signatures. How to deal with that? We do not want to send out "broken" mails. What is best practice?
Removing the s/mime part seems right, but how to do that? pass_mime_types could help, but
removing multipart (and specifying multipart/alternative and multipart/mixed) from list blocks allmost all mails.
Any help is greatly appreciated.
Thank you.
Stefan
On 12/2/19 12:44 AM, Stefan Bauer via Mailman-Users wrote:
More and more mails contain s/mime signatures. How to deal with that? We do not want to send out "broken" mails. What is best practice?
This reply is signed. I don't think the sig will be broken.
Removing the s/mime part seems right, but how to do that? pass_mime_types could help, but
pass_mime_types for this list is:
multipart text/plain text/x-diff text/x-patch application/pgp-signature application/pkcs7-signature text/html message/rfc822
Both collapse_alternatives and convert_html_to_plaintext are Yes.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Stefan Bauer via Mailman-Users writes:
More and more mails contain s/mime signatures. How to deal with that?
To add to what Mark says, I would say not at all. I would consider broken S/MIME signatures to be a bug, because Mailman should be treating the multipart/signed *part* as a block, and appending both header (if any) and footer (if any) as separate parts. The content subpart should be unchanged so the signature should not be broken. If subscribers complain that signatures don't verify, please report that to us. (I'm not sure we would do anything about it, since Mailman 2 is nearing end-of-life. On the other hand I would consider it a priority for Mailman 3, and it might not be hard to backport.)
The problems with signatures have to do with signatures intended to ensure integrity of the whole message, usually DKIM. These signatures are necessarily broken if Mailman makes any change to the message body or to the specified message header fields. S/MIME only deals with body parts on a part by part basis, and Mailman doesn't need to change those.
Steve
On 12/2/19 12:44 AM, Stefan Bauer via Mailman-Users wrote:
More and more mails contain s/mime signatures. How to deal with that? We do not want to send out "broken" mails. What is best practice?
This reply is signed. I don't think the sig will be broken.
Removing the s/mime part seems right, but how to do that? pass_mime_types could help, but
pass_mime_types for this list is:
multipart text/plain text/x-diff text/x-patch application/pgp-signature application/pkcs7-signature text/html message/rfc822
Both collapse_alternatives and convert_html_to_plaintext are Yes.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Stefan Bauer via Mailman-Users writes:
More and more mails contain s/mime signatures. How to deal with that?
To add to what Mark says, I would say not at all. I would consider broken S/MIME signatures to be a bug, because Mailman should be treating the multipart/signed *part* as a block, and appending both header (if any) and footer (if any) as separate parts. The content subpart should be unchanged so the signature should not be broken. If subscribers complain that signatures don't verify, please report that to us. (I'm not sure we would do anything about it, since Mailman 2 is nearing end-of-life. On the other hand I would consider it a priority for Mailman 3, and it might not be hard to backport.)
The problems with signatures have to do with signatures intended to ensure integrity of the whole message, usually DKIM. These signatures are necessarily broken if Mailman makes any change to the message body or to the specified message header fields. S/MIME only deals with body parts on a part by part basis, and Mailman doesn't need to change those.
Steve
participants (3)
-
Mark Sapiro -
Stefan Bauer -
Stephen J. Turnbull