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 37B426DE0119 for ; Thu, 16 Nov 2017 17:09:00 -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=[AWL=0.011, 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 QpXxdJJYEW_h for ; Thu, 16 Nov 2017 17:08:58 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 7D0AF6DE00D4 for ; Thu, 16 Nov 2017 17:08:58 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.89) (envelope-from ) id 1eFV9J-000114-6s; Thu, 16 Nov 2017 20:08:53 -0500 Received: (nullmailer pid 9177 invoked by uid 1000); Fri, 17 Nov 2017 01:08:51 -0000 From: David Bremner To: Kai Harries , notmuch@notmuchmail.org Cc: Tomi Ollila Subject: Re: bounce/forward not working due to CR at line end In-Reply-To: <87shdeovhb.fsf@x230.kaiha.invalid> References: <87d14ri436.fsf@x230.kaiha.invalid> <877euraf0e.fsf@tethera.net> <87fu9f45e1.fsf@x230.kaiha.invalid> <877eur5i33.fsf@tesseract.cs.unb.ca> <87shdeovhb.fsf@x230.kaiha.invalid> X-List-To: notmuch Date: Thu, 16 Nov 2017 21:08:51 -0400 Message-ID: <877eup90f0.fsf@tethera.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: Fri, 17 Nov 2017 01:09:00 -0000 Kai Harries writes: > David Bremner writes: > >> Kai Harries writes: >> >>> David Bremner writes: >>> >>>> During off-list discussion, Kai mentioned id:87a7zsm5ol.fsf@gmail.com as >>>> a message that he cannot bounce (and also not forward?). For me this >>>> forwards fine, but does not bounce because it has a corrupted Cc header, >>>> and my MTA rejects it. That doesn't sound related to the original >>>> problem report (nothing about line endings). >>> >>> Can you please evaluate the following on your system: >>> >>> (call-process "notmuch" nil t nil "show" "--format=raw" "id:87a7zsm5ol.fsf@gmail.com") >>> >>> If I do this on my system, then the text that is inserted into the >>> buffer has ^M (CR) at the line endings. Is this expected? >> >> No ^M line endings for me. Can you check the file on disk? Maybe "od -a" >> lacking a better idea. > > `od -a` does also show that the lines are ending with 'cr' and 'nl' > this is correct according to RFC 2822 [1]. That's not so clear. RFC2822 is explicitely not about disk storage; see the Scope paragraph of RFC2822 or RFC522. I think most peoples unix mail delivery agents use line feeds, otherwise more people would be having problems resending mail. See e.g. point 2 in https://www.exim.org/exim-html-current/doc/html/spec_html/ch-message_processing.html Be that as it may, apparently your system is using CRLF. > > According to this [2] Emacs normally converts line endings to only 'nl' > (newline) when opening a DOS file. This works on my system, if I open the > file from disk no carriage-return (^M) is shown. > > Not working is inserting the output of `notmuch show` into a buffer. If > I do this, then the carriage-return (^M) is shown. Yes, notmuch-show-resend-message uses notmuch-show-view-raw-message, which intentionally turns off any conversion > > David, I assume your system is also a Linux, does > > notmuch show --format=raw id:1472041345236.7014@de.bosch.com | od -a > > also show 'cr' and 'nl' as line ending? No, I don't have carriage returns in my actual files on disk, and consequently not in the output of notmuch show --format=raw. I suspect notmuch is mostly fine with CRLF line endings, due to mainly passing everything through gmime. But in the case of notmuch show --format=raw, this is not the case. I did confirm that adding CRLF line endings to an existing mail file causes the symptoms you originally described. I'm still not sure the best place to fix this; I'm pretty sure upstream emacs won't accept your change (or equivalent) to mime-to-mml. d