https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6657
--- Comment #6 from Adam Katz <[email protected]> 2011-09-10 00:31:25 UTC --- I like the documentation changes, but I think "missing or invalid delimiters" was better than the new phrasing, 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. Maybe something like: $parse_error = "config: SpamAssassin failed to parse line, \"$def\" ". "does not specify a valid field name for \"$key\", ". "skipping: $line"; 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? 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 (basically [^:\s] though I think other code has already handled the white space). (An extra level of confusion: POSIX regexps that begin with an exclamation point are negated.) Do we really need to look for extended or non-printing characters here? Can we instead simplify this to [^:] or [^:\s] ? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
