Well, that may still be a perfectly fine email.

Yes, it has the MIME crap, but it also has that

Content-Transfer-Encoding: quoted-printable

which should tell all users how to _handle_ that MIME crap.

It's sad that people in this day and age still don't just handle

Content-Transfer-Encoding: 8bit

and just send it on untouched, but SMTP certainly encourages that bad behavior of "convert to 7-bit MIME crap", because in theory there could be SMTP servers out there that can't handle anything 8-bit or with longer lines.

Those SMTP servers should just be scrapped and people told not to use them, but sadly that's not the approach email people have taken. They've taken the approach that old garbage SMTP servers should be allowed to exist and destroy email for the rest of us.

Yeah, would save us trouble :)

...

I have no idea if such a conversion is expected to be done.

It is (sadly) expected to be done by a lot of mail software.

But the problem is that some part of your email handling code then doesn't _undo_ the MIME conversion, and leaves the MIME turds alone, while then that "Content-Transfer-Encoding: quoted-printable" got lost.

Do you at any point end up using a raw mbox and cut-and-pasting stuff?

Just Thunderbolt for reading, and vim for editing. Really nothing special. In this specific case, I don't think I copied anything back and forth. Just a simple git commit and editing the message in vim.

The mail was sent around the same time the other two (?) broken mails showed up (end of January/beginning of February) and ended up in your mail box.

I checked my other patches that are in -next. All (especially the stuff I sent recently) seem to be fine except one remaining patch, sent end of February IIRC:

https://lkml.kernel.org/r/20200228095819.10750-2-david@redhat.com

It also has this issue with long lines in one instance. And for that patch, I still have the original commit lying around here. Did a fresh format-patch+send-mail to another mail address (via RH mailing infrastructure). Again, converted to

Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

But the MIME crap (for the newline) is gone. So the issue seems to be fixed.

Reading email in a broken mail-reader that doesn't undo MIME? Because that's the usual way that these kinds of turds get copied.. Using raw emails without honoring or taking that "Content-Transfer-Encoding" into account.

Again, sorry for the trouble, I suspect bad mailing infrastructure that has been fixed. Will pay attention if this starts happening again, and then switch to another mail server/mail address, because something within RH mailing infrastructure is making our life more difficult than it should be.