Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966938AbdCXUTV (ORCPT ); Fri, 24 Mar 2017 16:19:21 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:44038 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935652AbdCXUTP (ORCPT ); Fri, 24 Mar 2017 16:19:15 -0400 Subject: Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent spurious warnings To: Joe Perches , linux-kernel@vger.kernel.org References: <1490113805-9295-1-git-send-email-warthog9@eaglescrag.net> <1490121068.2041.13.camel@perches.com> Cc: Andy Whitcroft , "Darren Hart (VMware)" From: "John 'Warthog9' Hawley" Message-ID: <8d5aff7a-5fca-c551-f6df-c617c11564d6@eaglescrag.net> Date: Fri, 24 Mar 2017 13:19:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 24 Mar 2017 13:19:14 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2239 Lines: 71 You can disregard this, I missed the other thread and that looks fine. On 03/24/2017 01:14 PM, John 'Warthog9' Hawley wrote: > On 03/21/2017 11:31 AM, Joe Perches wrote: >> On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote: >>> Spamassassin sticks a long (~79 character) long string after a >>> line that has a single space in it. The line with space causes >>> checkpatch to erroniously think that it's in the content body, as >>> opposed to headers and thus flag a mail header as an unwrapped long >>> comment line. >> >> If the spammassassin header is like >> >> email-header-n: foo >> email-header-m: bar >> >> X-Spam-Report: bar >> >> Does that form follow rfc 5322? > > It does look that way > >> If it does then any email header could have that >> form and the header wrapping test should be >> updated from >> >> if ($in_header_lines && $realfile =~ /^$/ && >> !($rawline =~ /^\s+\S/ || >> $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) { >> $in_header_lines = 0; >> $in_commit_log = 1; >> $has_commit_log = 1; >> } >> >> to something like >> >> if ($in_header_lines && $realfile =~ /^$/ && >> !($rawline =~ /^ (?:\s*\S|$)/ || >> $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) { >> > > So this seems to fix the specific issue we were tripping over, but in > doing so causes some other problems on some of the other headers in the > message we are using for testing (3 new warnings, and an error), > specifically flagging a: > - Warning on 'Received:' header > - Warning on 'DKIM-Signature:' header (twice, for both leading and > trailing white space on To: and From:) > - Erroring on the DKIM-Signature as well > > Noting the DKIM-Signature, in this case, is also a multi-line header message > > This resolves the issue we were seeing, and doesn't (at least in my test > cases), cause any new errors: > > if ($in_header_lines && $realfile =~ /^$/ && > !( > ( > $rawline =~ /^\s+\S*/ > && > $rawline !~ /^[\r\n]+$/ > ) > || > $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i) > ) { > > as the line that's causing issues, /^ [\r\n]+$/, wouldn't get > incorrectly caught as the end of the headers. > > - John 'Warthog9' Hawley >