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 9C94B6DE0314 for ; Mon, 22 May 2017 18:38:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.156, RDNS_NONE=0.2] 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 sCRCVsPYDkmX for ; Mon, 22 May 2017 18:38:05 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) by arlo.cworth.org (Postfix) with ESMTP id C65446DE0191 for ; Mon, 22 May 2017 18:38:05 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 28A52F99B; Mon, 22 May 2017 19:49:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3F440218CE; Mon, 22 May 2017 17:06:13 -0400 (EDT) From: Daniel Kahn Gillmor To: David Bremner , notmuch@notmuchmail.org, notmuch@freelists.org Subject: Re: changing behaviour of notmuch show --part=1 In-Reply-To: <878tlpyyfi.fsf@tethera.net> References: <878tlpyyfi.fsf@tethera.net> Date: Mon, 22 May 2017 17:06:13 -0400 Message-ID: <874lwctxdm.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 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: Tue, 23 May 2017 01:38:06 -0000 On Mon 2017-05-22 07:32:17 -0300, David Bremner wrote: > The current behaviour of "notmuch show --part=1 --raw" is somewhat > peculiar. This is supposed to be the message body, but if the message is > multipart, it also includes the headers. This seems to be a direct > translation of an implimentation of quirk of gmime. In gmime 3.0 this > quirk goes away, and the behaviour of notmuch consequently changes, > unless we do something about it. I actually think the new behaviour > makes more sense (you only get the headers with part=0). There seem to > be several options > > 1) Bug-for-Bug-compatibility: Add special case code for gmime-3.0 to > output headers. > > 2) Allow-varying-output: Consider the previous behaviour a bug, fixed by > using gmime-3.0. This makes it hard for people to rely on, although > how one relies on it currently since it varies by message is a > mystery. > > 3) Fix the alleged bug: special case the output of the body with > gmime-2.6 to avoid outputting headers. i favor (2) for the short term, while treating (3) as an open bug to be fixed. thanks for identifying this, David. --dkg