forward messages inline for Outlook?

70 views
Skip to first unread message

Victor A. Stoichita

unread,
Feb 4, 2025, 2:51:24 PMFeb 4
to mu-di...@googlegroups.com
Hi,

When I forward an email to my contacts who use Outlook, they get the
forwarded part as an attachment.
In previous versions of mu4e, the forwarded part used to be inlined.

I understand that this is not related to mu4e, since we now use the gnus
machinery. I also understand that Outlook doesn’t correctly interprete
some standard flags. Indeed the forwarded parts display just fine in Gmail for instance.

My company uses Outlook. I often need to forward mails to colleagues,
who then complain that they get them as .htm attachments. As this only
happens when they get email from me, I can’t really convince them that
it’s Outlook’s fault.

I have tried with message-forward-as-mime set to t or nil : the
forwarded part always appears attached.

Has anyone achieved forwarding emails with mu 1.12.8 and the forwarded
part being shown inline in Outlook?

Best,
Victor

Dirk-Jan C. Binnema

unread,
Feb 7, 2025, 7:06:25 AMFeb 7
to mu-di...@googlegroups.com
Hi,

On Tuesday Feb 04 2025, Victor A. Stoichita wrote:

> When I forward an email to my contacts who use Outlook, they get the
> forwarded part as an attachment.
> In previous versions of mu4e, the forwarded part used to be inlined.
>
> I understand that this is not related to mu4e, since we now use the gnus
> machinery. I also understand that Outlook doesn’t correctly interprete
> some standard flags. Indeed the forwarded parts display just fine in Gmail for instance.
>
> My company uses Outlook. I often need to forward mails to colleagues,
> who then complain that they get them as .htm attachments. As this only
> happens when they get email from me, I can’t really convince them that
> it’s Outlook’s fault.

Don't think mu4e/gnus create ".htm" attachments.

> I have tried with message-forward-as-mime set to t or nil : the
> forwarded part always appears attached.

That's surprising. At the very least I'd expect some _different_ result.
Do the results look as expected in mu4e / other clients?

> Has anyone achieved forwarding emails with mu 1.12.8 and the forwarded
> part being shown inline in Outlook?

We have a ticket for Office365 forwarding,
https://github.com/djcb/mu/issues/2808

which is perhaps related; it seems the mail-server does something to the
message, and what recipient gets is not quite what you were sending.

You could create the simplest possible (text-only) "hello world"
message, and forward to yourself, then check what the mail-server made
of it, and carefully check the headers etc.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Jeroen Tiebout

unread,
Feb 7, 2025, 1:56:05 PMFeb 7
to mu-di...@googlegroups.com
I forwarded this message (from mu4e 1.12.8) to my work address (on outlook 365) and it shows up as expected, inline.
FWIW..
--
Jeroen Tiebout

Victor A. Stoichita

unread,
Feb 14, 2025, 5:09:59 PMFeb 14
to mu-di...@googlegroups.com
Thanks for your replies!

I tried again with the simplest text message: I send the word "Blue" to
myself, then I forward the received message to my professional address,
without adding anything to it.

With (setq message-forward-as-mime t) the forwarded part looks like
this [here and below I doubled the # into ## to avoid quoted tags like <##mml>
being interpreted in this message to the list]:

--8<---------------cut here---------------start------------->8---

<##mml type=message/rfc822 disposition=inline>
From: "Victor A. Stoichita" <svi...@svictor.net>
To: "Victor A. Stoichita" <svi...@svictor.net>
Subject: orange

Blue
<##/mml>
--8<---------------cut here---------------end--------------->8---

And the raw forwaded message looks like this :

--8<---------------cut here---------------start------------->8---
From: "Victor A. Stoichita" <svi...@svictor.net>
To: "Victor A. Stoichita" <victor.s...@cnrs.fr>
Subject: Fwd: orange
References: <87jz9sn...@svictor.net>
User-Agent: mu4e 1.12.8; emacs 30.0.93
Message-ID: <87ed00n...@svictor.net>
MIME-Version: 1.0
Content-Type: message/rfc822
Content-Disposition: inline

From: "Victor A. Stoichita" <svi...@svictor.net>
To: "Victor A. Stoichita" <svi...@svictor.net>
Subject: orange
MIME-Version: 1.0
Content-Type: text/plain

Blue
--8<---------------cut here---------------end--------------->8---


In my company’s webmail, even this text/plain forwarded message is
displayed as an attachment.

I gather from your replies and tests that my company’s server has an
idiosyncrasy of its own that transforms the mml part into an attachment,
no matter what "disposition=inline" says.

There’s no chance to convince the IT staff to solve my problem as it’s
a big national research institute and this happens only to my
emails. I suspect that gnus tries to be semantically correct, while other
clients simply paste the contents of the forwarded message. This is what
mu4e used to do as well before relying on gnus. And it’s still what gnus
does when we reply to an email. I’d like to get that behavior back when
forwarding emails as well.

I tried with (setq message-forward-as-mime nil). This works fine if
I forward only text messages. In that case, the forwarded message is all
plain text.

But if I forward a message that has text and html parts, then gnus tries
to be correct again and includes both in the forward. For instance,
I write the words *bold yellow* in mu4e, I htmlize it and I send it to myself.
I receive a multipart message. Then I forward it to my business
address, adding simply the word "black". The message then looks like
this:

--8<---------------cut here---------------start------------->8---
To: "Victor A. Stoichita" <victor.s...@cnrs.fr>
Subject: Fwd: green
From: "Victor A. Stoichita" <svi...@svictor.net>
Message-ID: <87o6z4m...@svictor.net>

black
-------------------- Start of forwarded message --------------------
From: "Victor A. Stoichita" <svi...@svictor.net>
To: Victor A. Stoichita <svi...@svictor.net>
Subject: green

<##multipart type=alternative>
<##part type=text/plain disposition=inline nofile=yes>
*bold yellow*
<##part type=text/html nofile=yes>
<p>
<b>bold yellow</b>
</p>
<##/multipart>
-------------------- End of forwarded message --------------------

--8<---------------cut here---------------end--------------->8---

Outlook makes a mess of this, as you can see in the attached screenshot.
The message up to "<##multipart …" is dispayed inline. The rest
appears as 3 attachments.
1. the text/plain "*bold yellow*" in ATT00001.txt
2. the html part with the words "bold yellow" written in bold in ATT00002.htm
3. the text/plain "--- End of forwarded message---" in ATT00003.txt

This is worse than anything for my collaborators since they now get
an incomplete message and 3 files to deal with.

Is there a straightforward way in mu4e/gnus to get the "reply" behavior also
when we forward an email? That is: to include the contents of the forwarded
message as if it were a replied message (no mml, no multipart, just
plain text)?

Sorry for the long mail, and thanks for reading this far!

Victor
Screenshot From 2025-02-14 22-38-50.png

Jeroen Tiebout

unread,
Feb 14, 2025, 7:36:33 PMFeb 14
to mu-di...@googlegroups.com
Well... that's interesting.
I forwarded your latest mail (the one I'm replying to here) to my work o365 address and yes, I get the same behavior as in your screenshot.
2 txt files attached (plus your screenshot) with the actual body being of no real help.

Can't offer much of a solution but willing to help test or verify if you tell me what to do :)
Good luck!

Jeroen
--
Jeroen Tiebout

Jeroen Tiebout

unread,
Feb 14, 2025, 7:40:14 PMFeb 14
to mu-di...@googlegroups.com
Oh wait...
Your latest message also shows contents as some kind of txt attachments in mu4e, it just does it more elegantly than outlook.
And when I reply the content of the attachment is nicely put inline (as you can see below).
Weird stuff...

Sorry for the spam without really helping.

On Friday 2025-02-14 23:07:04 +01, "Victor A. Stoichita" <vic...@svictor.net> wrote:

--
Jeroen Tiebout

Dirk-Jan C. Binnema

unread,
Feb 15, 2025, 4:47:18 AMFeb 15
to mu-di...@googlegroups.com
Hi Victor,
Thanks for experimenting with this!

The gnus model has two main variables,

message-forward-as-mime
message-forward-show-mml

`gnus-summary-mail-forward' documents their meaning:

if ARG is nil, see `message-forward-as-mime' and `message-forward-show-mml';
if ARG is 1, decode the message and forward directly inline;
if ARG is 2, forward message as an rfc822 MIME section;
if ARG is 3, decode message and forward as an rfc822 MIME section;
if ARG is 4, forward message directly inline;
otherwise, use negated `message-forward-as-mime'.

Which is handled as:
--8<---------------cut here---------------start------------->8---
((eq arg 1)
(setq message-forward-as-mime nil
message-forward-show-mml t))
((eq arg 2)
(setq message-forward-as-mime t
message-forward-show-mml nil))
((eq arg 3)
(setq message-forward-as-mime t
message-forward-show-mml t))
((eq arg 4)
(setq message-forward-as-mime nil
message-forward-show-mml nil))
(t
(setq message-forward-as-mime (not message-forward-as-mime))))
--8<---------------cut here---------------end--------------->8---

So even option "4" still doesn't get the desired results, or at least
not with non-plain-text messages?

If so, guess we should ask the Gnus folks. It seems the kind of Big Mail
Server behavior isn't so uncommon and more people must have run into it.

Kind Regards,

Victor A. Stoichita

unread,
Feb 20, 2025, 10:47:03 AMFeb 20
to Dirk-Jan C. Binnema, mu-di...@googlegroups.com
Hi Dirk-Jan,
Thanks for these explanations!
And thanks also to Jeroen for confirming that it’s not just my company’s
server that does weird things.

Can we test directly with ‘gnus-summary-mail-forward’? When I invoke it
on an email, it says "this is a pseudo-article" and nothing happens.

I admit being confused about gnus. I read carefully the ‘mu’
documentation when I started using it some years ago and tried to keep
up with the changes ever since. When 'mu' switched to using gnus I tried
to look into it as well but was defeated by its rather huge manual
(https://www.gnus.org/manual/big-gnus.html). I couldn’t determine what
was relevant for mu4e.

Could you or someone else please recommend what to read to understand
the behavior of gnus in mu4e context? For instance, what applies to
’pseudo-articles’ (if indeed all mail in mu4e is a pseudo-article in
gnus sense)?

Regards,
Victor

Dirk-Jan C. Binnema

unread,
Feb 20, 2025, 12:03:32 PMFeb 20
to mu-di...@googlegroups.com
Hi Victor,
But did you try those 4 options? In particular #4?

I.e., (setq message-forward-as-mime nil
message-forward-show-mml nil)

> Can we test directly with ‘gnus-summary-mail-forward’? When I invoke it
> on an email, it says "this is a pseudo-article" and nothing happens.
>
> I admit being confused about gnus. I read carefully the ‘mu’
> documentation when I started using it some years ago and tried to keep
> up with the changes ever since. When 'mu' switched to using gnus I tried
> to look into it as well but was defeated by its rather huge manual
> (https://www.gnus.org/manual/big-gnus.html). I couldn’t determine what
> was relevant for mu4e.
>
> Could you or someone else please recommend what to read to understand
> the behavior of gnus in mu4e context? For instance, what applies to
> ’pseudo-articles’ (if indeed all mail in mu4e is a pseudo-article in
> gnus sense)?

Mu4e piggy-backs on Gnus' code, but you can't expect random gnus-
functions to work in when using mu4e. The "pseudo articles" are one
symptom of that...

If you want to play with Gnus, I'd recommend setting it up, even if it
can be a little daunting.

When it comes to forwarding messages, mu4e offers exactly what gnus
offers; so playing a bit with those options and seeing if there's a
working combination might be useful.

Kind regards,
Message has been deleted

Ramon Diaz-Uriarte

unread,
Feb 21, 2025, 7:26:43 AMFeb 21
to Dirk-Jan C. Binnema, mu-di...@googlegroups.com
Hi Dirk and Victor,

(Apologies: I deleted my message from the google groups list a moment ago because of formatting issues. Here I go again, in a simpler version).

I experience behavior similar to the one reported by Victor. Some experiments below.
I've tried all four settings. Option 4 does not solve it for me (none of the others do, either). With Option 4 the forwarded message is attached as an html file, but apparently cannot be read from the message itself (see first attachment, image-a.png).


Details:

In outlook I wrote an HTML message. In mu4e (but same account) I wrote a text message. I sent them to the email with the outlook account. And, from mu4e, I forwarded them to that same original account and a few others.

The problematic service is outlook; mu4e, gmail's web interface and roundcube all work fine. (Option 2 does not work for me also because of accents, though I understand this is a different issue);

Option 1:
Txt: OK
HMTL: Cut, htm attach

Option 2:
Txt: Outlook item
HTML: Outlook item.

Option 3:
Txt: Outlook item
HTML: Outlook item (see attachment image-oi.png)

Option 4:
Txt: OK
HTML: Cut, htm attach


Legend:

OK: You can read the text directly.

"Outlook item": The forwarded message displays as a clickable "Outlook Item" which opens a window from outlook itself. But the contents are not displayed in the messsage.

Cut, htm attach: the forwarded message is included as an attachment (ATTzzzzzz.htm). It seems that, from outlooks interface, users would have to download and open the file outside of outlook.

In daily use, my default is option 1. What I do if I suspect the recipient uses outlook is often to hit reply, instead of forward, or to copy the relevant parts above the "forwarded message".


Best,

R.



--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-31
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdi...@gmail.com
r.d...@uam.es
ramon...@iib.uam.es

https://ligarto.org/rdiaz


image-a.png
image-oi.png

Victor A. Stoichita

unread,
Feb 28, 2025, 3:34:42 AMFeb 28
to Ramon Diaz-Uriarte, Dirk-Jan C. Binnema, mu-di...@googlegroups.com
Thanks for testing this methodically, Ramon!

Le 21 Feb 2025, Ramon Diaz-Uriarte <rdi...@gmail.com> a écrit :

> In daily use, my default is option 1. What I do if I suspect the recipient uses outlook is often to hit reply, instead of forward, or to copy the relevant parts above the "forwarded message".

This is also what I would do. I know one other mu user (not on this list
I think), who works in a different university that uses Outlook, and
this is also what he does: forwards by hitting reply and then changes
the address.

Anonther more general issue with how gnus forwards messages is when we
need to add html text to the forward. In the academy for instance, when
we mention a booktitle, we should italicize it, by convention.

This works fine with ’org-mime-htmlize’. But 'org-mime-htmlize' makes
a mess of the forwarded part as generated by the gnus forward system.
If the forwarded text is generated by the reply system instead, then the
result is more predictable.
This issue is not Outlook related. But I see it as an additional
incentive to streamline the process of pre-composing the forward buffer
the "reply" way. (I have wanted to look into this, but time has been
lacking so far.)

Blue skies,
Victor

Ramon Diaz-Uriarte

unread,
Mar 5, 2025, 6:20:44 AMMar 5
to Victor A. Stoichita, Dirk-Jan C. Binnema, mu-di...@googlegroups.com


On Fri, 28-February-2025, at 09:33:51, "Victor A. Stoichita" <vic...@svictor.net> wrote:
> Thanks for testing this methodically, Ramon!
>
> Le 21 Feb 2025, Ramon Diaz-Uriarte <rdi...@gmail.com> a écrit :
>
>> In daily use, my default is option 1. What I do if I suspect the recipient uses outlook is often to hit reply, instead of forward, or to copy the relevant parts above the "forwarded message".
>
> This is also what I would do. I know one other mu user (not on this list
> I think), who works in a different university that uses Outlook, and
> this is also what he does: forwards by hitting reply and then changes
> the address.

Good to know several of us are using the same workaround :-)

>
> Anonther more general issue with how gnus forwards messages is when we
> need to add html text to the forward. In the academy for instance, when
> we mention a booktitle, we should italicize it, by convention.
>

I never add (at least consciously) any html to the messages I write; when I need italics or other formatting, I do that via attachments (latex or whatever). In the email message itself if book title is not in italics ... well, so be it .

Best,

R.

> This works fine with ’org-mime-htmlize’. But 'org-mime-htmlize' makes
> a mess of the forwarded part as generated by the gnus forward system.
> If the forwarded text is generated by the reply system instead, then the
> result is more predictable.
> This issue is not Outlook related. But I see it as an additional
> incentive to streamline the process of pre-composing the forward buffer
> the "reply" way. (I have wanted to look into this, but time has been
> lacking so far.)
>
> Blue skies,
> Victor

Henrik Frisk

unread,
Apr 6, 2025, 6:09:18 AMApr 6
to mu-di...@googlegroups.com, Victor A. Stoichita, Dirk-Jan C. Binnema
Den ons 5 mars 2025 kl 12:20 skrev Ramon Diaz-Uriarte <rdi...@gmail.com>:


On Fri, 28-February-2025, at 09:33:51, "Victor A. Stoichita" <vic...@svictor.net> wrote:
> Thanks for testing this methodically, Ramon!
>
> Le 21 Feb 2025, Ramon Diaz-Uriarte <rdi...@gmail.com> a écrit :
>
>> In daily use, my default is option 1. What I do if I suspect the recipient uses outlook is often to hit reply, instead of forward, or to copy the relevant parts above the "forwarded message".
>
> This is also what I would do. I know one other mu user (not on this list
> I think), who works in a different university that uses Outlook, and
> this is also what he does: forwards by hitting reply and then changes
> the address.

Good to know several of us are using the same workaround :-)
 
A little late on this thread, but I'm having the same problem as described here: An email forwarded to an Outlook account ends up as an attachment

best,
Henrik
Reply all
Reply to author
Forward
0 new messages