Re: [patch 2/5] drivers/base/memory.c: indicate all memory blocks as removable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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@xxxxxxxxxx

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.

-- 
Thanks,

David / dhildenb






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux