On 2023-01-06 at 17:23:50 UTC-0500 (Fri, 6 Jan 2023 16:23:50 -0600) Brian Conry <bco...@bestpractical.com> is rumored to have said:
Hi, First things first: * SpamAssassin version: 3.4.2 * Debian 10
I don't know what the Debian versioning status is, but that is a very old and very likely broken SA if it has not had 3.4.6 patches backported.
* SA is created and invoked as a Perl object by a MIMEDefang filter
On 2023-01-08 at 00:57:47 UTC-0500 (Sat, 7 Jan 2023 23:57:47 -0600) Brian Conry <bco...@bestpractical.com> is rumored to have said:
First, any configuration change I would make would be scoped to _only_ the one (1) recipient address in question - nothing will be changed about what SA does for any other address that we handle.
Easy: in your mimedefang-filter file, just skip the entire SA check if a message is for that one recipient. Note that you cannot exclude users from milter handling inside Postfix itself. (Your Option 3)
Slightly harder: in your mimedefang-filter file, load alternative rules for that one recipient which excludes (zero scores) URIDNSBL rules. (variation on Option 4)
More work: in your mimedefang-filter file, selectively exempt or special-rule messages for that one recipient based on something more selective than just the recipient, e.g. sender, size, subject, etc. (variation on Option 4)
Hardest: slap some sense into whoever has decreed particular DNS queries to be suspect. Policing mail system DNS with the same rules one uses to protect random Windows PCs driven directly by humans from their users is unworkable by design.
It may well be that simply excluding RTIR inbound traffic entirely from SA checks would be the wisest choice. If you are using the Bayes rules with auto-learning (which you may be by default) there's a risk of mis-training on that anomalous mail flow and applying the "learning" to everyone else's mail.
-- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
