-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-01-07 a las 14:54 +0100, Carlos E. R. escribió:
El 2023-01-07 a las 13:01 +0100, Per Jessen escribió:
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 From: opensuse.org <no-reply@opensuse.org> To: opensuse-project@opensuse.org Subject: (8) Incoming mails are pending ... 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] - -0.4 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [195.135.221.145 listed in list.dnswl.org] - -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] - -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 URI_NOVOWEL URI: URI hostname has long non-vowel sequence 0.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.2 HTML_MESSAGE BODY: HTML included in message 0.1 RCVD_IN_SBL RBL: Received via a relay in Spamhaus SBL [84.21.172.201 listed in zen.spamhaus.org] 3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS - -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 2.7 GOOG_REDIR_NORDNS Google redirect to obscure spamvertised website + no rDNS 2.5 URIBL_DBL_SPAM Contains a spam URL listed in the Spamhaus DBL blocklist [URIs: w3s.link] 0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: ipfs.io, w3s.link] 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: w3s.link] Ok, so the score is zero, which in a way does not affect me, but I'm wasting time doing such queries. spamhaus and URIBL. This must be affecting any openSUSE user that uses SA in default configuration. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY7l8HRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVtcgAoIYeW78zX5Zv89hreiG0 7Q1R5UThAJ4xVKEUrzagvvWWbczk9SPLZNMMNA== =ypOx -----END PGP SIGNATURE-----
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.
From: opensuse.org <no-reply@opensuse.org> To: opensuse-project@opensuse.org Subject: (8) Incoming mails are pending
...
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? -- Per Jessen, Zürich (9.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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 <no-reply@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-checks-in-spamassassin.2533/> +++······················ 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)
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.
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.
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. -- Per Jessen, Zürich (7.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
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." -- Per Jessen, Zürich (8.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
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 https://www.dnswl.org/, * high trust * [209.85.208.177 listed in list.dnswl.org] * -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) * [209.85.208.177 listed in wl.mailspike.net] * 1.0 FREEMAIL_FROM Sender email is commonly abused enduser mail * provider * [x.xx[at]gmail.com] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) * 0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or * identical to background * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid . . . * 0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to * dbl.spamhaus.org was blocked due to usage of an open resolver. * See https://www.spamhaus.org/returnc/pub/ * [URIs: sophos.com] * 0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to * zen.spamhaus.org was blocked due to usage of an open resolver. * See https://www.spamhaus.org/returnc/pub/ * [URIs: sophos.com]
-----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-checks-in-spamassassin.2533/> 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 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). I may have confused this with the URIBL checks as I was enabling and disabling them both while testing.
The link says that the names can change. And the link is dated 2010.
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
These I found in "/var/lib/spamassassin/3.004005/updates_spamassassin_org/20_dnsbl_tests.cf" I'll test a bit more after a break. Trying to do this and several other things at once. On the bright side, I did get updated to 15.4. Luckily I took a snapshot before as I forgot all my systemd hack jobs would be gone and had to go fish them out. Yeah I keep good notes. Thanks to VMWARE anyway.
-- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar)
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 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:
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.
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?
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 1/8/2023 3:18 PM, Carlos E. R. wrote:
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.
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. It may be a typo in the docs, or like many things, the author assumes certain knowledge.
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 6:29 PM, Carlos E. R. wrote:
On 2023-01-08 22:02, joe a wrote: . . .
Now trying with:
CVD_IN_ZEN 0 RCVD_IN_XBL 0 RCVD_IN_PBL 0
I set that in local.cf
<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
I see the same thing, but says in "/etc/mail/spamassassin/local.cf": Well. I see it now that I look for it. Sheesh.
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
Yeah, I mentioned that on the SA list. Don't you lurk there too? joe a.
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.
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. What does that?
I don't even see "dns_query" in <https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html>. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
"CER" == Carlos E R <robin.listas@telefonica.net> 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!
On 2023-01-09 12:38, Togan Muftuoglu wrote:
"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
Because that's a hidden manual. :-/ dns_query_restriction (allow|deny) domain1 domain2 ... Option allows disabling of rules which would result in a DNS query to one of the listed domains. The first argument must be a literal "allow" or "deny", remaining arguments are domains names. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
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
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. Telcontar:~ # man spamassassin Man: find all matching manual pages (set MAN_POSIXLY_CORRECT to avoid this) * spamassassin (1) spamassassin (3pm) Man: What manual page do you want? Man: Telcontar:~ # man 3pm spamassassin No manual entry for spamassassin in section 3pm Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
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 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. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Mon, 9 Jan 2023 15:46:14 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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 :)
...
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 :)
I recently had someone refer me to perldoc with similar notation. Ignorant me, I hit the search engined for "perldoc" and was led to https://perldoc.perl.org/. Which did not help, finding nothing related to my search. So, I ran down other paths. Now I know that uttering "perldoc" at a Linux prompt provides interesting reading for the (relative) novice. Thanks to all contributors for my enlightenment.
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 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.
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)
On 2023-01-09 04:33, joe a wrote:
On 1/8/2023 6:29 PM, Carlos E. R. wrote:
On 2023-01-08 22:02, joe a wrote: . . .
So it has to be:
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? No, I haven't touched SA for a decade at least :-)
It just worked. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (6)
-
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
joe a -
Per Jessen -
Togan Muftuoglu