Bug 7787

Summary: Use of uninitialized value in TxRep
Product: Spamassassin Reporter: Vadim Belman <vrurg>
Component: PluginsAssignee: SpamAssassin Developer Mailing List <dev>
Status: NEW ---    
Severity: normal    
Priority: P2    
Version: 3.4.3   
Target Milestone: Undefined   
Hardware: PC   
OS: FreeBSD   

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.