Bug 7787 - Use of uninitialized value in TxRep
Summary: Use of uninitialized value in TxRep
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.4.3
Hardware: PC FreeBSD
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
Depends on:
Reported: 2020-01-20 15:48 UTC by Vadim Belman
Modified: 2020-01-20 15:48 UTC (History)
0 users

Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Vadim Belman 2020-01-20 15:48:13 UTC
Recent upgrade of packages on a mailserver brought in spamassasin v3.4.3 together with lots of warnings from TxRep:

Use of uninitialized value in numeric gt (>) at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1465.
Use of uninitialized value in string eq at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1502.

A typical command line causing this looks like:

sa-learn --spam $HOME/Maildir/.auxiliary.SPAM/new $HOME/Maildir/.auxiliary.SPAM/cur

Though it looks like pretty much any other learning command would result in the same warning. It also looks like the warning is produced per each single mail processed.

TxRep is configured for use of a SQL server, DB is shared among server users:

user_awl_dsn                 DBI:mysql:spamassassin:localhost
user_awl_sql_username        <...>
user_awl_sql_password        <...>
user_awl_sql_table           txrep
txrep_factory Mail::SpamAssassin::SQLBasedAddrList
header         TXREP   eval:check_senders_reputation()
describe       TXREP   Score normalizing based on sender's reputation
tflags         TXREP   userconf noautolearn
priority       TXREP   1000

User configuration related to txrep is following:

use_txrep 1
txrep_autolearn 0
txrep_ipv4_mask_len 16
txrep_learn_penalty 50
txrep_learn_bonus 100
txrep_track_messages 1
txrep_user2global_ratio 0

Prior to upgrading I saw no warnings, the DB hasn't benn altered in any way, up to my knowledge.

Personal note: I don't have time for debugging the issue. But a quick look into the code raised a flag about the use of method count(). It is expected to return undef under certain conditions, but the return value is never checked and blindly used as is. Not mentioning the fact that $self->{entry}->{msgcount} it returns might also happen to be unset (even as a side effect of another bug), but the value is not tested for validity.