On 2023-01-07 15:24, Per Jessen wrote:
Carlos E. R. wrote:
Anyway, grepping on /var/log/mail-202301*.xz doesn't find "spamhaus" or "open resolver", so that is not my problem.
But it is!
I just looked in my spam folder, which contains only 8 emails after that long processing, and one of them has:
Date: 30 Nov 2022 02:40:30 -0800
Just a remark - running anything that old through SA is usually pointless or at best unreliable.
It was an experiment. The folder should be clean. There were mails from 2020 in it, but I did not thing it would be an issue.
From: opensuse.org
To: opensuse-project@opensuse.org Subject: (8) Incoming mails are pending
You remember this one, surely :-)
...
Content analysis details: (7.4 points, 5.0 required)
pts rule name description - ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [195.135.221.145 listed in [zen.spamhaus.org]
This is almost certainly a red herring, 195.135.221.145 is an opensuse machine ("anna") in Nuernberg. I had a ticket like this not long ago, I think it is Spamhaus refusing your lookup due to excessive number of queries. Just a hunch.
but I'm wasting time doing such queries. spamhaus and URIBL.
You can simply disable them.
This must be affecting any openSUSE user that uses SA in default configuration.
Possibly, but what is the problem?
That we are spamming spamhaus? :-D It is not a problem for me, because the clever folk at SA detect that error message of "open resolver" and handle it with a score of zero. But the queries are sent, none the less. Maybe, I could do something to my dnsmasq to obviate the forwarders and do direct queries for these. You mentioned server=/infra.opensuse.org/nn.nn.nn.nn syntax. Instead of that, give the address as a name, perhaps. And what name? server=/zen.spamhaus.org/... No, manual says an IP is expected. -S, --local, --server=[/[<domain>]/[do- main/]][<ipaddr>[#<port>]][@<inter- face>][@<source-ip>[#<port>]] Specify IP address of upstream servers directly. Setting this flag does not suppress reading of /etc/resolv.conf, use --no-resolv to do that. If one or more optional domains are given, that server is used only for those domains and they are queried only using the specified server. This is intended for private nameservers: if you have a nameserver on your network which deals with names of the form xxx.inter- nal.thekelleys.org.uk at 192.168.1.1 then giving the flag --server=/inter- nal.thekelleys.org.uk/192.168.1.1 will send all queries for internal machines to that nameserver, everything else will go to the servers in /etc/re- solv.conf. DNSSEC validation is turned off for such private nameservers, UN- LESS a --trust-anchor is specified for the domain in question. An empty do- main specification, // has the special meaning of "unqualified names only" ie names without any dots in them. A non- standard port may be specified as part of the IP address using a # character. More than one --server flag is al- lowed, with repeated domain or ipaddr parts as required. More specific domains take precedence over less specific domains, so: --server=/google.com/1.2.3.4 --server=/www.google.com/2.3.4.5 will send queries for google.com and gmail.google.com to 1.2.3.4, but www.google.com will go to 2.3.4.5 Matching of domains is normally done on complete labels, so /google.com/ matches google.com and www.google.com but NOT supergoogle.com. This can be overridden with a * at the start of a pattern only: /*google.com/ will match google.com and www.google.com AND su- pergoogle.com. The non-wildcard form has priority, so if /google.com/ and /*google.com/ are both specified then google.com and www.google.com will match /google.com/ and /*google.com/ will only match supergoogle.com. For historical reasons, the pattern /.google.com/ is equivalent to /google.com/ if you wish to match any subdomain of google.com but NOT google.com itself, use /*.google.com/ The special server address '#' means, "use the standard servers", so --server=/google.com/1.2.3.4 --server=/www.google.com/# will send queries for google.com and its subdo- mains to 1.2.3.4, except www.google.com (and its subdomains) which will be forwarded as usual. Also permitted is a -S flag which gives a domain but no IP address; this tells dnsmasq that a domain is local and it may answer queries from /etc/hosts or DHCP but should never forward queries on that domain to any upstream servers. --local is a syn- onym for --server to make configura- tion files clearer in this case. IPv6 addresses may include an %inter- face scope-id, eg fe80::202:a412:4512:7bbf%eth0. The optional string after the @ char- acter tells dnsmasq how to set the source of the queries to this name- server. It can either be an ip-ad- dress, an interface name or both. The ip-address should belong to the ma- chine on which dnsmasq is running, otherwise this server line will be logged and then ignored. If an inter- face name is given, then queries to the server will be forced via that in- terface; if an ip-address is given then the source address of the queries will be set to that address; and if both are given then a combination of ip-address and interface name will be used to steer requests to the server. The query-port flag is ignored for any servers which have a source address specified but the port may be speci- fied directly as part of the source address. Forcing queries to an inter- face is not implemented on all plat- forms supported by dnsmasq. so: server=/zen.spamhaus.org/... But what IP? I don't know what queries is SA sending. cer@Telcontar:~> host -v zen.spamhaus.org Trying "zen.spamhaus.org" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65302 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;zen.spamhaus.org. IN A ;; AUTHORITY SECTION: zen.spamhaus.org. 10 IN SOA need.to.know.only. hostmaster.spamhaus.org. 2301071915 3600 600 432000 10 ... cer@Telcontar:~> host zen.spamhaus.org cer@Telcontar:~> No DNS over there :-? And the syntax for dnsmasq doesn't have a provision for using the root servers and down from there. Disable the tests? If that is the only way, yes. https://www.emailquestions.com/threads/how-to-disable-spamhaus-and-other-rbl... +++······················ To disable the Spamhaus RBL's add these lines to your local.cf : RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 The names of the individual RBL checks may change over time so be sure to keep an eye on them after upgrades. ······················++- AFAIK that doesn't disable the test, it disables its results. The tests are still done, so it is useless. There is: +++······················ To disable all RBL's add this line to your local.cf : skip_rbl_checks 1 ······················++- which disables ALL, not only those from Spamhaus. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)