spamassassin-dev September 2011 archive
Main Archive Page > Month Archives  > spamassassin-dev archives
spamassassin-dev: [Bug 6657] can't have both header existence te

[Bug 6657] can't have both header existence test and header field modifier, e.g. exists:References:addr

From: <bugzilla-daemon_at_nospam>
Date: Wed Sep 14 2011 - 09:29:03 GMT

Mark Martinec <> changed:

           What |Removed |Added
   Target Milestone|Undefined |3.4.0

--- Comment #7 from Mark Martinec <> 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 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

  Sending lib/Mail/SpamAssassin/Conf/
  Sending lib/Mail/SpamAssassin/
Committed revision 1170488.

-- Configure bugmail: ------- You are receiving this mail because: ------- You are the assignee for the bug.