On 4/12/22 11:45, David Newman wrote:
To rule out the smtp module, I sent a PGP-signed message using a different MUA (Thunderbird, in my case). Mailman3 accepted this post without complaint, and I reported back to list users that this appears to be an Apple Mail encoding issue.
Normally, that'd be the end of it. But this is a list for a bunch of Internet graybeards, including one of the authors of the SMTP protocols and the subscriber is a former IETF chair. He's grumbling that if this really were an Apple Mail issue, wouldn't it be far more widespread?
Maybe, but who knows.
The issue is with at least macOS 12.0.1, Mail.app Version 15.0 (3693.20.0.1.32), and GPG Mail 6.0, Build 2023.
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.
I had a long exchange with Barry Warsaw about this. an excerpt is
It's definitely an Apple Mail issue. Both the message you sent and the original message part have the same defect: InvalidMultipartContentTransferEncodingDefect()
Also, My Thunderbird MUA wouldn't display the message content at all.
Interesting though that your original message was also signed and sent by Apple Mail and didn't have the defect. It's structure was
multipart/signed multipart/alternative text/plain text/html application/pgp-signature
and none of the multipart parts have Content-Transfer-Encoding.
The follow up you sent with the original message was
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
All the asterisked parts have a Content-Transfer-Encoding header which is the defect.
It seems to be related to the presence of the empty text/plain part following the signature.
I don't think it would be, because (a) Mailman2 is still far more pervasive than Mailman3 and (b) the combination of PGP signing and Apple Mail on MacOS and Mailman3 is still pretty unusual.
Has anyone else hit this encoding issue, other than the post above? And did Mailman2 silently accept this because it was less strict about checking for bad encoding?
To my knowledge it's only been hit by Barry and the poster of the original report
Mailman 2.1 is has the Python 2 email package which doesn't report InvalidMultipartContentTransferEncodingDefect().
I reported it in November at https://feedbackassistant.apple.com/feedback/9768496 which is open with no reply.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan