--- /dev/null
+Return-Path: <dkg@fifthhorseman.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 8506F6DE01EA\r
+ for <notmuch@notmuchmail.org>; Fri, 6 Nov 2015 15:48:29 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+ autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id LJDg9xACtSam for <notmuch@notmuchmail.org>;\r
+ Fri, 6 Nov 2015 15:48:27 -0800 (PST)\r
+Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 74CEE6DE1502\r
+ for <notmuch@notmuchmail.org>; Fri, 6 Nov 2015 15:48:27 -0800 (PST)\r
+Received: from fifthhorseman.net (unknown [209.226.201.248])\r
+ by che.mayfirst.org (Postfix) with ESMTPSA id 8EC5AF984;\r
+ Fri, 6 Nov 2015 18:48:25 -0500 (EST)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id A10ED1FFE4; Fri, 6 Nov 2015 18:48:24 -0500 (EST)\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+To: Matthew Lear <matt@bubblegen.co.uk>\r
+Cc: "notmuch\@notmuchmail.org" <notmuch@notmuchmail.org>\r
+Subject: Re: notmuch-emacs: forward messages inline\r
+In-Reply-To: <847CC903-FE82-49B4-A3D6-1070D58BF2F3@bubblegen.co.uk>\r
+References: <430FC760-8BF5-4798-89B5-E7F2A16564B7@bubblegen.co.uk>\r
+ <87h9l0qg1p.fsf@alice.fifthhorseman.net>\r
+ <847CC903-FE82-49B4-A3D6-1070D58BF2F3@bubblegen.co.uk>\r
+User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Fri, 06 Nov 2015 18:48:24 -0500\r
+Message-ID: <87wptubsfr.fsf@alice.fifthhorseman.net>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Fri, 06 Nov 2015 23:48:29 -0000\r
+\r
+On Fri 2015-11-06 14:23:22 -0500, Matthew Lear wrote:\r
+> I guess that's one way, but it's a bit of a faff. Unless it was possible to wrap\r
+> it all up in lisp, I don't really think it's a good option.\r
+\r
+It seems to be specifically what you're looking to do, so i don't see it\r
+as a "faff" but *shrug*\r
+\r
+> No arguments on the 'being sane' front, although I have seen\r
+> notmuch-emacs fail to correctly formulate an RFC822 attachment of the\r
+> original email message a few times. I suspect this was due to MS Outlook\r
+> formatting but can't be sure, though.\r
+\r
+If you have a repeatable use case, please report it. I would expect\r
+that "inline forwarding" would be much *more* likely to formulate the\r
+message incorrectly, since it would involve re-flowing text, etc.\r
+rfc822/message-style forwarding is just an unfiltered byte-dump as a\r
+part inside a newly-composed message.\r
+\r
+> My main use of notmuch is at work where I have to handle large amounts\r
+> of email such as bug notifications from a couple of systems, messages\r
+> to/from lists, auto generated stuff for tracking, plus the usual reams\r
+> of corporate email from teams and colleagues. Notmuch allows me to\r
+> handle this fantastically.\r
+\r
+great! :)\r
+\r
+> A common use case of forwarding messages inline is to take an email\r
+> already received, and send it onto colleagues. It's not uncommon for\r
+> this to initiate a new thread of conversation and other people could\r
+> be added to the thread as appropriate. If I were to forward a message\r
+> I received as an RFC822 attachment, in order for the conversation to\r
+> be coherent and contained in the text when other people were added to\r
+> the thread, the email containing my attachment would need to be\r
+> forwarded to (additional) recipients because 'replying to all' and\r
+> including new recipients wouldn't contain the original message.\r
+\r
+It sounds like you're saying you'd like to have a reply mode that\r
+includes attachments as well. is that right? Or when replying, you'd\r
+like to have a per-attachment option to go ahead and re-include it?\r
+\r
+fwiw, i'd also like to be able to forward entire threads directly from\r
+notmuch, instead of having to forward only one message at a time.\r
+\r
+> As I see it, to be able to forward and include people starting a new\r
+> thread based on the forwarded message, it needs to be inline. Make\r
+> sense?\r
+\r
+Hm, this kind of forwarding usually results in reverse-chronological\r
+ordering, which i find impossible to read effectively, particularly when\r
+i'm jumping into the middle of it. Also, if the original message itself\r
+contains attachments, it doesn't forward those attachments effectively.\r
+right?\r
+\r
+It'd be nice to be able to bounce the relevant messages to the new\r
+recipient (e.g. "| /usr/sbin/sendmail foo@example.com") and then follow\r
+up with In-Reply-To and References set properly, all in one clean\r
+action. But depending on the age of the original message and the\r
+dmarc/anti-spam policies of the domains of the original author and the\r
+new recipient, i can imagine that the original message might not make it\r
+through, even if the followup would.\r
+\r
+I hear you that it sounds like we're missing something to cleanly handle\r
+the real-world workflow you describe, but i don't think\r
+inline-forwarding is it.\r
+\r
+ --dkg\r
projects / notmuch-archives.git / commitdiff