avoid stripping top-level MIME-part
Alice and Bob each sent a PGP/MIME encrypted+signed message to a schleuder 3.0.0~beta17 list.
Both messages had text/plain and text/html parts. But Bob's message was reformatted by the schleuder list in a way that caused both the plain and html parts to display to the recipient.
Both Alice and Bob were using some variant of icedove 45.6.0 on debian systems. Alice's version of enigmail is 1.9.6, Bob's was 1.8.2.
I'll show the structure of the clearted MIME parts inside the application/encrypted part (once it's been decrypted):
Here's how Alice's initial message was structured (note the weird extra multipart/mixed layer marked as "2" here):
1 gpg --decrypt < alice-orig.eml | printmimestructure
2 └┬╴multipart/mixed 1581 bytes
3 └┬╴multipart/alternative 1257 bytes
4 ├─╴text/plain 274 bytes
5 └─╴text/html 561 bytes
and here's how it came out once it was re-sent by schleuder (part "3" has been re-mapped to part "9", with the schleuder metadata inserted as part "8"):
6 gpg --decrypt < alice-resent.eml | printmimestructure
7 └┬╴multipart/mixed 2549 bytes
8 ├─╴text/plain 215 bytes
9 └┬╴multipart/alternative 1325 bytes
10 ├─╴text/plain 286 bytes
11 └─╴text/html 583 bytes
But Bob's original message was more traditionally structured:
12 gpg --decrypt < bob-orig.eml | printmimestructure
13 └┬╴multipart/alternative 3982 bytes
14 ├─╴text/plain 1205 bytes
15 └─╴text/html 2355 bytes
And as a result, it ends up with both parts displayed sequentially, rather than as alternatives once it's re-sent through schleuder (part "18" is the schleuder metadata part, which is then just displayed inline with parts "19" and "20" (which themselves originate from parts "14" and "15", above):
16 gpg --decrypt < bob-resent.eml | printmimestructure
17 └┬╴multipart/mixed 5300 bytes
18 ├─╴text/plain 220 bytes
19 ├─╴text/plain 1252 bytes
20 └─╴text/html 2425 bytes
So it looks to me like schleuder is stripping the top-layer multipart, and replacing it with its own multipart/mixed aggregator. It really shouldn't do that -- it should always take the top-level part of the incoming message, and place it as a peer of its metadata part. That is, an incoming mesage like:
A └┬╴multipart/alternative
B ├─╴text/plain
C └─╴text/html
Should be mapped to:
D └┬╴multipart/mixed (schleuder wrapper)
E ├─╴text/plain (schleuder metadata)
F └┬╴multipart/alternative (comes from input part "A")
G ├─╴text/plain (comes from input part "B")
H └─╴text/html (comes from input part "C")
Let me know if any of this doesn't make sense.