https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6657
Mark Martinec <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|Undefined |3.4.0 --- Comment #7 from Mark Martinec <[email protected]> 2011-09-14 09:29:03 UTC --- > lint: config: SpamAssassin failed to parse line, "__HAS_REFERENCES_ADDR > exists:References:addr" does not specify a valid header field name for > "header", skipping: header __HAS_REFERENCES_ADDR exists:References:addr > at build/mkrules line 254. > $value and $line are nearly identical and therefore redundant. Agreed, redundant. > Maybe something like: > $parse_error = "config: SpamAssassin failed to parse line, \"$def\" ". > "does not specify a valid field name for \"$key\", ". > "skipping: $line"; The $def is unfortunately no longer available in Parser.pm where the diagnostics is issued. So to avoid having to re-parse I just simplified the text, it now reads: $ spamassassin -L --lint Sep 14 11:17:36.188 [94102] warn: config: SpamAssassin failed to parse line, it does not specify a valid header field name, skipping: header SYMBOLIC_TEST_NAME exists:From:addr when encountering an illegal directive such as this. > Another note: even though this fails t/lint.t (but only on the first run since > a 'make clean' or rules update), 'make test' does not fail and 'spamassassin > --lint' still has no output (and -D doesn't add anything on this front). Are > these the desired outcomes? I don't understand what you are saying. The 'spamassassin --lint' does produce output when there is an error in one of the configuration files. Where is a t/lint.t ? > Separately, and I know this was in the code before Mark touched it, I dislike > our use of the regex character class [!-9;-\176] which matches the two > ranges from "!" to "9" and from ";" to "\176" (~, tilde). I had to look at a > character map to even figure out that this is really just looking for any > non-colon/non-space/non-extended printable characters The regexp was just transliterated from RFC 5322 section 3.6.8: field-name = 1*ftext ftext = %d33-57 / ; Printable US-ASCII %d59-126 ; characters not including ; ":". But I agree it is probably an overkill. Changed it to: } elsif ($header_name !~ /^([^: \t]+)$/) { # be generous trunk: Sending lib/Mail/SpamAssassin/Conf/Parser.pm Sending lib/Mail/SpamAssassin/Conf.pm Committed revision 1170488. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
