From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966812AbdCXUOj (ORCPT ); Fri, 24 Mar 2017 16:14:39 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:43968 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966267AbdCXUOb (ORCPT ); Fri, 24 Mar 2017 16:14:31 -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: Date: Fri, 24 Mar 2017 13:14:29 -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: <1490121068.2041.13.camel@perches.com> 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:14:30 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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