Hello SpamAssassin Users and Developers,
I wanted to take a moment to provide my $0.02 on two in the wild issues
with 3.4.1 that I've heard a lot about in the past few days:
The first in the wild issue has been some failures on sa_compile.t.
These errors are confirmed as solely test errors and do not indicate an
issue with using compiled rules in production. You can see more about
the issue on https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7181 and
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7005. If you are
affected by this issue, an easy work around is to rename the re2c
executable during cpan installations or make tests so that the
sa_compile.t test is skipped.
And if you do have issues with compiled rules beyond the tests,
commenting out the Rule2XSBody plugin in v320.pre will disable the use
of compiled rules and the underlying deterministic finite state machine.
The second in the wild issue has been some logging of uninitialized
errors from TxRep.com when txrep_track_messages is enabled. The errors
are categorized as completely innocuous but totally annoying. The good
news is that we believe the logic causing the issue has been identified
and improved. But before I state that emphatically, I have asked Ivo,
the author of TxRep, to review the logic changes that avert the error to
make sure we have a good fix. You can see more about that issue at
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164. In the
meantime, an easy work around to this issue is to add
txrep_track_messages 0 to your configuration which will disable the code
with the bug.
In my opinion, neither of these issues warrants an escalation of a 3.4.2
release but I wanted to let people know they are being actively worked
on as well as give some possible workarounds.
Thanks for supporting Apache SpamAssassin!
Regards,
KAM
--
Kevin A. McGrail
VP & Chair, Apache SpamAssassin Project Management Committee
