[Greylist-users] perl errors on non-numeric $rowids > 0

[Evan Harris]

Though it doesn't hurt anything, this warning has been fixed for a while in
the cvs version.

You can fix yours manually by changing the test to:

if (substr($rowids, 0, 1) > 0) {

Evan


On Fri, 14 Nov 2003, Ken Raeburn wrote:

>
> I just got back from a trip, fixed a mailer that was offline, finally
> whitelisted my newest MX server, and ran its queue of delayed mail.
> Now, in the (mixed sendmail + relaydelay) logs on the receiving end, I
> see a lot of these perl errors reported:
>
> Nov 14 20:19:15 kal-el relaydelay:   Whitelisted Relay.  Skipping checks and passing the mail.
> Nov 14 20:19:15 kal-el sm-mta[24752]: hAF0shSC024752: from=<bounce-debian-user=raeburn=xxxx.raeburn.org at lists.debian.org>, size=5451, class=-30, nrcpts=2, msgid=<y4tq_.A.MFC.agCs_ at murphy>, proto=ESMTP, daemon=MTA, relay=splat.raeburn.org [140.239.227.39]
> Nov 14 20:19:15 kal-el sm-mta[27855]: hAF0shSA024752: to=raeburn at xxxx-internal.raeburn.org,nobody at xxxx-internal.raeburn.org, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=149008, relay=xxxx-internal.raeburn.org. [10.0.0.6], dsn=2.0.0, stat=Sent (hAF1JFN19957 Message accepted for delivery)
> Nov 14 20:19:15 kal-el relaydelay:   IN EOM CALLBACK - PrivData: 1544,1544
> Nov 14 20:19:15 kal-el relaydelay: Argument "1544,1544" isn't numeric in numeric gt (>) at /usr/local/sbin/relaydelay.pl line 432.
> Nov 14 20:19:15 kal-el relaydelay:   * Mail successfully processed.  Incremented passed count on rowid 1544.
> Nov 14 20:19:15 kal-el relaydelay:   * Mail successfully processed.  Incremented passed count on rowid 1544.
> Nov 14 20:19:15 kal-el sm-mta[27857]: hAF0shSC024752: to=/dev/null, ctladdr=<nobody at xxx.raeburn.org> (8/0), delay=00:00:00, xdelay=00:00:00, mailer=*file*, pri=149610, dsn=2.0.0, stat=Sent
> Nov 14 20:19:15 kal-el relaydelay:
>
> (Actual recipient addresses have been obscured.)
>
> These messages are coming in with two recipient addresses each, and
> record id 1544 in the database is the newly added whitelist entry for
> the downstream server those messages are coming in from.
>
> I'm using relaydelay 0.04 modified with the VERP-handling patch I sent
> a while back.  (Actually, a minor variation of it.)  Line 432 is here,
> in eom_callback:
>
>     # Issue a temporary failure for this message.  Connection may or may not continue
>     #   with delivering other mails.
>     return SMFIS_TEMPFAIL;
>   }
>
>   # Only if we have some rowids, do we update the count of passed messages
>   if ($rowids > 0) {
> ^^^^^^^^^^^^^^^^^^^^
>     # split up the rowids and update each in turn
>     my @rowids = split(",", $rowids);
>     foreach my $rowid (@rowids) {
>       $dbh->do("UPDATE relaytofrom SET passed_count = passed_count + 1 WHERE id = $rowid") or goto DB_FAILURE;
>       print "  * Mail successfully processed.  Incremented passed count on rowid $rowid.\n" if ($verbose);
>
> Actually, there are a few places where "$rowids > 0" is checked, but
> the rowids field of the private data appears to be a comma-separated
> list of row ids.  I expect this code should probably be checking for
> an empty string, instead, or a string that doesn't match "^0+$", or
> something like that.
>
> It doesn't appear to be hurting anything; the counts do get updated,
> so at least in these error cases, it looks like the correct branch is
> being taken.
>
> Ken
>
> --
> We are Grey.  We stand between the Spam and the Light.
>