Re: excluding specific RBL checks
> On Jan 8, 2023, at 10:35 PM, Henrik K wrote: > > On Sun, Jan 08, 2023 at 04:23:11PM -0500, Charles Sprickman wrote: >> What did you end up with? >> >> I have a bunch of zero rules for these yet still keep getting the >> "administrative notice" from sbl/zen. >> >> The fact that those guys don't just send out a "yes, this is on by default >> in spamassassin, here is copy pasta to turn us off" email bugs me. >> >> I've grown to this huge list and still get the warnings. >> >> # remove spamhaus tests, they want us to pay >> # need to include the first base rule or DNS still triggers but is ignored >> score __RCVD_IN_ZEN 0 >> score RCVD_IN_SBL 0 >> score RCVD_IN_XBL 0 >> score RCVD_IN_PBL 0 >> score URIBL_SBL 0 >> score URIBL_CSS 0 >> score URIBL_SBL_A 0 >> score URIBL_CSS_A 0 >> score URIBL_DBL_SPAM 0 >> score URIBL_DBL_PHISH 0 >> score URIBL_DBL_MALWARE 0 >> score URIBL_DBL_BOTNETCC 0 >> score URIBL_DBL_ABUSE_SPAM 0 >> score URIBL_DBL_ABUSE_REDIR 0 >> score URIBL_DBL_ABUSE_PHISH 0 >> score URIBL_DBL_ABUSE_MALW 0 >> score URIBL_DBL_ABUSE_BOTCC 0 >> >> Until I can get around to updating I'm considering just nuking the actual >> tests from the ruleset. > > Much easier and reliable way: > > dns_query_restriction deny spamhaus.org Trying this on half the pair, I assume this hits all subdomains of spamhaus.org? Never ran into that parameter in my searches for this. Thanks! Charles
Re: excluding specific RBL checks
> On Jan 8, 2023, at 10:44 PM, joe a wrote: > > On 1/8/2023 4:23 PM, Charles Sprickman wrote: >> What did you end up with? > > score RCVD_IN_ZEN_BLOCKED_OPENDNS 0 > > I am not certain if that stops the test or simply reporting of the message. > Looks like I will need to do some packet capture after all. > >> I have a bunch of zero rules for these yet still keep getting the >> "administrative notice" from sbl/zen. >> The fact that those guys don't just send out a "yes, this is on by default >> in spamassassin, here is copy pasta to turn us off" email bugs me. >> I've grown to this huge list and still get the warnings. >> # remove spamhaus tests, they want us to pay >> # need to include the first base rule or DNS still triggers but is ignored >> score __RCVD_IN_ZEN 0 > > Is that a typo? There should be no underscore before RCVD, correct? That's copypasta from the wiki page spamhaus references. No explanation on the page why the underscores... C > >> score RCVD_IN_SBL 0 >> score RCVD_IN_XBL 0 >> score RCVD_IN_PBL 0 >> score URIBL_SBL 0 >> score URIBL_CSS 0 >> score URIBL_SBL_A 0 >> score URIBL_CSS_A 0 >> score URIBL_DBL_SPAM 0 >> score URIBL_DBL_PHISH 0 >> score URIBL_DBL_MALWARE 0 >> score URIBL_DBL_BOTNETCC 0 >> score URIBL_DBL_ABUSE_SPAM 0 >> score URIBL_DBL_ABUSE_REDIR 0 >> score URIBL_DBL_ABUSE_PHISH 0 >> score URIBL_DBL_ABUSE_MALW 0 >> score URIBL_DBL_ABUSE_BOTCC 0 >> Until I can get around to updating I'm considering just nuking the actual >> tests from the ruleset. >> Charles signature.asc Description: Message signed with OpenPGP
Re: excluding specific RBL checks
On 1/8/2023 10:35 PM, Henrik K wrote: On Sun, Jan 08, 2023 at 04:23:11PM -0500, Charles Sprickman wrote: . . . # remove spamhaus tests,. . . score RCVD_IN_SBL 0 score RCVD_IN_XBL 0 score RCVD_IN_PBL 0 score URIBL_SBL 0 score URIBL_CSS 0 score URIBL_SBL_A 0. . . Much easier and reliable way: dns_query_restriction deny spamhaus.org Ah Hah! Seems to work for me. See? I CAN be taught! joe a.
Re: excluding specific RBL checks
On 1/8/2023 4:38 PM, Benny Pedersen wrote: joe a skrev den 2023-01-08 21:50: SA version 3.4.5 Gears are clashing, clutch is slipping, among other things. Trying to exclude certain checks, via spamhouse services "by the book" what book ? The good one? Several places. Most looked like cut and paste from each other. Trying to find the exact place now and cannot. Saw it most recently on another list, where others happened to be having similar dns issues. When placing these values in local.cf: RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 "spamassassin --lint" complains. Yet SA starts without complaint and seems to not run those tests. you miss score in 3 lines ? Yep. Placing "score" at the beginning of the line makes lint happy and SA seems to start fine and also does not run those tests. so lint passed ? Yes, with score. So, one assumes it is a typo in the docs, or, one is expected to infer the "score" word. what docs ? anythin on web is fake news, only valid docs is perldoc Mail::SpamAssassin::Conf I only know of https://spamassassin.apache.org/full/3.4.x/doc/ which I though I was referencing. Seems likely I just allowed myself to be misled, "chaff". and all related plugins Yet I still see this while "skip_rbl_checks 1" (in both above scenarios): clear your config :) "RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE:" Which suggests that one runs despite the directive or, I am using the wrong one. make /etc/resolv.conf only have nameserver 127.0.0.1 and you ether have bind, unbound, pdns-recursor as of your own choise Certainly worth a try and much simpler that what I was trying. still problems ?, lets hear them
Re: excluding specific RBL checks
On 1/8/2023 4:23 PM, Charles Sprickman wrote: What did you end up with? score RCVD_IN_ZEN_BLOCKED_OPENDNS 0 I am not certain if that stops the test or simply reporting of the message. Looks like I will need to do some packet capture after all. I have a bunch of zero rules for these yet still keep getting the "administrative notice" from sbl/zen. The fact that those guys don't just send out a "yes, this is on by default in spamassassin, here is copy pasta to turn us off" email bugs me. I've grown to this huge list and still get the warnings. # remove spamhaus tests, they want us to pay # need to include the first base rule or DNS still triggers but is ignored score __RCVD_IN_ZEN 0 Is that a typo? There should be no underscore before RCVD, correct? score RCVD_IN_SBL 0 score RCVD_IN_XBL 0 score RCVD_IN_PBL 0 score URIBL_SBL 0 score URIBL_CSS 0 score URIBL_SBL_A 0 score URIBL_CSS_A 0 score URIBL_DBL_SPAM 0 score URIBL_DBL_PHISH 0 score URIBL_DBL_MALWARE 0 score URIBL_DBL_BOTNETCC 0 score URIBL_DBL_ABUSE_SPAM 0 score URIBL_DBL_ABUSE_REDIR 0 score URIBL_DBL_ABUSE_PHISH 0 score URIBL_DBL_ABUSE_MALW 0 score URIBL_DBL_ABUSE_BOTCC 0 Until I can get around to updating I'm considering just nuking the actual tests from the ruleset. Charles
Re: excluding specific RBL checks
On 1/8/2023 4:00 PM, joe a wrote: On 1/8/2023 3:50 PM, joe a wrote: SA version 3.4.5 Gears are clashing, clutch is slipping, among other things. Trying to exclude certain checks, via spamhouse services "by the book" When placing these values in local.cf: RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 "spamassassin --lint" complains. Yet SA starts without complaint and seems to not run those tests. Placing "score" at the beginning of the line makes lint happy and SA seems to start fine and also does not run those tests. So, one assumes it is a typo in the docs, or, one is expected to infer the "score" word. Yet I still see this while "skip_rbl_checks 1" (in both above scenarios): "RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE:" Which suggests that one runs despite the directive or, I am using the wrong one. And the answer to the latter is "I had the wrong directive". Which is obvious. Now. Correcting myself, yet again, "score" needs to be specified, it seems, otherwise this is seen in /var/log/mail: 2023-01-08T15:00:42.854109-05:00 auxilary spamd[14937]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": RCVD_IN_ZEN 0 2023-01-08T15:00:42.854573-05:00 auxilary spamd[14937]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": RCVD_IN_XBL 0 2023-01-08T15:00:42.854908-05:00 auxilary spamd[14937]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": RCVD_IN_PBL 0 Contrary to some, there is value in following logs when making changes. who'd have thought that.
Re: excluding specific RBL checks
On Sun, Jan 08, 2023 at 04:23:11PM -0500, Charles Sprickman wrote: > What did you end up with? > > I have a bunch of zero rules for these yet still keep getting the > "administrative notice" from sbl/zen. > > The fact that those guys don't just send out a "yes, this is on by default in > spamassassin, here is copy pasta to turn us off" email bugs me. > > I've grown to this huge list and still get the warnings. > > # remove spamhaus tests, they want us to pay > # need to include the first base rule or DNS still triggers but is ignored > score __RCVD_IN_ZEN 0 > score RCVD_IN_SBL 0 > score RCVD_IN_XBL 0 > score RCVD_IN_PBL 0 > score URIBL_SBL 0 > score URIBL_CSS 0 > score URIBL_SBL_A 0 > score URIBL_CSS_A 0 > score URIBL_DBL_SPAM 0 > score URIBL_DBL_PHISH 0 > score URIBL_DBL_MALWARE 0 > score URIBL_DBL_BOTNETCC 0 > score URIBL_DBL_ABUSE_SPAM 0 > score URIBL_DBL_ABUSE_REDIR 0 > score URIBL_DBL_ABUSE_PHISH 0 > score URIBL_DBL_ABUSE_MALW 0 > score URIBL_DBL_ABUSE_BOTCC 0 > > Until I can get around to updating I'm considering just nuking the actual > tests from the ruleset. Much easier and reliable way: dns_query_restriction deny spamhaus.org
TxRep records unreliably on MySQL
Hello list, After an upgrade to SA-4.0.0 I decided to give TxRep a try after using AWL since it was introduced. I set up TxRep accordingly to SA’s documentation with a mysql-5.7.40 server, give it a first try by sending an email to the box where SA is running and saw TxRep just has recorded unreliably onto the sql table: #v+ root@localhost [spamassassin]> describe txrep; +--+--+--+-+---+-+ | Field| Type | Null | Key | Default | Extra | +--+--+--+-+---+-+ | username | varchar(100) | NO | PRI | | | | email| varchar(255) | NO | PRI | | | | ip | varchar(40) | NO | PRI | | | | msgcount | int(11) | NO | | 0 | | | totscore | float| NO | | 0 | | | signedby | varchar(255) | NO | PRI | | | | last_hit | timestamp| NO | MUL | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | +--+--+--+-+---+-+ 7 rows in set (0,00 sec) root@localhost [spamassassin]> select * from txrep; +--+---+--+--+--++-+ | username | email | ip | msgcount | totscore | signedby | last_hit| +--+---+--+--+--++-+ | vscan| 209.85.218.51 | none |1 | -0.217 || 2023-01-09 01:25:46 | | vscan| aac3c57398484c78fd317abe6061e81c4b9296f2@sa_generated | none |1 | -0.217 | 1673223945 | 2023-01-09 01:25:46 | | vscan| gmail.com | none |1 | -0.217 | gmail.com | 2023-01-09 01:25:46 | | vscan| mail-ej1-f51.google.com | none |1 | -0.217 | helo | 2023-01-09 01:25:46 | | vscan| u...@gmail.com| none |1 | -0.217 | gmail.com | 2023-01-09 01:25:46 | +--+---+--+--+--++-+ 5 rows in set (0,00 sec) #v- Anyone can tell me how the hell it is logging for example: an address in the email column or garbage on the signedby table? SQL statements used to create txrep table is the one supplied by SA-4.0.0 (beside table’s name, this is the same as ones AWL need). The following TxRep settings were been used in the global local.cf: #v+ use_txrep 1 txrep_ipv4_mask_len 32 txrep_ipv6_mask_len 128 auto_welcomelist_distinguish_signed 1 txrep_spf 1 #v- Cheers, -- matt [at] lv223.org GPG key ID: 7D91A8CA
Re: excluding specific RBL checks
Charles Sprickman skrev den 2023-01-08 22:23: What did you end up with? I have a bunch of zero rules for these yet still keep getting the "administrative notice" from sbl/zen. The fact that those guys don't just send out a "yes, this is on by default in spamassassin, here is copy pasta to turn us off" email bugs me. I've grown to this huge list and still get the warnings. # remove spamhaus tests, they want us to pay # need to include the first base rule or DNS still triggers but is ignored score __RCVD_IN_ZEN 0 score RCVD_IN_SBL 0 score RCVD_IN_XBL 0 score RCVD_IN_PBL 0 score URIBL_SBL 0 score URIBL_CSS 0 score URIBL_SBL_A 0 score URIBL_CSS_A 0 score URIBL_DBL_SPAM 0 score URIBL_DBL_PHISH 0 score URIBL_DBL_MALWARE 0 score URIBL_DBL_BOTNETCC 0 score URIBL_DBL_ABUSE_SPAM 0 score URIBL_DBL_ABUSE_REDIR 0 score URIBL_DBL_ABUSE_PHISH 0 score URIBL_DBL_ABUSE_MALW 0 score URIBL_DBL_ABUSE_BOTCC 0 oh, i bet spamhaus is still queryed sadly :( but with score 0 its not known or have any effect if yuo have bind installed then do "rndc querylog" this is a togle so one more call shift state of querylog, do "rndc status" to see current state veryfy now its does not query undesired rbls if you can verify this i can help solve the remaining problem
Re: excluding specific RBL checks
joe a skrev den 2023-01-08 21:50: SA version 3.4.5 Gears are clashing, clutch is slipping, among other things. Trying to exclude certain checks, via spamhouse services "by the book" what book ? When placing these values in local.cf: RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 "spamassassin --lint" complains. Yet SA starts without complaint and seems to not run those tests. you miss score in 3 lines ? Placing "score" at the beginning of the line makes lint happy and SA seems to start fine and also does not run those tests. so lint passed ? So, one assumes it is a typo in the docs, or, one is expected to infer the "score" word. what docs ? anythin on web is fake news, only valid docs is perldoc Mail::SpamAssassin::Conf and all related plugins Yet I still see this while "skip_rbl_checks 1" (in both above scenarios): clear your config :) "RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE:" Which suggests that one runs despite the directive or, I am using the wrong one. make /etc/resolv.conf only have nameserver 127.0.0.1 and you ether have bind, unbound, pdns-recursor as of your own choise still problems ?, lets hear them
Re: excluding specific RBL checks
What did you end up with? I have a bunch of zero rules for these yet still keep getting the "administrative notice" from sbl/zen. The fact that those guys don't just send out a "yes, this is on by default in spamassassin, here is copy pasta to turn us off" email bugs me. I've grown to this huge list and still get the warnings. # remove spamhaus tests, they want us to pay # need to include the first base rule or DNS still triggers but is ignored score __RCVD_IN_ZEN 0 score RCVD_IN_SBL 0 score RCVD_IN_XBL 0 score RCVD_IN_PBL 0 score URIBL_SBL 0 score URIBL_CSS 0 score URIBL_SBL_A 0 score URIBL_CSS_A 0 score URIBL_DBL_SPAM 0 score URIBL_DBL_PHISH 0 score URIBL_DBL_MALWARE 0 score URIBL_DBL_BOTNETCC 0 score URIBL_DBL_ABUSE_SPAM 0 score URIBL_DBL_ABUSE_REDIR 0 score URIBL_DBL_ABUSE_PHISH 0 score URIBL_DBL_ABUSE_MALW 0 score URIBL_DBL_ABUSE_BOTCC 0 Until I can get around to updating I'm considering just nuking the actual tests from the ruleset. Charles > On Jan 8, 2023, at 4:00 PM, joe a wrote: > > On 1/8/2023 3:50 PM, joe a wrote: >> SA version 3.4.5 >> Gears are clashing, clutch is slipping, among other things. >> Trying to exclude certain checks, via spamhouse services "by the book" >> When placing these values in local.cf: >> RCVD_IN_ZEN 0 >> RCVD_IN_XBL 0 >> RCVD_IN_PBL 0 >> "spamassassin --lint" complains. Yet SA starts without complaint and seems >> to not run those tests. >> Placing "score" at the beginning of the line makes lint happy and SA seems >> to start fine and also does not run those tests. >> So, one assumes it is a typo in the docs, or, one is expected to infer the >> "score" word. >> Yet I still see this while "skip_rbl_checks 1" (in both above scenarios): >> "RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE:" >> Which suggests that one runs despite the directive or, I am using the wrong >> one. > > And the answer to the latter is "I had the wrong directive". Which is > obvious. Now. >
Re: excluding specific RBL checks
On 1/8/2023 3:50 PM, joe a wrote: SA version 3.4.5 Gears are clashing, clutch is slipping, among other things. Trying to exclude certain checks, via spamhouse services "by the book" When placing these values in local.cf: RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 "spamassassin --lint" complains. Yet SA starts without complaint and seems to not run those tests. Placing "score" at the beginning of the line makes lint happy and SA seems to start fine and also does not run those tests. So, one assumes it is a typo in the docs, or, one is expected to infer the "score" word. Yet I still see this while "skip_rbl_checks 1" (in both above scenarios): "RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE:" Which suggests that one runs despite the directive or, I am using the wrong one. And the answer to the latter is "I had the wrong directive". Which is obvious. Now.
excluding specific RBL checks
SA version 3.4.5 Gears are clashing, clutch is slipping, among other things. Trying to exclude certain checks, via spamhouse services "by the book" When placing these values in local.cf: RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 "spamassassin --lint" complains. Yet SA starts without complaint and seems to not run those tests. Placing "score" at the beginning of the line makes lint happy and SA seems to start fine and also does not run those tests. So, one assumes it is a typo in the docs, or, one is expected to infer the "score" word. Yet I still see this while "skip_rbl_checks 1" (in both above scenarios): "RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE:" Which suggests that one runs despite the directive or, I am using the wrong one.
Re: Refused by block lists
On 1/8/2023 2:08 PM, Martin Gregorie wrote: On 07.01.23 14:06, joe a wrote: Pretty sure. Or, I was. Ran various tests with unbound running and not running confirmed it was working, at least providing a response. Thats pretty simple to check, provided you've got Wireshark installed: Fire it up and tell it to watch for DNS and/or blacklist lookup traffic on the appropriate ports. Then feed known spam to SA. Wireshark will show you if spam is causing external lookup requests to be generated, where they are being sent, and what replies are being received Martin Earlier I was going to do something like that, but at the firewall/router link to the cable modem. I wanted to be sure the "source IP" was the site static IP. A separate discussion uncovered I may have to register that IP with spamhaus.org. Registered years ago and stopped using it. Just now dawned that provider mergers cause my static IP's to change a few years back. Almost every day I pass a "beef farmer" whose ponds and field teem with Canadian Geese. Perhaps that should have been an omen?
Re: Refused by block lists
> > On 07.01.23 14:06, joe a wrote: > > > Pretty sure. Or, I was. Ran various tests with unbound running > > > and > > > not running confirmed it was working, at least providing a > > > response. > > Thats pretty simple to check, provided you've got Wireshark installed: Fire it up and tell it to watch for DNS and/or blacklist lookup traffic on the appropriate ports. Then feed known spam to SA. Wireshark will show you if spam is causing external lookup requests to be generated, where they are being sent, and what replies are being received Martin
Re: Looking for advice about limiting DNS queries
On 2023-01-06 at 17:23:50 UTC-0500 (Fri, 6 Jan 2023 16:23:50 -0600) Brian Conry 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 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
Re: Refused by block lists
On 1/8/2023 12:36 PM, Matus UHLAR - fantomas wrote: On 07.01.23 12:03, joe a wrote: Thanks. I think I actually got unbound working but still was getting URIBL rejects from spamhaus. On 1/7/2023 1:25 PM, Matus UHLAR - fantomas wrote: - do you actually use that unbound server? is 127.0.0.1 in /etc/resolv.conf? On 07.01.23 14:06, joe a wrote: Pretty sure. Or, I was. Ran various tests with unbound running and not running confirmed it was working, at least providing a response. providing answer to my second question would spare you from guessing. 127.0.0.1 is not in /etc/resolv.conf. I labor under the impression that telling unbound to accept query only on one IP and telling SA in local.cf "dns_server th.at.addr.ess" would cause it to use unbound.
Re: Refused by block lists
On 07.01.23 12:03, joe a wrote: Thanks. I think I actually got unbound working but still was getting URIBL rejects from spamhaus. On 1/7/2023 1:25 PM, Matus UHLAR - fantomas wrote: - do you actually use that unbound server? is 127.0.0.1 in /etc/resolv.conf? On 07.01.23 14:06, joe a wrote: Pretty sure. Or, I was. Ran various tests with unbound running and not running confirmed it was working, at least providing a response. providing answer to my second question would spare you from guessing. SA I told to use unbound via local.cf as well. Right now unbound is disabled and DNS is via "my old way". why? it can't be worse. - doesn't unbound forward queries to other (isp, open) resolvers? Not certain. The docs/examples seemed a bit sparse suggesting it does and exceptions needed to be specified for spamhaus (for example) but did not provide examples of how to do that. Some folks elsewhere seemed to suggest it would "just work". Likely I need to learn how to configure it properly? standard configuration should be enough, IF it's used at all. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Remember half the people you know are below average.
Re: Looking for advice about limiting DNS queries
On 1/8/2023 12:57 AM, Brian Conry wrote: ... Third, to expand on something I alluded to briefly, the emails in question are generated by a security appliance on our customer's network, in accordance with their security policy and posture. The warnings we're getting when our mail server performs these DNS queries are coming from _our_ network infrastructure, which is AWS. As I understand things, I have several options. ... No, there are more options than that; 210 by my count including hybrid solutions. Others here probably have more. For you, I recommend the use of Shortcircuiting in association with whitelist_from_rcvd. Make sure the Shortcircuit module is loaded. Check SA's v320.pre file. Then, In your local.cf add this: score USER_IN_WHITELIST -100 ifplugin Mail::SpamAssassin::Plugin::Shortcircuit shortcircuit USER_IN_WHITELIST on endif # Mail::SpamAssassin::Plugin::Shortcircuit whitelist_from_rcvd With SA v3.2, I personally don't trust the DKIM and SPF modules but if the offending security server emails pass DKIM/SPF checks, then you can play around with using the whitelist_auth function: whitelist_auth Now, your mail server is happy. Emails to the security people from any other source will be subjected to the full checks of SA, so they will be happy. The rest of your users will be happy. Keep it simple. Happiness abounds :)
Re: Looking for advice about limiting DNS queries
On 8/1/23 13:57, Brian Conry wrote: Hello again, I'm replying to my own message because I don't want to single out anyone who has already replied. There was value in each of your responses. This is going to be a long email, and for that you have my apologies, but I can't think of any way to make it shorter without it sounding like "dude, just trust me, I know what I'm doing", and I don't want to be that guy. Thank you for the time and thought that went into the replies. I sincerely appreciate your concern for the effectiveness of our spam filtering. One thing is clear to me from those response is that I did a poor job explaining the situation, and for that you also have my apologies. This is my attempt to correct that error. 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. Second, this recipient address is for a queue in an RTIR [1] installation for one of our hosted customers. The purpose of this queue is to receive reports of suspicious activity from elsewhere, and the queue is worked by trained security professionals. This address is already configured to receive all messages no matter what the spam score is. It is their job to look at them and assess whether or not it represents an incident, and if so what response is needed. Third, to expand on something I alluded to briefly, the emails in question are generated by a security appliance on our customer's network, in accordance with their security policy and posture. The warnings we're getting when our mail server performs these DNS queries are coming from _our_ network infrastructure, which is AWS. As I understand things, I have several options. Option 1) Do nothing with any configuration. We will continue to get notification from AWS of this suspicious activity, often several times in one day, that we then have to go and correlate with mail logs to confirm that the suspicious DNS queries were, in fact, related to the spam filtering of an email, and that the email in question was for this queue that is specifically for receiving that sort of content. The danger with this is that we will become lax in our checking of the mail logs and that this will essentially devolve into a variant on option 2, but with more work. Option 2) Tell our network monitoring (AWS) to ignore these findings for our mail servers. This seems fairly reasonable, as we know that our mail servers will make these queries semi-regularly as they are running the spam filtering on the messages for this recipient. The downside is that it will also turn off all notification to us if similar content were to be received at another address, potentially one that isn't handled by trained security professionals, or even if (heaven forbid) our mail servers were to be compromised by bitcoin mining malware. That last one shouldn't be possible due to other controls, but there's no denying that there is some added risk in auto-ignoring these warnings. Option 3) Skip all spam checking for this recipient. It is, after all, associated with an incident response queue, expected to receive email messages with body content that contains names of, or even links directly to, known malware domains, and is staffed by security professionals. And yet, this all-or-nothing approach feels like it's sacrificing some possible good, which leads to my questions regarding a hypothetical Option 4. Option 4) Targeted disabling of specific checks for this _one_ recipient that preserves as much value as possible for the remaining checks. I think there are several variants here, and this is where I know that I don't have the expertise necessary to make the optimal decision. From what I can tell from the reports, the only queries that are triggering the security alert for our mail servers are the ones made for records in the (known malware) domain or one of its subdomains. In the debug logs that I inspected there were three queries: 1) malwaredomain.com/A 2) subdomain.malwaredomain.com/A 3) malwaredomain.com/NS As best as I can tell, the results of these queries were all used for additional DNSRBL queries, but if AWS is noticing that part of the context they aren't letting on. Variant A) disable all DNSRBL checks. :( Variant B) disable only those RBLs that ask for the information that triggers these queries. This is an improvement, but it also skips those same checks on everything in the message headers. Variant C) disable some/most/all checks for names found only in the message body. This would provide full checking of all names found in the headers and skip only that content in which we expect to find trouble. I believe I can do variants A) and B), so worst case would be choosing B, but I'm willing to put in some additional work to implement variant C) if that is possible. If
