From: Daniel Kahn Gillmor Date: Fri, 6 Nov 2015 23:48:24 +0000 (+1900) Subject: Re: notmuch-emacs: forward messages inline X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=4c6b57165d2f93f01b114e670168712a81e0f1a8;p=notmuch-archives.git Re: notmuch-emacs: forward messages inline --- diff --git a/a6/25cc343a4c3efd7b0c7b1f9f80ad55eca75c61 b/a6/25cc343a4c3efd7b0c7b1f9f80ad55eca75c61 new file mode 100644 index 000000000..d42a7672d --- /dev/null +++ b/a6/25cc343a4c3efd7b0c7b1f9f80ad55eca75c61 @@ -0,0 +1,118 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +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