[PATCH] dim: avoid early decode on email body.

[Jani Nikula]

On Tue, 15 Sep 2020, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
> On Tue, Sep 15, 2020 at 08:33:25PM +0300, Jani Nikula wrote:
>> On Tue, 15 Sep 2020, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
>> > On Tue, Sep 15, 2020 at 11:05:24AM +0300, Jani Nikula wrote:
>> >> On Tue, 15 Sep 2020, Daniel Vetter <daniel at ffwll.ch> wrote:
>> >> Please test this on a message with Content-Transfer-Encoding set before
>> >> applying.
>> >
>> > I tested and it doesn't work... but it also doesn't work without this patch
>> > and with python2. It doesn't work anyways...
>> >
>> > Is this a case that we should care?
>> 
>> Yes. Even if the sender does not use it, some mail transfer agents may,
>> for example, base64 encode the body. We do need to decode the mails.
>
> Yes, you are right... but it never worked so it means we never supported
> this case. why should we start supporting it now?

I'm pretty sure it has worked in the past, and *must* continue to
work. Please just git blame the history near there and you'll find
base64 references.

>> Anyway, the problem doesn't seem to be specifically about the decoding
>> itself, I think it's about the difference in python 2 vs. 3 unicode. In
>> your example, it looks like a binary blob.
>
> indeed, but I didn't find a clean way to modify the decode part itself.
> and removing the decode works for all of our current cases.

Ahem, all the cases you just tried. :p


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center