Feature request: forwarding of all an email's attachments
In my experience, coming from GUI MUAs, when a user tells an MUA to forward (not "bounce", nor "resend") a message, that MUA should, without further prompting, do all of the following:
- Create a draft new message.
- Per RFC: RFC 5322 (more or less).
- GUI MUAs do this? Yes.
- Mutt does this? Yes.
- Copy the original message body and selected headers into the new message's body, with a delimiter to make it clear where the original message starts (and, ideally, a second delimiter to show where it ends).
- Per RFC: RFC 5322 (more or less).
- GUI MUAs do this? Yes.
- Mutt does this? Yes.
- Set that new message's In-Reply-To header field to have the value of the original message's Message-ID field.
- Per RFC: N/A (unless one interprets "reply" to include "forward", in which case 5322).
- GUI MUAs do this? Yes.
- Mutt does this? Yes.
- Set that new message's References header field to include the value of the original message's Message-ID field.
- Per RFC: N/A (unless one interprets "reply" to include "forward", in which case 5322).
- GUI MUAs do this? Yes.
- Mutt does this? Yes.
- Set the draft new message's "Subject:" line to "Fwd: ORIGINALSUBJECT".
- Per RFC: 5256.
- GUI MUAs do this? Yes.
- Mutt does this? Yes.
- Move the cursor to the body of the draft new message, above the opening delimiter for the original message, so that the user can immediately add a prefatory remark, if desired.
- Per RFC: N/A.
- GUI MUAs do this? Yes.
- Mutt does this? Yes.
- Attach all of the original message's attachments to the draft new message.
- Per RFC: N/A.
- GUI MUAs do this? Yes.
- Mutt does this? No.
The divergence between Mutt and more common MUAs, on the last point, currently requires the user to follow a multi-step workaround every time the user wants to forward a message with attachmants:
- View the original message,
- then invoke
<view-attachments>
, - then manually tag all the attachments,
- then invoke
<tag-prefix>
, - then invoke
<forward-message>
.
Unfortunately, this workaround is prone to human error (such as failing to tag all of the attachments) and moreover, it cannot currently be readily automated (e.g. turned into a macro), because <tag-pattern>
does not work in the Attachment Menu.
Mutt's current inability to behave according to the list at the top of this feature request is, unfortunately: an ergonomic annoyance that Mutt users must bear until its behaviour is improved in that respect; a barrier to adoption (a "pain point") for would-be Mutt users who expect GUI MUA-like behaviour; and an impediment to developing useful macros that depend upon being able to tag all of a message's attachments.
So, I humbly ask that Mutt be made capable of being configured to behave as described in the list at the top of this feature request, when the user invokes <forward-message>
. Ideally, as part of that work, <tag-pattern>
should be extended to work in the Attachment Menu. As a possible addition, a new configuration parameter might be introduced, called <forward-all-attachments>
or suchlike, which should probably be a quad-option set to "ask-yes" by default, and which would cause <forward-message>
to behave as though the user had performed the multi-step workaround described above.
P.S. In response to the question of how to forward all of a message's attachments, people on forums or mailing lists sometimes suggest workarounds that are no more appropriate (probably even less so) than the multi-step workaround described above. Here are a few of them, and their shortcomings, to forestall their being raised in response to this feature request:
- Set
mime-forward
to "yes" in .muttrc, then invoke<forward-message>
. (Shortcoming: sends original body as an attachment, where it is not immediately available to view, rather than in the body where it is immediately visible. Mainstream GUI clients haven't done this since the 1990s, probably because it was found to be unergonomic.) - Invoke
<resend-message>
. (Likely requires the "From:" and perhaps other headers to be manually adjusted. Does not delimit original message clearly. Does not set Subject correctly. Perhaps does not set References or In-Reply-To correctly.) - Invoke
<bounce-message>
. (Does not provide an opportunity to add any prefatory remarks.) - Write a macro that pipes the original message and its attachments to a pipeline of utilities (e.g. a wrapper around Courier-MTA's
mailbot
andreformail
) that will reformat them appropriately, and then pipe the resulting message into a new Mutt invocation as a draft message. (Overly complex: implementing this is probably beyond the average user. Also prone to break if future versions of the utilities change their invocation syntaxes.)
P.P.S. In the list at the top of this feature request, I am somewhat generalising about GUI MUAs. Undoubtedly there have been GUI MUAs that did not act behave as described.