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)

On 2023-01-07 20:47, Per Jessen wrote:

Carlos E. R. wrote:

...

...

...

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

Well, _we_ are not - at most, some of our users' nameservers are. Besides, it's nothing new.

We "users" ;-)

...

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.

In the ticket I looked at, spamhaus delivered a correct code, indicating "excessive queries". A code that doesn't produce any score.

FYI, there is no open resolver on 195.135.221.145 - hence my suggestion that it is a red herring. The wrong error message.

...

But the queries are sent, none the less.

Yup. As expected.

...

Maybe, I could do something to my dnsmasq to obviate the forwarders and do direct queries for these. [snip] And the syntax for dnsmasq doesn't have a provision for using the root servers and down from there.

Dunno, it is possible that dnsmasq simply doesn't support such a setup - dnsmasq is called "a light-weight DNS forwarder", so maybe it does not support the full lookup process itself.

Which is then what joe said, that bind has to be used for this. I can, I think, forward those queries to my miniserver computer which runs bind, and in this one use the root servers chain. I can do that on my next huge mail folder scan, which is not yet prepared.

...

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.

No, it disables the test.

Are you sure? I can do that an rerun the folder scan, discarding the mails (they are already sorted). See if there is a speed difference. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-01-08 09:57, Per Jessen wrote:

Carlos E. R. wrote:

...

...

...

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.

No, it disables the test.

Are you sure?

Yes, that why I wrote it. It is also explained in the SpamAssassion documentation:

https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html "Setting a rule's score to 0 will disable that rule from running."

Ok, that's perfect :-) Thanks for remembering. I did read it, but long ago. My recollection was different. I even have a local copy of the file: ~/Documentation/Mail/SpamAssassin-3.1_doc/Mail_SpamAssassin_Conf.html Curious. Searching in zypper to see if there was a separate documentation package, what I found instead was a spamassassin-spamc package. Turns out that it comes from repo OBS:devel:languages:perl, while the oss spamassassin package contains spamc. But one is version 3.4.5 and the other is version 4.0.0. Not going to try. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2023-01-08 at 12:20 -0500, joe a wrote:

On 1/7/2023 2:47 PM, Per Jessen wrote:

...

. . .

...

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.

No, it disables the test.

My results do not indicated the tests are stopped, given the results (snipped) below:

* 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/ * [209.85.208.177 listed in zen.spamhaus.org] * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at

Right, if you get that, the tests are done. Ok, where have you written: RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 ? The link says that the names can change. And the link is dated 2010. https://www.emailquestions.com/threads/how-to-disable-spamhaus-and-other-rbl... It might be (looking at /var/lib/spamassassin/3.004005/updates_spamassassin_org/20_dnsbl_tests.cf): __RCVD_IN_ZEN 0 RCVD_IN_SBL 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 maybe RCVD_IN_SBL_CSS 0 - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY7sMThwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVA9gAn05aDR9h9FVI9f8+0E5p tnAZJm3tAJ9xNVHS6DuM8MMKWzhWSR/S8js55g== =fZc6 -----END PGP SIGNATURE-----

On 2023-01-08 19:55, joe a wrote:

On 1/8/2023 1:32 PM, Carlos E. R. wrote:

...

On Sunday, 2023-01-08 at 12:20 -0500, joe a wrote:

...

On 1/7/2023 2:47 PM, Per Jessen wrote:

...

. . .

...

 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.

 No, it disables the test.

...

My results do not indicated the tests are stopped, given the results (snipped) below:

...

*  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/      *      [209.85.208.177 listed in zen.spamhaus.org]      * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at

Right, if you get that, the tests are done.

Ok, where have you written:

RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0

?

local.cf in the form "score RCVD_IN_ZEN 0" (etc).

AH, no. Take out that "score" word. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-01-08 20:41, joe a wrote:

On 1/8/2023 2:20 PM, Carlos E. R. wrote:

...

On 2023-01-08 19:55, joe a wrote:

...

On 1/8/2023 1:32 PM, Carlos E. R. wrote:

...

...

...

...

Ok, where have you written:

RCVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0

?

local.cf in the form "score RCVD_IN_ZEN 0" (etc).

AH, no. Take out that "score" word.

I should have said in last post, spamassassin --lint did not like them without "score".

"Jan  8 14:07:49.688 [14529] warn: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": RCVD_IN_ZEN 0 Jan  8 14:07:50.519 [14529] warn: lint: 1 issues detected, please rerun with debug enabled for more information"

Should they be somewhere else?

The link said there. I was going to try ~/.spamassassin/user_prefs. I use the spamc/spamd pair. I just wrote the tokens and restarted spamd, no complaints so far. I then undid and tried /etc/mail/spamassassin/local.cf. Restarting the service works fine, but --lint complains. So I do not know. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-01-08 22:02, joe a wrote:

On 1/8/2023 3:18 PM, Carlos E. R. wrote:

...

On 2023-01-08 20:41, joe a wrote:

...

...

So I do not know.

Posting that on the SA list.  I find it works the same with or without "score", so will go with that as it makes lint happy.  Odd that lint complains, yet SA does not.

Ok, when you get an answer there, please tell here :-) On the other hand, I'm processing 1003 of the same mails (including 3 that are spam), using dnsmasq and bind, with the no forwarding trick, and I don't get the "open resolver" error from SA. But I see instead hundreds of errors in the machine running bind, it can not resolve many domains, others timeout. The original run did 81376 mails in 2217m21,9s, thus 36.7 mails per minute. Now I did 1003 mails in 1521 seconds, thus 39.6 mails per minute. Just a little bit faster (but might be because the procmail test file is much shorter). Now trying with: CVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0 in .spamassassin/user_prefs [...] Ok, 1528S. No difference. 39.6 mails/minute. Then I looked into the mail log: <2.6> 2023-01-08T22:54:36.237088+01:00 Telcontar spamd 17988 - - config: failed to parse line, skipping, in "/home/cer/.spamassassin/user_prefs": RCVD_IN_ZEN 0 <2.6> 2023-01-08T22:54:36.237228+01:00 Telcontar spamd 17988 - - config: failed to parse line, skipping, in "/home/cer/.spamassassin/user_prefs": RCVD_IN_XBL 0 <2.6> 2023-01-08T22:54:36.237356+01:00 Telcontar spamd 17988 - - config: failed to parse line, skipping, in "/home/cer/.spamassassin/user_prefs": RCVD_IN_PBL 0 So that method does not work. And nullifying the results is pointless, too. [...] DOH! The documentation says: Setting a rule's score to 0 will disable that rule from running. https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html So it has to be: score RCVD_IN_ZEN 0 score RCVD_IN_XBL 0 score RCVD_IN_PBL 0 Testing again. 1512s, so 39.8 mails per minute. Barely an effect. Ok, let's kill all remote tests. skip_rbl_checks 1 Now it is 1334s, so 45.1 mails per minute. Well, that's faster, but not a lot of improvement. The next step is parallelize. It is easy to do with postfix, but in my case I'm post processing and not using postfix. But in fact, I can skip the spam checking and do only the sorting part, but that's my particular situation, doesn't help you. I was just doing tests of SA. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 1/8/2023 10:33 PM, joe a wrote:

On 1/8/2023 6:29 PM, Carlos E. R. wrote: . . .

...

score RCVD_IN_ZEN 0 score RCVD_IN_XBL 0 score RCVD_IN_PBL 0

Yeah, I mentioned that on the SA list. Don't you lurk there too?

joe a.

Speaking of which, this just in: "Much easier and reliable way: "dns_query_restriction deny spamhaus.org"" In local.cf, for me. Now, I think that is in the docs as well, but, it never registered, with me. Apparently. joe a.

...

...

...

...

"CER" == Carlos E R writes:

CER> On 2023-01-09 05:19, joe a wrote: >> On 1/8/2023 10:33 PM, joe a wrote: >>> On 1/8/2023 6:29 PM, Carlos E. R. wrote: >> . . . >>>> >>>> score RCVD_IN_ZEN 0 score RCVD_IN_XBL 0 score RCVD_IN_PBL 0 >>> >>> Yeah, I mentioned that on the SA list. Don't you lurk there too? >>> >>> joe a. >> Speaking of which, this just in: "Much easier and reliable way: >> "dns_query_restriction deny spamhaus.org"" In local.cf, for me. Now, I >> think that is in the docs as well, but, it never registered, with me. >> Apparently. CER> What does that? CER> I don't even see "dns_query" in CER> https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html. why don't you simply check the man page of your installation for a better answer man Mail::SpamAssassin::Conf -- Life is endless possibilities, and there is choice!

Carlos E.R. wrote:

On 2023-01-09 12:38, Togan Muftuoglu wrote:

...

why don't you simply check the man page of your installation for a better answer

man Mail::SpamAssassin::Conf

Because that's a hidden manual. :-/

Hidden? man -k spamassassin -- Per Jessen, Zürich (7.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-01-09 14:23, Per Jessen wrote:

...

Carlos E.R. wrote:

...

On 2023-01-09 12:38, Togan Muftuoglu wrote:

...

why don't you simply check the man page of your installation for a better answer

man Mail::SpamAssassin::Conf

Because that's a hidden manual. :-/

Hidden?

man -k spamassassin

I simple do man spamassassin. That's what I expect to just work. Not a weird syntax with colons.

Where have you been for the last twenty years? :-) It is the perfectly normal naming for perl modules / extensions. -- Per Jessen, Zürich (7.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On Mon, 9 Jan 2023 15:46:14 +0100 "Carlos E. R." wrote:

On 2023-01-09 15:39, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-01-09 14:23, Per Jessen wrote:

...

Carlos E.R. wrote:

...

On 2023-01-09 12:38, Togan Muftuoglu wrote:

...

why don't you simply check the man page of your installation for a better answer

man Mail::SpamAssassin::Conf

Because that's a hidden manual. :-/

Hidden?

man -k spamassassin

I simple do man spamassassin. That's what I expect to just work. Not a weird syntax with colons.

Where have you been for the last twenty years? :-) It is the perfectly normal naming for perl modules / extensions.

Grrr. I don't write Perl. :-)

Of course I have seen that syntax before, but it just doesn't stick in my memory.

I don't have spamassassin installed so I don't have its man page locally but when I do man spamassassin online I get the (1) version and near the top it says: Synopsis For ease of access, the SpamAssassin manual has been split up into several sections. If you're intending to read these straight through for the first time, the suggested order will tend to reduce the number of forward references. Extensive additional documentation for SpamAssassin is available, primarily on the SpamAssassin web site and wiki. You should be able to view SpamAssassin's documentation with your man(1) program or perldoc(1). OVERVIEW spamassassin SpamAssassin overview (this section) CONFIGURATION Mail::SpamAssassin::Conf SpamAssassin configuration files USAGE ... So I don't see why you think it's hidden? And the mention of perldoc is a strong hint to the syntax. Methinks you do protest too much :)

On 2023-01-09 16:15, Dave Howorth wrote:

On Mon, 9 Jan 2023 15:46:14 +0100 "Carlos E. R." <> wrote:

...

On 2023-01-09 15:39, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-01-09 14:23, Per Jessen wrote:

...

Carlos E.R. wrote:

...

On 2023-01-09 12:38, Togan Muftuoglu wrote: > why don't you simply check the man page of your installation > for a better answer > > man Mail::SpamAssassin::Conf

Because that's a hidden manual. :-/

Hidden?

man -k spamassassin

I simple do man spamassassin. That's what I expect to just work. Not a weird syntax with colons.

Where have you been for the last twenty years? :-) It is the perfectly normal naming for perl modules / extensions.

Grrr. I don't write Perl. :-)

Of course I have seen that syntax before, but it just doesn't stick in my memory.

I don't have spamassassin installed so I don't have its man page locally but when I do man spamassassin online I get the (1) version and near the top it says:

You know that once a man is read, say two decades ago, it is never read again complete, just the sections one is looking for ;-)

OVERVIEW

spamassassin SpamAssassin overview (this section)

CONFIGURATION

Mail::SpamAssassin::Conf SpamAssassin configuration files

USAGE

Yet Another Documentation System :-D

...

So I don't see why you think it's hidden? And the mention of perldoc is a strong hint to the syntax. Methinks you do protest too much :)

perldoc means something to those that speak perl :-p Yes, I am old. I grumble. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-01-09 16:21, joe a wrote:

On 1/9/2023 9:39 AM, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-01-09 14:23, Per Jessen wrote:

...

Carlos E.R. wrote:

...

On 2023-01-09 12:38, Togan Muftuoglu wrote:

...

why don't you simply check the man page of your installation for a better answer

man Mail::SpamAssassin::Conf

Because that's a hidden manual. :-/

Hidden?

man -k spamassassin

I simple do man spamassassin. That's what I expect to just work. Not a weird syntax with colons.

Where have you been for the last twenty years? :-)  It is the perfectly normal naming for perl modules / extensions.

I'm pretty sure he's not the only one that did not know that, regardless been "been around" time.

Me, I only look at Perl when necessary and do not recall that convention.  But then, not everything can be recalled at all times.

That's correct. Of course I have used "man Mail::SpamAssassin::Conf" sometime in the past, even perldoc. But one forgets. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)