From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 81D721F62E; Wed, 16 Jan 2019 04:58:02 +0000 (UTC) Date: Wed, 16 Jan 2019 04:58:02 +0000 From: Eric Wong To: Wang Kang Cc: meta@public-inbox.org, alpine-info@u.washington.edu, Konstantin Ryabitsev Subject: [PATCH] nntp: header responses use CRLF consistently Message-ID: <20190116045802.ikm67b4cwigso3tc@dcvr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: Thanks, I'm pretty sure the following will fix it. Not sure why others hadn't noticed since there's a lot of Alpine users judging from Message-IDs. Anyways I managed to replicate it quickly with alpine in Debian ("alpine -url news://...") and strace quickly showed me the difference. Deploying to news.public-inbox.org shortly. Cc-ing Konstantin for kernel.org. ---------------8<----------------- Subject: [PATCH] nntp: header responses use CRLF consistently Alpine is apparently stricter than other clients I've tried w.r.t. using CRLF for headers. So do the same thing we do for bodies to ensure we only emit CRLFs and no bare LFs. Reported-by: Wang Kang https://public-inbox.org/meta/alpine.DEB.2.21.99.1901161043430.29788@la.scateu.me/ --- lib/PublicInbox/NNTP.pm | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/PublicInbox/NNTP.pm b/lib/PublicInbox/NNTP.pm index 623ffd3..63d5870 100644 --- a/lib/PublicInbox/NNTP.pm +++ b/lib/PublicInbox/NNTP.pm @@ -515,6 +515,7 @@ sub set_art { sub _header ($) { my $hdr = $_[0]->header_obj->as_string; utf8::encode($hdr); + $hdr =~ s/(?