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 559CE6DE09FB for ; Thu, 26 Jan 2017 16:32:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.005 X-Spam-Level: X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=0.006, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OREtgxy58kAS for ; Thu, 26 Jan 2017 16:32:42 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 597E26DE0946 for ; Thu, 26 Jan 2017 16:32:42 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2) (envelope-from ) id 1cWuSV-0005Sx-ND; Thu, 26 Jan 2017 19:32:07 -0500 Received: (nullmailer pid 31248 invoked by uid 1000); Fri, 27 Jan 2017 00:32:37 -0000 From: David Bremner To: Allan Streib , notmuch@notmuchmail.org Subject: Re: Bug/Issue: References header doesn't wrap in emacs package In-Reply-To: <87twh5dmki.fsf@insight.mit.edu> References: <87612qwh04.fsf@viking.dsc.soic.indiana.edu> <87si5t1nhu.fsf@zancas.localnet> <878u7k21d8.fsf@zancas.localnet> <87d1ntg1a2.fsf@insight.mit.edu> <87vb1l9tt3.fsf@zancas.localnet> <87twh5dmki.fsf@insight.mit.edu> Date: Thu, 26 Jan 2017 20:32:37 -0400 Message-ID: <874m0le40q.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.22 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, 27 Jan 2017 00:32:44 -0000 Sanjoy Mahajan writes: > On 2016-06-07 06:28, David Bremner wrote: > >> Sanjoy Mahajan writes: >> >> >>> I'm not sure whether fixing it in emacs is right. The command 'notmuch >>> reply' is itself (with the sexp or json formats) generating the too-long >>> References: header. Shouldn't it generate an RFC-compliant message? >>> >>> Or should the json/sexp formats remain agnostic about line length, >>> because wrapping doesn't make sense with key/value pairs? In that case, >>> I agree that message-mode should fix any long lines. >> >> For me the main issue is that the references header is editable by the >> user before sending. So some input sanitization is needed at the sending >> stage. > > Further supporting that argument, the user could also include a > 1000-character line in the message body, which would require sanitizing > at the sending stage. > > -Sanjoy Headers are now folded in emacs master, apparently http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21608