When you get line-numbered warnings, it helps to include a short snippet
(about 10 lines of context) of code in your report with the included lines.
You can use "grep -n" or "nl" for that.

EvalTests.pm line 1108.
EvalTests.pm line 1165.

Thanks.

That is why i made a point to say that i was using cvs head as of a few minutes
ago. I'm not a perl hacker (java is my beast)...so you can look at the lines
yourself. =)

Anyway, here is 1108:

dbg ("checking RBL $rbl_server, set $set", "rbl", -1);

and 1165:

eval {
    foreach my $ip (@ips) {
      next unless ($ip =~ /(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/);
      $self->do_rbl_lookup($rule, $set, $type, $rbl_server,
                           "$4.$3.$2.$1.$rbl_server", $subtest);
    }
  };

(1165 is the line that starts with $self)

> That is why i made a point to say that i was using cvs head as of a few minutes
> ago.

Someone might not be able to look at the bug report until CVS has changed
and it's easier for you to include the lines than it is for us to take our
CVS tree back in time (it's possible, but the syntax is a bit cumbersome
and it might require setting up a new CVS tree if you're doing other work).

cvs supports the ability to do a checkout at a determined date/time and it
really isn't that hard if you have any sort of cvs experience (which i would
hope you do if you are using it).

You can also easily browse the viewcvs commits in that file at the date/time of
the bug report to see what changes had happened.

I heart lazy people. Not.

> cvs supports the ability to do a checkout at a determined date/time and it
> really isn't that hard if you have any sort of cvs experience (which i would
> hope you do if you are using it).

Which I said it did.  I also said it's cumbersome which is my opinion.
Also, the CVS server is slow during the day and I don't want to check out the
entire tree to get your version if I can avoid it.

Also, this way, I don't have to trust that the CVS tree was up-to-date and
I don't have to worry that the version you were running is the same as the
version in your CVS tree.

And get this, it's *less work* for the reporter to copy a few lines than it
is for the developer of the code to check out a new CVS tree.

> I heart lazy people. Not.

That's pretty rude and inconsiderate.  Are you paying me or something?

Just the same, I would like to fix this problem, so I need to ask you some
questions:

1. Have you defined any local SpamAssassin rules, possibly from an older
   version of SpamAssassin?  Especially RBL tests. Any settings in local.cf
   or user_prefs for the users that are experiencing the problem?  If so,
   please attach them to this report (and try reproducing the error without
   them).

2. I need you to attach some example spam that triggered these warnings.
   I can't reproduce this problem using any of my spam.  When you attach it,
   use the "Create a new attachment" link on this web page and include the
   full headers of the example messages (in mbox format), don't use
   cut-and-paste.

3. Please tell me the version of perl that you're using ("perl -v" is fine),
   the OS, and the OS version.

Thanks.

> Also, the CVS server is slow during the day and I don't want to check out the
> entire tree to get your version if I can avoid it.

No need for the entire tree to get the line numbers. You can just get the one
single file. Also, since you seem to be online right now and answering my
questions pretty quickly, it seems that you would have the version of the file
I'm talking about. =)

> And get this, it's *less work* for the reporter to copy a few lines than it
> is for the developer of the code to check out a new CVS tree.

That is why I included it for you after you requested it.

> That's pretty rude and inconsiderate.  Are you paying me or something?

Why should I pay you...you choose to volunteer on your own. Just like I have
done for the last 9+ years I have contributed to OSS projects.

--------------------------------------------------------------------------

1. Have you defined any local SpamAssassin rules, possibly from an older
   version of SpamAssassin?  Especially RBL tests. Any settings in local.cf
   or user_prefs for the users that are experiencing the problem?  If so,
   please attach them to this report (and try reproducing the error without
   them).

since bugzilla sucks so badly (@see http://scarab.tigris.org/), I will attach it
in another message.

---------------------------------------------------------------------------

2. I need you to attach some example spam that triggered these warnings.
   I can't reproduce this problem using any of my spam.  When you attach it,
   use the "Create a new attachment" link on this web page and include the
   full headers of the example messages (in mbox format), don't use
   cut-and-paste.

It happens on each and every message that comes through my server.
---------------------------------------------------------------------------

3. Please tell me the version of perl that you're using ("perl -v" is fine),
   the OS, and the OS version.

perl -v                                         

This is perl, v5.8.0 built for darwin

uname -a
Darwin takahe.whichever.com 6.6 Darwin Kernel Version 6.6: Thu May  1 21:48:54 P
DT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC  Power Macintosh powerpc
---------------------------------------------------------------------------

header RCVD_IN_RFCI_WHOIS       eval:check_rbl('rfciwhois', 'whois.rfc-ignorant.
org.')

> It happens on each and every message that comes through my server.

And I don't have a single one of them.  The problem could have been with the
received header parsing or something specific to the format of YOUR mail
messages.

However, the problem is a syntax error in your rule:

header RCVD_IN_RFCI_WHOIS       eval:check_rbl('rfciwhois',
'whois.rfc-ignorant.org.')

It's "rbleval", not "eval".

yea for backwards incompatible changes. not.