On Sun, 05 Feb 2017, Brian May wrote: > On Wed, Dec 07, 2016 at 09:26:04AM +0100, Jakub Novak wrote: > > With the latest update of Debian packages in Scratch, Amavis started to > > reject more than 50% of all emails as spam. > > From Amavis debuging logs, all the MySQL fields that are of type "float" > > does not get its correct values from database anymore, but are all "0". > > Varchar, int and tinyints are still OK. > > With spam_kill_level 0, Amavis behaves that all emails with spam score >= 0 > > are rejected as sure spam. No quarantine, no spam tagging. > > I guess it must be something with data type conversion, because SQL SELECT > > that Amavis sends to Mysql (observed from Amavis.log and Mysql.log) returns > > all values and all field names fine. > > That is verified from Amavis debug log, where no "lookup_sql_field, no such > > fields" are logged (except spam_tag3_level, sa_username, sa_userconf and > > forward_method, same as before the bug). > > Is anything happening with this bug?
I don't know. I never use mysql (or any DB, really) with amavisd-new, and I have no idea why it would fetch 0 instead of the proper float value from mysql, or how to fix it :-( > The last I see is: > https://lists.amavis.org/pipermail/amavis-users/2017-January/004712.html > > In any case it looks like amavisd-new won't be included in the stretch > release, it was removed from stretch and I don't think we can get it > back in now. If we managed a minimal fix _fast_ and throughoutly tested it, we could at least *ask*... > At least it should be easy to backport as required. Sort of, and it will be annoying as all heck, though. I should know, I maintain official backports of most of my packages. amavisd-new is security-sensitive (even if it has a very good track record), so the testing + backports delay is not going to help any. At least it was confirmed in IRC that we can maintain stretch-backports from buster *and* buster security-updates, so it *is* workable, if very sub-optimal. -- Henrique Holschuh
