From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 8506F6DE01EA for ; Fri, 6 Nov 2015 15:48:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJDg9xACtSam for ; Fri, 6 Nov 2015 15:48:27 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by arlo.cworth.org (Postfix) with ESMTP id 74CEE6DE1502 for ; Fri, 6 Nov 2015 15:48:27 -0800 (PST) Received: from fifthhorseman.net (unknown [209.226.201.248]) by che.mayfirst.org (Postfix) with ESMTPSA id 8EC5AF984; Fri, 6 Nov 2015 18:48:25 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A10ED1FFE4; Fri, 6 Nov 2015 18:48:24 -0500 (EST) From: Daniel Kahn Gillmor To: Matthew Lear Cc: "notmuch\@notmuchmail.org" Subject: Re: notmuch-emacs: forward messages inline In-Reply-To: <847CC903-FE82-49B4-A3D6-1070D58BF2F3@bubblegen.co.uk> References: <430FC760-8BF5-4798-89B5-E7F2A16564B7@bubblegen.co.uk> <87h9l0qg1p.fsf@alice.fifthhorseman.net> <847CC903-FE82-49B4-A3D6-1070D58BF2F3@bubblegen.co.uk> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 06 Nov 2015 18:48:24 -0500 Message-ID: <87wptubsfr.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 23:48:29 -0000 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