notmuch-emacs: forward messages inline

notmuch-emacs: forward messages inline

[Matthew Lear]

Hi all. Are there any recommended ways to selectively forward an email as inline with notmuch-emacs rather than as an RFC822 attachment, eg have a new shortcut key that can be used for this purpose in addition to f? I have toggled one of the mml configuration variables (I forget exactly what it was) which switched the forwarding method to inline (ACAICT this also removed the ability of being able to forward as RFC822), but it also included various header information in the body of the email. Not good.
I was wondering if any of you have such lisp-fu in your .emacs, or have any thoughts on how one could go about going this through a custom key binding.
Cheers,
  Matt


 

Re: notmuch-emacs: forward messages inline

[Daniel Kahn Gillmor]

Hi Matt--

On Fri 2015-11-06 04:51:53 +0900, Matthew Lear wrote:
> Are there any recommended ways to selectively forward an email as
> inline with notmuch-emacs rather than as an RFC822 attachment, eg have
> a new shortcut key that can be used for this purpose in addition to f?
> I have toggled one of the mml configuration variables (I forget
> exactly what it was) which switched the forwarding method to inline
> (ACAICT this also removed the ability of being able to forward as
> RFC822), but it also included various header information in the body
> of the email. Not good.

I suppose you could reply to the message (r) and just change the
addresses, which would include the previous message "inline".  If you
don't like that it leaks the previous message-id in the In-Reply-To and
References headers, you can just kill them from the buffer manually.

But can i ask why you'd want this?  forwarded messages as RFC 822
attachments are significantly more sane for any MUA to deal with.

            --dkg

Re: notmuch-emacs: forward messages inline

[Suvayu Ali]

On Fri, Nov 06, 2015 at 06:42:26AM +0900, Daniel Kahn Gillmor wrote:
> 
> But can i ask why you'd want this?  forwarded messages as RFC 822
> attachments are significantly more sane for any MUA to deal with.

I'm not the OP, but often I prefer this over forwarding as attachments.
I find it useful when I only want to forward specific bits of an email.
Rather than sending the whole message (which often has lots of quoted
text from earlier in the thread), I can easily edit the message as
needed.  I guess this is functionally similar to your "reply and edit"
suggestion.

-- 
Suvayu

Open source is the future. It sets us free.

Re: notmuch-emacs: forward messages inline

[Matthew Lear]

Hi Daniel,

> On 5 Nov 2015, at 21:42, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>> On Fri 2015-11-06 04:51:53 +0900, Matthew Lear wrote:
>> Are there any recommended ways to selectively forward an email as
>> inline with notmuch-emacs rather than as an RFC822 attachment, eg have
>> a new shortcut key that can be used for this purpose in addition to f?
>> I have toggled one of the mml configuration variables (I forget
>> exactly what it was) which switched the forwarding method to inline
>> (ACAICT this also removed the ability of being able to forward as
>> RFC822), but it also included various header information in the body
>> of the email. Not good.
> 
> I suppose you could reply to the message (r) and just change the
> addresses, which would include the previous message "inline".  If you
> don't like that it leaks the previous message-id in the In-Reply-To and
> References headers, you can just kill them from the buffer manually.

I guess that's one way, but it's a bit of a faff. Unless it was possible to wrap
it all up in lisp, I don't really think it's a good option.

> But can i ask why you'd want this?  forwarded messages as RFC 822
> attachments are significantly more sane for any MUA to deal with.

No arguments on the 'being sane' front, although I have seen
notmuch-emacs fail to correctly formulate an RFC822 attachment of the
original email message a few times. I suspect this was due to MS Outlook
formatting but can't be sure, though. My main use of notmuch is at work
where I have to handle large amounts of email such as bug notifications from
a couple of systems, messages to/from lists, auto generated stuff for tracking,
plus the usual reams of corporate email from teams and colleagues. Notmuch
allows me to handle this fantastically. A common use case of forwarding
messages inline is to take an email already received, and send it onto
colleagues. It's not uncommon for this to initiate a new thread of conversation
and other people could be added to the thread as appropriate. If I were to
forward a message I received as an RFC822 attachment, in order for the
conversation to be coherent and contained in the text when other people were
added to the thread, the email containing my attachment would need to be
forwarded to (additional) recipients because 'replying to all' and including new
recipients wouldn't contain the original message. As I see it, to be able to
forward and include people starting a new thread based on the forwarded
message, it needs to be inline. Make sense?
--  Matt 

Re: notmuch-emacs: forward messages inline

[Daniel Kahn Gillmor]

On Fri 2015-11-06 14:23:22 -0500, Matthew Lear wrote:
> I guess that's one way, but it's a bit of a faff. Unless it was possible to wrap
> it all up in lisp, I don't really think it's a good option.

It seems to be specifically what you're looking to do, so i don't see it
as a "faff" but *shrug*

> No arguments on the 'being sane' front, although I have seen
> notmuch-emacs fail to correctly formulate an RFC822 attachment of the
> original email message a few times. I suspect this was due to MS Outlook
> formatting but can't be sure, though.

If you have a repeatable use case, please report it.  I would expect
that "inline forwarding" would be much *more* likely to formulate the
message incorrectly, since it would involve re-flowing text, etc.
rfc822/message-style forwarding is just an unfiltered byte-dump as a
part inside a newly-composed message.

> My main use of notmuch is at work where I have to handle large amounts
> of email such as bug notifications from a couple of systems, messages
> to/from lists, auto generated stuff for tracking, plus the usual reams
> of corporate email from teams and colleagues. Notmuch allows me to
> handle this fantastically.

great! :)

> A common use case of forwarding messages inline is to take an email
> already received, and send it onto colleagues. It's not uncommon for
> this to initiate a new thread of conversation and other people could
> be added to the thread as appropriate. If I were to forward a message
> I received as an RFC822 attachment, in order for the conversation to
> be coherent and contained in the text when other people were added to
> the thread, the email containing my attachment would need to be
> forwarded to (additional) recipients because 'replying to all' and
> including new recipients wouldn't contain the original message.

It sounds like you're saying you'd like to have a reply mode that
includes attachments as well.  is that right?  Or when replying, you'd
like to have a per-attachment option to go ahead and re-include it?

fwiw, i'd also like to be able to forward entire threads directly from
notmuch, instead of having to forward only one message at a time.

> As I see it, to be able to forward and include people starting a new
> thread based on the forwarded message, it needs to be inline. Make
> sense?

Hm, this kind of forwarding usually results in reverse-chronological
ordering, which i find impossible to read effectively, particularly when
i'm jumping into the middle of it.  Also, if the original message itself
contains attachments, it doesn't forward those attachments effectively.
right?

It'd be nice to be able to bounce the relevant messages to the new
recipient (e.g. "| /usr/sbin/sendmail foo@example.com") and then follow
up with In-Reply-To and References set properly, all in one clean
action.  But depending on the age of the original message and the
dmarc/anti-spam policies of the domains of the original author and the
new recipient, i can imagine that the original message might not make it
through, even if the followup would.

I hear you that it sounds like we're missing something to cleanly handle
the real-world workflow you describe, but i don't think
inline-forwarding is it.

        --dkg

Re: notmuch-emacs: forward messages inline

[Mark Walters]

Hi

Does adding something like the following to your .emacs file do what you want?


(defun my-forward (prefix)
  (interactive "P")
  (let ((message-forward-as-mime nil)
	(message-forward-ignored-headers ".*"))
    (notmuch-show-forward-message prefix)))

(define-key notmuch-show-mode-map "F" 'my-forward)

Then "F" should forward the message as a plain message rather than
rfc822, and there should not be any spurious headers.

Best wishes

Mark



On Fri, 06 Nov 2015, Matthew Lear <matt@bubblegen.co.uk> wrote:
> Hi Daniel,
>
>> On 5 Nov 2015, at 21:42, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>>> On Fri 2015-11-06 04:51:53 +0900, Matthew Lear wrote:
>>> Are there any recommended ways to selectively forward an email as
>>> inline with notmuch-emacs rather than as an RFC822 attachment, eg have
>>> a new shortcut key that can be used for this purpose in addition to f?
>>> I have toggled one of the mml configuration variables (I forget
>>> exactly what it was) which switched the forwarding method to inline
>>> (ACAICT this also removed the ability of being able to forward as
>>> RFC822), but it also included various header information in the body
>>> of the email. Not good.
>> 
>> I suppose you could reply to the message (r) and just change the
>> addresses, which would include the previous message "inline".  If you
>> don't like that it leaks the previous message-id in the In-Reply-To and
>> References headers, you can just kill them from the buffer manually.
>
> I guess that's one way, but it's a bit of a faff. Unless it was possible to wrap
> it all up in lisp, I don't really think it's a good option.
>
>> But can i ask why you'd want this?  forwarded messages as RFC 822
>> attachments are significantly more sane for any MUA to deal with.
>
> No arguments on the 'being sane' front, although I have seen
> notmuch-emacs fail to correctly formulate an RFC822 attachment of the
> original email message a few times. I suspect this was due to MS Outlook
> formatting but can't be sure, though. My main use of notmuch is at work
> where I have to handle large amounts of email such as bug notifications from
> a couple of systems, messages to/from lists, auto generated stuff for tracking,
> plus the usual reams of corporate email from teams and colleagues. Notmuch
> allows me to handle this fantastically. A common use case of forwarding
> messages inline is to take an email already received, and send it onto
> colleagues. It's not uncommon for this to initiate a new thread of conversation
> and other people could be added to the thread as appropriate. If I were to
> forward a message I received as an RFC822 attachment, in order for the
> conversation to be coherent and contained in the text when other people were
> added to the thread, the email containing my attachment would need to be
> forwarded to (additional) recipients because 'replying to all' and including new
> recipients wouldn't contain the original message. As I see it, to be able to
> forward and include people starting a new thread based on the forwarded
> message, it needs to be inline. Make sense?
> --  Matt 
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch-emacs: forward messages inline

[Matthew Lear]

>
> Hi
>
> Does adding something like the following to your .emacs file do what you
> want?
>
>
> (defun my-forward (prefix)
>   (interactive "P")
>   (let ((message-forward-as-mime nil)
> 	(message-forward-ignored-headers ".*"))
>     (notmuch-show-forward-message prefix)))
>
> (define-key notmuch-show-mode-map "F" 'my-forward)
>
> Then "F" should forward the message as a plain message rather than
> rfc822, and there should not be any spurious headers.

Hi Mark. Yes, thanks. For plain text emails this is perfect in that it
gives me what I want (and I can customise the start/end of forwarded
message separators). For messages with text and html versions of the body
it is less ideal because it generates an email with three attachments -
one with the plain text of the message body, one with the html of the
message body and one that just contains the 'end of forwarded message'
separator. I'd prefer that the plain text message body was included inline
and that the html portion was the only attachment in this case. Is this
possible?
--  Matt