boundary different from the actual one

[dslul]

I noticed this issue while investigating why Geary fails to render emails from hydroxide. Here is an example:

Content-Type: multipart/mixed;
 boundary=5f90a47b14ee5fb2ef971a766f59c2c304d94b909316a2b453e171f7fe58
Mime-Version: 1.0
Message-Id: REDACTED
To: <REDACTED@protonmail.com>
From: <REDACTED@gmail.com>
Subject: REDACTED
Date: Wed, 09 Dec 2020 10:40:20 +0100

--0b4f25bfb7be712ecea75f6e2a15c479efbd5aedbd0e123480a6e03914f8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8

REDACTED MESSAGE

--0b4f25bfb7be712ecea75f6e2a15c479efbd5aedbd0e123480a6e03914f8--

Some email clients can still render these emails, but others (like Geary) fail, because they cannot find the delimited message.

[sbinet]

I believe this to be another instance of #112

which I have been testing w/ #129.
could you give it a try?

[dslul]

Just tried, no luck.

[dslul]

I investigated a little more with wireshark. The problem is that clients that do these two commands to get the whole message:

a022 uid fetch 13 rfc822.header
a023 uid fetch 13 body.peek[text]

instead of a single

a023 uid fetch 13 body.peek[]

won't work, because in the first case a random boundary will be generated for each command, hence the mismatch.

[emersion]

Right. We should somehow generate a unique boundary for each message (or globally). Some messages might need multiple boundaries, and these still need to be different.

[emersion]

Can you try #144?

[dslul]

Can you try #144?

It works perfectly now 👍