2049079 - Inline-image sandwiched between two text/plain parts should not stop the text parts from being forwarded properly

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect)

Description

[Max Emig [:maxe]]

Attachment: text-sandwiched-inline-image.eml

I recently learned that Apple Mail does not always use relatively sane html for in-line images, but if no other formatting is applied splits the e-mail transparently into two or more text/plain parts with the attachment with Content-Disposition: inline; sandwiched in between.

This works fine enough when viewing, but breaks when forwarding.

Steps to reproduce:

1. Open my sample .eml-attachment.
2. Press forward

Expected behaviour:
"Don't leave me behind, I also wanna go." should be in the body of the forwarding compositor.

Actual behaviour:
"Don't leave me behind, I also wanna go." ends up in a Attached Message Part.txt file.

Reproduced with actual e-mails from Apple Mail on macOS 26.5.1.

Comment 1

[Max Emig [:maxe]]

Attachment: Bug 2049079 - Append later text/plain body parts to the forwarded body instead of attaching them. r=#thunderbird-back-end-reviewers

Comment 2

[Francesco (no longer active, use PM for contact)]

If you attach .emls as text/plain, we can read them here instead of having to download them.

I received a message from an Apple mail user with this structure:

--Apple-Mail-CE39B06C-55CE-4556-81B2-53AA7481248C
Content-Type: image/jpeg;
	name=image0.jpeg;
	x-apple-part-url="mf_D35DFCC9-7674-484D-B03E-2FB2A4F8DA4A/L0/001"
Content-Disposition: inline;
	filename=image0.jpeg
Content-Transfer-Encoding: base64

/9j/4AAUSkZJRgABAQEBLAEsAABBTVBG/+EtGkV4aWYAAE1NACoAAAAIAAYBEgADAAAAAQAGAAAB
GgAFAAAAAQAAAFYBGwAFAAAAAQAAAF4BKAADAAAAAQACAAACEwADAAAAAQABAACHaQAEAAAAAQAA
...

--Apple-Mail-CE39B06C-55CE-4556-81B2-53AA7481248C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Plains text message

This message doesn't get forwarded correctly. Would that be covered here? I didn't file a bug since I believed that the MIME structure wasn't valid.

Comment 3

[Max Emig [:maxe]]

If you attach .emls as text/plain, we can read them here instead of having to download them.

But downloading gets harder, needs save as and re-entering the filename.

Comment 4

[Max Emig [:maxe]]

This message doesn't get forwarded correctly. Would that be covered here? I didn't file a bug since I believed that the MIME structure wasn't valid.

So image first, text/plain afterwards? Afaik I fixed this case in bug 1813044 which landed in 151.

Comment 5

[Francesco (no longer active, use PM for contact)]

Not at my desk at the moment. Yes, image first, IIRC, not as attachment but inline. Correction: No multipart/mixed. Like your sample but without the first text part. So not a "sandwich", but an "open sandwich" of only two parts.

Comment 6

[Max Emig [:maxe]]

(In reply to Francesco from comment #5)

Not at my desk at the moment. Yes, image first, IIRC, not as attachment but inline. No multipart/mixed. Like your sample but without the first text part. So not a "sandwich", but an "open sandwich" of only two parts.

Please retest in either Stable, Beta or Daily.

ESR isn't the best baseline.

Comment 7

[Francesco (no longer active, use PM for contact)]

OK, but I don't have a build with your patch. I thought you could just drop the first text part from your sample and try it.

Comment 8

[Max Emig [:maxe]]

(In reply to Francesco from comment #7)

OK, but I don't have a build with your patch. I thought you could just drop the first text part from your sample and try it.

A quick reproduction attempt showed this working with- as well as without the new patch.

As in the latter text/plain part upgraded to the canonical text plus the picture as a proper attachment.

Comment 9

[Francesco (no longer active, use PM for contact)]

(In reply to Max Emig from comment #8)

A quick reproduction attempt showed this working with- as well as without the new patch.

Thank you, yes, the case I had with the the picture being the first part of multipart/mixed does indeed work in TB 153 beta. Sorry about the noise in this unrelated bug.

Comment 10

[Francesco (no longer active, use PM for contact)]

I'm taking the liberty to change the status to ASSIGNED, since you presented a patch. Please revert, if that's incorrect.

Comment 11

[Max Emig [:maxe]]

n/a

Comment 12

[Francesco (no longer active, use PM for contact)]

We settled this in comment #9.

Comment 13

[Max Emig [:maxe]]

(In reply to Francesco from comment #12)

We settled this in comment #9.

Sorry, I had still an earlier draft open when attaching the keyword.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/869d984f2221
Append later text/plain body parts to the forwarded body instead of attaching them. r=mkmelin

Comment 15

[Max Emig [:maxe]]

Comment on attachment 9599485 [details]
Bug 2049079 - Append later text/plain body parts to the forwarded body instead of attaching them. r=#thunderbird-back-end-reviewers

Uplift Approval Request

• Please state case for uplift consideration and ensure bug severity is set: Thunderbird 153 ESR release is still over three weeks away, actually impacting e-mails generated by Apple Mail on macOS 26.
• User impact if declined: Same broken behaviour so users facing this issue will be forced to wait another year on ESR or change the channel.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Daily?: Yes
• Has the fix been verified in Beta?: No
• Needs manual test from QA?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• Does the fix cause any migrations to be skipped?: No
• String changes made/needed:

Comment 16

[Corey Bryant]

Comment on attachment 9599485 [details]
Bug 2049079 - Append later text/plain body parts to the forwarded body instead of attaching them. r=#thunderbird-back-end-reviewers

[Triage Comment]
Approved for beta

Comment 17

[Evandro Baginski [:ebaginski]]

Thunderbird 153.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/4370f57e542a