On Sun, Mar 29, 2020 at 08:03:52PM +0200, David Hildenbrand wrote:
Please, David H - whatever you do with email is WRONG.
Fix your completely broken email client. Stop doing this.
To butt in uninvited into this conversation, it doesn't look like there's anything really wrong with what David sends, except for the quoted-printable formatting, which is probably converted automatically by one of Red Hat's relay MTAs.
What I received via the mailing list (e.g., linux-mm@kvack.org)
Message-Id: 20200128093542.6908-1-david@redhat.com MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: <linux-mm.kvack.org> [...] X-Mimecast-Spam-Score: 1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 [...]
And a lot of this MIME crap.
I have no idea if such a conversion is expected to be done.
In theory, it doesn't really matter, as mail clients are supposed to be properly undoing all this 7-bit legacy madness. When we run that thread through "b4 am" to get things back into 8bit, everything looks just fine. You can try it yourself:
b4 am 20200128093542.6908-1-david@redhat.com
Unless I am missing something important, the issue is not in mail client setup, but there is something in the mailing infrastructure horribly messing with my mails. Red Hat has recently switched to Mimecast and there have been plenty of issues, maybe this is one of these.
I guess the only thing I can do is sending mails via a different mail server / different email address?
It would appear that the workflow Andrew uses to queue up patches from you isn't expecting quoted-printable formatting, which is why when Linus gets them, they are mangled.
We would either need to switch Andrew to a set of tools that handle 7bit legacy formats better, or figure out how you can send things via MTAs that won't convert from 8bit to quoted-printable. Maybe you can convince Red Hat to set up their relays to always preserve 8bit?
-K
On Sun, Mar 29, 2020 at 12:43 PM Konstantin Ryabitsev konstantin@linuxfoundation.org wrote:
It would appear that the workflow Andrew uses to queue up patches from you isn't expecting quoted-printable formatting, which is why when Linus gets them, they are mangled.
I don't think that's the case.
Why? Because I see _proper_ handling of MIME and quoted-printable from Andrew all the time.
For example, anything from Jérôme Glisse always ends up having been quoted-printable, simply because of how Jérôme's emails look, and because he has 8-bit characters in his name.
There are other examples of the same thing - a lot of the emails I get from Andrew do end up having quoted-printable encoding.
It's only David's patches that then end up having lost the encoding marker, but have QP sequences in the commit message.
The odd thing is that the *patches* are fine, even if they have equals signs etc that would have been QP-encoded too. So it's literally just the commit message that tends to be corrupt.
Which is why I was suspecting people cut-and-pasting the raw emails for examplanations or something similar.
Linus
On Sun, Mar 29, 2020 at 12:55 PM Linus Torvalds torvalds@linux-foundation.org wrote:
Which is why I was suspecting people cut-and-pasting the raw emails for examplanations or something similar.
"examplantions"? Really?
I had some kind of mini-stroke. Example/explanations ;)
Linus
On Sun, Mar 29, 2020 at 12:55:09PM -0700, Linus Torvalds wrote:
On Sun, Mar 29, 2020 at 12:43 PM Konstantin Ryabitsev konstantin@linuxfoundation.org wrote:
It would appear that the workflow Andrew uses to queue up patches from you isn't expecting quoted-printable formatting, which is why when Linus gets them, they are mangled.
I don't think that's the case.
Why? Because I see _proper_ handling of MIME and quoted-printable from Andrew all the time.
Hmm... You are correct. I see that Naohiro Aota's original patch was also QP-encoded. I'm just as confused as everyone, then. :) As far as I can tell, there is no meaningful difference between David's emails and Naohiro's:
https://lore.kernel.org/linux-mm/20200206090132.154869-1-naohiro.aota@wdc.co... https://lore.kernel.org/linux-mm/20200128093542.6908-1-david@redhat.com/raw
David's original patch is well-formed and the only notable difference between the two is that there's a line of ==== in Nahorio's email that makes it immediately obvious that the message needs to be decoded before it can be used.
-K
It would appear that the workflow Andrew uses to queue up patches from you isn't expecting quoted-printable formatting, which is why when Linus gets them, they are mangled.
We would either need to switch Andrew to a set of tools that handle 7bit legacy formats better, or figure out how you can send things via MTAs that won't convert from 8bit to quoted-printable. Maybe you can convince Red Hat to set up their relays to always preserve 8bit?
I'll give it a try, but I think it's rather unlikely ... :)
On 30.03.20 16:54, David Hildenbrand wrote:
It would appear that the workflow Andrew uses to queue up patches from you isn't expecting quoted-printable formatting, which is why when Linus gets them, they are mangled.
We would either need to switch Andrew to a set of tools that handle 7bit legacy formats better, or figure out how you can send things via MTAs that won't convert from 8bit to quoted-printable. Maybe you can convince Red Hat to set up their relays to always preserve 8bit?
I'll give it a try, but I think it's rather unlikely ... :)
So, people are looking into. Literally any mail that goes via Mimecast servers (at least sent by me!) is converted *for whatever reason* to quoted-printable.
E.g., patches I punched out today via "git send-email" even have the line continuations thingy again (they disappeared for a while, maybe there are different MTAs involved and it's like playing the lottery)
https://lore.kernel.org/linux-mm/20200401104156.11564-2-david@redhat.com/raw
From what I can tell the mail itself is fine once converted, it's just
nasty that 8-bit is converted *for whatever reason*.
On Wed, Apr 01, 2020 at 03:35:01PM +0200, David Hildenbrand wrote:
We would either need to switch Andrew to a set of tools that handle 7bit legacy formats better, or figure out how you can send things via MTAs that won't convert from 8bit to quoted-printable. Maybe you can convince Red Hat to set up their relays to always preserve 8bit?
I'll give it a try, but I think it's rather unlikely ... :)
So, people are looking into. Literally any mail that goes via Mimecast servers (at least sent by me!) is converted *for whatever reason* to quoted-printable.
I mean, it's not *wrong* to do that -- older mail standards required that all MTA-to-MTA communication should be done in 7bit. But we're literally talking previous-century legacy protocols here. Forcefully converting all mail to 7bit is about the most 90s thing you can do these days, short of being really into mullets and Arsenio Hall.
E.g., patches I punched out today via "git send-email" even have the line continuations thingy again (they disappeared for a while, maybe there are different MTAs involved and it's like playing the lottery)
Those show up when your lines are longer than 76 characters. Because, you know, otherwise the message would be too wide to fit through the ethernet cable.
https://en.wikipedia.org/wiki/Quoted-printable#Quoted-Printable_encoding
Best regards, -K
On 01.04.20 17:33, Konstantin Ryabitsev wrote:
On Wed, Apr 01, 2020 at 03:35:01PM +0200, David Hildenbrand wrote:
We would either need to switch Andrew to a set of tools that handle 7bit legacy formats better, or figure out how you can send things via MTAs that won't convert from 8bit to quoted-printable. Maybe you can convince Red Hat to set up their relays to always preserve 8bit?
I'll give it a try, but I think it's rather unlikely ... :)
So, people are looking into. Literally any mail that goes via Mimecast servers (at least sent by me!) is converted *for whatever reason* to quoted-printable.
I mean, it's not *wrong* to do that -- older mail standards required that all MTA-to-MTA communication should be done in 7bit. But we're literally talking previous-century legacy protocols here. Forcefully converting all mail to 7bit is about the most 90s thing you can do these days, short of being really into mullets and Arsenio Hall.
The last sentence really made my day, thanks :D
E.g., patches I punched out today via "git send-email" even have the line continuations thingy again (they disappeared for a while, maybe there are different MTAs involved and it's like playing the lottery)
Those show up when your lines are longer than 76 characters. Because, you know, otherwise the message would be too wide to fit through the ethernet cable.
Yeah, however, the mail servers I'm using are not doing this consistently. Maybe some of them are more advanced than others :)
Let's see if IT can teach these mail servers about the 21 century ...
linux-stable-mirror@lists.linaro.org
-
David Hildenbrand -
Konstantin Ryabitsev -
Linus Torvalds