Mark Sapiro writes:
That combination at least produces multipart/signed messages with multipart/* parts containing a Content-Transfer-Encoding: header.
The Python 3 email library considers this to be a InvalidMultipartContentTransferEncodingDefect() message defect.
Merely containing C-T-E is not an error per RFC 2045, although it seems to consider it a stupid thing to do. If present, it may be "binary", "7-bit", or "8-bit" (below summarized as "cleartext").
Did Apple Mail apply a non-cleartext C-T-E? Or has an RFC tightening that restriction been published since? (I don't know why it would, though.)
Even with a non-cleartext C-T-E, it seems reasonable for Mailman to treat it as application/octet-stream and pass it through, unless the list is configured to do something like strip application/octet-stream or that requires decoding like spam-filtering (Postel principle, although one could argue it shouldn't be sent on on the same principle -- ah, the joys of being an e-mail Mediator). That would be especially true it if were quoted-printable, since any relevant MIME headers would (presumably) be pure ASCII and therefore unencoded.
multipart/signed multipart/mixed * text/plain message/rfc822 (the attached message) * multipart/signed * text/plain application/pgp-signature text/plain (an empty plain text part) text/plain (a quote of my message to you) application/pgp-signature
It's true that Apple Mail is horked if it produces that structure with C-T-E in the indicated places (but we already knew that :-( ).
Steve