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 2D5D76DE141B for ; Mon, 9 Nov 2015 06:59:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[AWL=0.055, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 NQVxIi1r2jjk for ; Mon, 9 Nov 2015 06:59:04 -0800 (PST) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by arlo.cworth.org (Postfix) with ESMTPS id 3FBC96DE1348 for ; Mon, 9 Nov 2015 06:59:04 -0800 (PST) Received: by wmnn186 with SMTP id n186so108433684wmn.1 for ; Mon, 09 Nov 2015 06:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=9w8NPj9gXoFhtAynau/nDoz6rAGXAYLOpClEgPlogcY=; b=yaRIVEdQdLMIKLUPeEPjaeUAUqngzyO8UjJHRSlkx6vjKsFT9vCVkaqKM4xTHXRT79 uzINqLygDe90yP7KIadbLawh1lvf/8yt1Ad2dAyFCQwEs36ua35Y5607hFiFI1/MoRdR LNz9pZdQpp+GyYkREZBlpiR9ApR09JZTwUyk/FsS3nYqit/J60IBqVi2ZGBIT/BjA7TH X8ST3WFDUkc1nTJJ7Lx0qRD7qv6hwLwQYbGtqkRaCIV3Ye9mutsqQ0VemNVzaqmZsyag QEX4pTyvzMgJ468k79rnQIxIm1CLV/vM6vkUEh1HX/cOPGlKgLv25i+SHbn5qiMCme4L DRrw== X-Received: by 10.194.77.174 with SMTP id t14mr30693178wjw.23.1447081141229; Mon, 09 Nov 2015 06:59:01 -0800 (PST) Received: from localhost (5751dfa2.skybroadband.com. [87.81.223.162]) by smtp.gmail.com with ESMTPSA id lb2sm15870117wjc.15.2015.11.09.06.58.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2015 06:59:00 -0800 (PST) From: Mark Walters To: Matthew Lear , Daniel Kahn Gillmor 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.18+519~ga09e253 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Mon, 09 Nov 2015 14:58:58 +0000 Message-ID: <871tbz8bil.fsf@qmul.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Mon, 09 Nov 2015 14:59:07 -0000 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 wrote: > Hi Daniel, > >> On 5 Nov 2015, at 21:42, Daniel Kahn Gillmor 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