On 4/14/22 08:21, Stephen J. Turnbull wrote:
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.)
Yes. The C-T-E on all the multipart parts was quoted-printable, not allowed under RFC 2045.
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.
The Python email library says the message is defective. Mailman's lmtp runner in turn rejects the defective message with a 501 status https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/lmtp.py...
It could accept a defective message or one with specific defects, but this is problematic for further processing. For example, at least one MUA, Thunderbird, renders such a message with an empty body.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan