[mu4e bug] Email forwarded via Office 365 does not include new text and has extra attachment (mime issue?)

[bramadams]

Describe the bug

When forwarding an email, the new text added above the forwarded text is not included. Furthermore, the line "-------------------- End of forwarded message --------------------" somehow ends up in an attachment.

I've attached an example email (email-original.txt), the draft of the forwarded email with some new text at the top (email-draft.txt) and the final forwarded email that is received (email-forwarded.txt), which does not contain the new text.

email-original.txt
email-draft.txt
email-forwarded.txt

How to Reproduce

These are the steps:

1. run mu4e-compose-forward on an email
2. add some new text at the top, i.e., before the forwarded message
3. send it
4. the resulting forwarded email does not contain the new text from step 2, and somehow there is an extra attachment containing just "-------------------- End of forwarded message --------------------"

Environment

Using the mu4e 1.12.8 and emacs 30.0.93, with message-forward-as-mime set to nil.

Checklist

• you are running either an 1.10.x/1.12.x release or master (otherwise please upgrade)
• you can reproduce the problem without 3rd party extensions (including Doom/Evil, various extensions etc.)
• you have read all of the above

[djcb]

Can't reproduce, when I forward that message, I get a correct one back. The draft you have looks reasonable as well, at a first glance.

I get:

--=-=-=
Content-Type: text/plain


hello world

-------------------- Start of forwarded message --------------------
From: [email protected]
To: [email protected]
CC: 
Subject: network downtime upgrades

etc.

In your forwarded messages there are all kinds of things that are not from Mu4e. So perhaps the mail-server is mishandling the message? Can you reproduce with a different mail-server?

[bramadams]

Thanks for the feedback.

It turns out that the issue only happens when forwarding the email using smtp-mail.outlook.com, i.e., using Office 365. Using gmail's smtp does not exhibit the problem, nor does it show up when forwarding the email using the Office 365 web app.

Googling on the name of the extra attachment (att00001.txt) learnt that this kind of issue seems to occur for emails having a more complex MIME structure (e.g., attachments) that somehow does not adhere to what Office 365 expects, causing the latter to re-interpret the MIME content.

I tried manually removing the <#multipart type=related> in email-draft.txt (basically removing the attached png file), and now:

1. the new text added on top of the email does show up (which is an improvement)
2. yet both the plain text and html versions of the forwarded email occur as attachments instead of being inlined (contradicting the nil setting for message-forward-as-mime)
3. there is still an extra attachment containing "-------------------- End of forwarded message --------------------"

I tried some other things, like removing the HTML part (which I typically never need to forward), etc. but I always end up with either the original problem or the one above.

The only workaround seems to be to somehow extract the plain text and the original attachments, yanking them right before the multiparts, then discarding the multiparts altogether. Yet, this is not really feasible on a daily basis, nor can I ditch Office 365 (work-related).

Is it possible that some delimiter is missing in the MIME (multi)part of the email, or perhaps an encoding issue (e.g., the usage of quoted-printable in email-forwarded.txt)?

[bramadams]

Just compared the email forwarded from mu4e to the one forwarded from the web interface of Office 365. It seems like the latter merges the new text from the forwarded email with the original plain and html message text (instead of putting the new text outside the multiparts), like this:

[...]
Content-Type: multipart/related;
	boundary="_004_YT3PR01MB105597A30488F27DF6DDCEAC6F21A2YT3PR01MB10559CA_";
	type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: v.w
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YT3PR01MB10559.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: a347fade-b0a8-4c39-a2a7-08dd35e3aaab
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2025 04:10:09.3539
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d61ecb3b-38b1-42d5-82c4-efb2838b925c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kOeZ9vpVHwVblepGrFjxIwwnlJ3vPGpWd0RWAOsbK6YGkvnBOtevMgIxiI48S7WIYYEutJ9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB8727
X-TUID: v+p/YLmZq/WD

--_004_YT3PR01MB105597A30488F27DF6DDCEAC6F21A2YT3PR01MB10559CA_
Content-Type: multipart/alternative;
	boundary="_000_YT3PR01MB105597A30488F27DF6DDCEAC6F21A2YT3PR01MB10559CA_"

--_000_YT3PR01MB105597A30488F27DF6DDCEAC6F21A2YT3PR01MB10559CA_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

Text before the forwarded email.

Thanks!
________________________________
From: [email protected]
To: [email protected]
CC: 
Subject: network downtime upgrades

If you see problems with that date, please reach out to me directly. We have a backup date that could work, but we would have fewer people that day, so would either get less done or have longer service outages.

[...]

[djcb]

I guess there are few things you could try -- different values for message-forward-as-mime and message-forward-show-mml and see if that makes a difference. You can also try some different files to forward -- start with some plain text, and then with some attachment, html mail etc., and see what works and what doesn't.

[bramadams]

Setting message-forward-as-mime to t (with or without MML) works correctly, i.e., no unexpected behaviour, but (by definition) attaches the forwarded email instead of inlining.

With message-forward-as-mime as nil, a plain text email works correctly, while an email with plain/html text (no "related" images) does show the new text, but has the issues described in #2808 (comment) (i.e., the case when removing <#multipart type=related>).

[djcb]

Hmm, not sure we can help much in this case. It seems like some specific problem with that particular mail-server; moreover, mu4e is re-using the Emacs built-in functionality for that (in Gnus).

Now, I suspect many other e-mail clients can interact with that mail-server directly, so it may be interesting to try the simplest possible forward message with a client that gets the expected result vs what you get with mu4e, and analyze the differences. But, to be honest, you would need to do that yourself -- our time is limited, sorry!

You could of also ask on the mailing-list.