forward messages inline for Outlook?

[Victor A. Stoichita]

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]

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]

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]

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

[Jeroen Tiebout]

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]

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]

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]

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]

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,

[Ramon Diaz-Uriarte]

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

[Victor A. Stoichita]

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]

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]

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

[Ben Maughan]

I am resurrecting this old thread to report that (with the help of Claude) I have got a solution to this problem, using org-msg. Here are the notes that I put together with Claude's help. I'm pasting markdown so I'm not sure how it will look. I've extracted this from my more complicated mu4e setup so I've not tested it in isolation but I think it will work. Please test carefully before using for anything important!

## The fix

The solution reuses org-msg's reply machinery for forwards. When composing a
reply, org-msg exports the parent email's HTML to a temp file, stores it in the
`:reply-to` property, and at send time merges your composed text directly into
the original HTML DOM — producing a single `text/html` part with no MIME
wrapping. This is why replies display correctly in Outlook.

The fix intercepts the forward compose buffer after org-msg has finished its
setup, exports the parent HTML using the same reply mechanism, strips the
gnus-generated forward block from the buffer body, and sets `:reply-to` so
org-msg treats the forward exactly like a reply at send time.

## Requirements

- mu4e
- [org-msg](https://github.com/jeremy-compostella/org-msg)

## org-msg configuration

A working org-msg configuration compatible with this fix. The key settings are
`org-msg-default-alternatives` (which controls whether HTML is generated for
new messages, replies to HTML, and replies to plain text) and
`org-msg-convert-citation` (which styles quoted text).

```elisp
(use-package org-msg
  :after (org mu4e)
  :config
  ;; set mu4e as email agent
  (setq mail-user-agent 'mu4e-user-agent)
  (setq org-msg-options "html-postamble:nil H:5 num:nil ^:{} toc:nil author:nil email:nil \\n:t"
        org-msg-startup "hidestars indent inlineimages"
        org-msg-greeting-fmt nil
        org-msg-greeting-name-limit 1      ; use first name only
        org-msg-default-alternatives '((new           . (text html))
                                       (reply-to-html . (text html))
                                       (reply-to-text . (text)))
        org-msg-convert-citation t         ; style quoted text nicely
        org-msg-signature
        "
#+begin_signature
--
Your signature here
#+end_signature")

  ;; Key bindings in the org-msg compose buffer
  ;; send
  (define-key org-msg-edit-mode-map (kbd "C-c C-c") #'org-msg-ctrl-c-ctrl-c)
  ;; save as draft
  (define-key org-msg-edit-mode-map (kbd "C-c C-d") #'message-dont-send)

  (org-msg-mode))
```

## Implementation

Add the following to your Emacs config after org-msg is loaded:

```elisp
(defun my/org-msg-fix-forward ()
  "For HTML forwards, replace the gnus MML block with an org-msg reply-to.
This causes org-msg to merge the forwarded content directly into the
HTML body at send time, so Outlook displays it inline rather than as
an attachment."
  (when (and (eq mu4e-compose-type 'forward)
             (eq major-mode 'org-msg-edit-mode)
             (org-msg-mua-call 'article-htmlp))
    (let ((reply-to-files (org-msg-save-article-for-reply-mu4e)))
      (when reply-to-files
        (when (bound-and-true-p org-appear-mode)
          (org-appear-mode -1))
        ;; Delete the gnus forward block between the start/end banners,
        ;; leaving the org-msg options, properties, and signature intact.
        (save-excursion
          (goto-char (point-min))
          (when (re-search-forward
                 "^-+ Start of forwarded message -+$" nil t)
            (let ((start (line-beginning-position)))
              (when (re-search-forward
                     "^-+ End of forwarded message -+$" nil t)
                (delete-region start (1+ (line-end-position)))))))
        (org-msg-set-prop "reply-to" reply-to-files)
        (setq mml-content-disposition-alist
              (append (org-msg--mml-content-disposition-alist)
                      mml-content-disposition-alist))
        (when (bound-and-true-p org-appear-mode)
          (org-appear-mode 1))))))

;; Depth 10 ensures this runs after org-msg-post-setup.
(add-hook 'mu4e-compose-mode-hook #'my/org-msg-fix-forward 10)
```

### With mu4e-send-delay

If you are using
[mu4e-send-delay](https://github.com/krisbalintona/mu4e-send-delay)
then some modifications to that package are needed for compatibility
with this. Let me know if this is of interest.

## How it works

1. `mu4e-compose-forward` opens the compose buffer and runs
   `mu4e-compose-mode-hook`.
2. `org-msg-post-setup` (depth 0) activates `org-msg-edit-mode` and inserts the
   org-msg options, properties block, and signature. The gnus-generated forward
   block (text + HTML MIME parts wrapped in start/end banners) is left in the
   buffer body below the signature.
3. `my/org-msg-fix-forward` (depth 10) runs after org-msg setup is complete. It
   calls `org-msg-save-article-for-reply-mu4e` to export the parent email's HTML
   to a temp file, deletes the gnus forward block from the buffer, and sets the
   `:reply-to` property to the exported HTML path.
4. At send time, `org-msg-prepare-to-send` sees `:reply-to` set and calls
   `org-msg-build`, which parses the exported HTML and merges your composed text
   above it in a single `text/html` part — identical to how a reply is
   constructed. No `message/rfc822` wrapping, no attachment.

## Notes

- This only applies to forwards of HTML emails. Plain-text forwards are
  unaffected (`org-msg-mua-call 'article-htmlp` returns nil and the function
  exits early).
- If you use `org-appear-mode`, it is briefly disabled and re-enabled during
  setup to avoid a harmless but noisy `args-out-of-range` error caused by buffer
  contents changing while org-appear's post-command hook is running.
- The forwarded email's content appears in the sent message exactly as it would
  in a reply — the original HTML is preserved and displayed inline by Outlook
  and other clients.