I'm banging my head over this, but not seeming to find anything that stands out to me.
Intermittently... rough estimate being around 1 in 5... I'm seeing cases where an instance of SpamAssassin does not appear to use Bayes against a message. I'm suspecting at the times that this is happening, it's also having issues with network related rules/functions, such as DNSBL checks. When I check a message manually with `spamassassin -D`, Bayes seems to work properly, and in some cases I get DNSBL responses that weren't present with the original check. For background, the system in question is running RHEL 9 and SpamAssassin 4.0.1 (understanding 4.0.2 is out, just haven't had a chance to test updates for it yet). SpamAssassin is called via MailScanner rather than spamd, and everything otherwise seems to be behaving properly. The configuration was migrated recently from RHEL 7 and SA 3.4.6, and we weren't seeing this issue. Bayes is using the Mail::SpamAssassin::BayesStore::SQL store module with DBI:mysql (the actual backend server is MariaDB, though). There is a twin server that is set with a lower MX priority that also connects to the database (I haven't been able to confirm if the behavior appears on it yet). MailScanner, unfortunately, isn't logging any specific issues with the messages in question. Security limits (open files, etc.) all appear to be the same as what is on the previous server, but I am not sure if anything's being hit as nothing is being logged to indicate that as the issue. Just seeing if anyone has seen similar behavior or if they have any thoughts on mitigation. I do see that the Mail::SpamAssassin::BayesStore::MySQL store module is also available based on docs, so I do plan on testing that at my first opportunity, but that wouldn't seem to be related potential/anecdotal DNSBL or other network related functions not firing.
