On 4/14/22 9:50 AM, Mark Sapiro wrote:
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...
Yes.
To be clear, this is an Apple Mail issue. Mailman 3 accepted PGP-signed messages from Apple Mail on versions prior to 15.0 running on MacOS 12.0.1. Something changed on Apple's part.
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.
That's not my experience. Mailman 3 accepted without complaint a PGP-signed message I sent from Thunderbird 91.8.0 and forwarded it to list subscribers with the message body intact.
dn