AW: AW: RCVD_IN_RP_CERTIFIED always -3
Thanks a lot fantomas :-) The cron I will activate. I have a local dns server running which postfix and SA are using. -Ursprüngliche Nachricht- Von: Matus UHLAR - fantomas [mailto:uh...@fantomas.sk] Gesendet: Freitag, 7. Juni 2024 12:38 An: users@spamassassin.apache.org Betreff: Re: AW: RCVD_IN_RP_CERTIFIED always -3 On 06.06.24 21:17, hostmas...@audiogen.ch wrote: >I just got the latest rules. >I'm okay with poor performance for some of the rules as there isn't much >load on the related system. >And yes, you're right, on Ubuntu 20.04.06 the rules are installed in >/usr/share/spamassassin. >sa-update has placed the updated rules in /var/lib/spamassassin. I kept >usr/share/spamassassin for the moment as if I got it right, /var/lib will >have priority over /usr/share. >Seems to work so far, however I will check the logs in a couple of days to >validate it's actually running smoothly. you should enable automatic rule updates in /etc/default/spamassassin: CRON=1 As another general recommendation, run local caching non-forwarding DNS server on mail server and don't use public DNS resolvers: https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver -- 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. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
AW: RCVD_IN_RP_CERTIFIED always -3
Thanks Bill. No worries, i did not use GitHub. The only reason I posted that link was to proof that Harald guy wrong who claimed there was no RCVD_IN_RP_CERTIFIED rule. The reason to stick with 3.4.4 is simple: Ubuntu 20.04.06 LTS has not upgraded to 4.0.0. Since I'd like to stick with the distribution, the migration path will rather be to a newer Ubuntu LTS than to manually update SA to 4.0.0. It's one of this trade-off situations. And since I only run a small installation and all the anti-spam measures are working great (even with the old version and rules - the postfix checks and the RBLs do such a great job that SA doesn't get too much todo), there is no instant need to upgrade. However, I was not aware the 4.x rules are backward compatible (with some exceptions as I learned from this list). I run sa-update and it worked. It's a bit confusing that SA 3.4.4 is creating a 3.004004 directory (obv. it's taking its application version by default) to store the 4.x rules. I run a short diff against github to validate the rules are the same. -Ursprüngliche Nachricht- Von: Bill Cole [mailto:sausers-20150...@billmail.scconsult.com] Gesendet: Freitag, 7. Juni 2024 23:28 An: users@spamassassin.apache.org Betreff: Re: RCVD_IN_RP_CERTIFIED always -3 On 2024-06-06 at 12:08:54 UTC-0400 (Thu, 6 Jun 2024 18:08:54 +0200) is rumored to have said: > Thanks for your answer Harald. > > Regarding "there is no such configuration option in SpamAssassin": The conf snipplet I posted below comes from the repository, however it's an older version, which still is supported by Ubuntu 20.04.06 LTS and can be installed from their related archive (at least my rules where last updated in March 23). > https://github.com/apache/spamassassin/blob/spamassassin_release_3_4_4/trunk -only/rules/20_dnsbl_tests.cf (the same is used up to 3.4.6) Note that the Github repository is a courtesy replica for people who don't want to learn Subversion, and it is NOT authoritative. We do not support using Github to install SpamAssassin in any way. You can try it but you're on your own. As for grabbing rules from ancient history in Github, that is just a recipe for disaster. The rules are updated daily and packaged for distribution directly from the ASF and our SA-only mirrors using sa-update. Rules change for many different reasons, including changes in how 3rd-party data providers like Validity (formerly ReturnPath) operate. > I should have written I'm on an older Ubuntu, might have helped to avoid confusion. If Ubuntu told you to update rules from Github, you should consider a better distro... (I strongly doubt that they did...) > Regarding the SpamAssassin 4.x rules - are they backward compatible to 3.4.4? Yes. As well-documented in the SpamAssassin documentation, the correct way to keep your rules and their scores up-to-date is to run the sa-update tool daily. It is part of the distribution. Rules in the standard "updates.spamassassin.org" channel are maintained to be backwards compatible, with rules that use newer features being tested for availability before load. HOWEVER: Running 3.4.4 is a bad idea. Unless it has extensive backports of patches from more modern versions, it is going to miss a lot of spam and run very inefficiently. This is especially true if you use rulesets from that era, which have known (and fixed in trunk) runaway problems and obsolete DNSBL configs. There may also be a problem running sa-update from 3.4.4 because we have abandoned SHA1 signatures. I'm not sure if 3.4.4 included the changes that switch to more secure hashes. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: [mailop] SORBS Closing.
On 2024-06-06 at 19:53:02 UTC-0400 (Thu, 6 Jun 2024 19:53:02 -0400) J Doe is rumored to have said: [...] > Hi Rob and list, > > Speaking as a small user of SORBS via SpamAssassin 4.0, I assume the > correct response to disable use of SORBS is to place the following in my > local.cf file: > > dns_query_restriction deny sorbs.net > > Is that correct and is there any additional portions of local.cf I need > to configure so that I am no longer consulting SORBS ? You do not even need to do that. All SORBS-referencing rules were removed from the updates.spamasssassin.org rules channel earlier this week. Scanning the latest deployed (by sa-update) version r1918114 I see no surviving references to SORBS. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: RCVD_IN_RP_CERTIFIED always -3
On 2024-06-06 at 12:08:54 UTC-0400 (Thu, 6 Jun 2024 18:08:54 +0200) is rumored to have said: > Thanks for your answer Harald. > > Regarding "there is no such configuration option in SpamAssassin": The conf > snipplet I posted below comes from the repository, however it's an older > version, which still is supported by Ubuntu 20.04.06 LTS and can be installed > from their related archive (at least my rules where last updated in March 23). > https://github.com/apache/spamassassin/blob/spamassassin_release_3_4_4/trunk-only/rules/20_dnsbl_tests.cf > (the same is used up to 3.4.6) Note that the Github repository is a courtesy replica for people who don't want to learn Subversion, and it is NOT authoritative. We do not support using Github to install SpamAssassin in any way. You can try it but you're on your own. As for grabbing rules from ancient history in Github, that is just a recipe for disaster. The rules are updated daily and packaged for distribution directly from the ASF and our SA-only mirrors using sa-update. Rules change for many different reasons, including changes in how 3rd-party data providers like Validity (formerly ReturnPath) operate. > I should have written I'm on an older Ubuntu, might have helped to avoid > confusion. If Ubuntu told you to update rules from Github, you should consider a better distro... (I strongly doubt that they did...) > Regarding the SpamAssassin 4.x rules - are they backward compatible to 3.4.4? Yes. As well-documented in the SpamAssassin documentation, the correct way to keep your rules and their scores up-to-date is to run the sa-update tool daily. It is part of the distribution. Rules in the standard "updates.spamassassin.org" channel are maintained to be backwards compatible, with rules that use newer features being tested for availability before load. HOWEVER: Running 3.4.4 is a bad idea. Unless it has extensive backports of patches from more modern versions, it is going to miss a lot of spam and run very inefficiently. This is especially true if you use rulesets from that era, which have known (and fixed in trunk) runaway problems and obsolete DNSBL configs. There may also be a problem running sa-update from 3.4.4 because we have abandoned SHA1 signatures. I'm not sure if 3.4.4 included the changes that switch to more secure hashes. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: AW: RCVD_IN_RP_CERTIFIED always -3
On 06.06.24 21:17, hostmas...@audiogen.ch wrote: I just got the latest rules. I'm okay with poor performance for some of the rules as there isn't much load on the related system. And yes, you're right, on Ubuntu 20.04.06 the rules are installed in /usr/share/spamassassin. sa-update has placed the updated rules in /var/lib/spamassassin. I kept usr/share/spamassassin for the moment as if I got it right, /var/lib will have priority over /usr/share. Seems to work so far, however I will check the logs in a couple of days to validate it's actually running smoothly. you should enable automatic rule updates in /etc/default/spamassassin: CRON=1 As another general recommendation, run local caching non-forwarding DNS server on mail server and don't use public DNS resolvers: https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver -- 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. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
Re: TxRep does not evaluate EMAIL_IP reputation
Thanks for the reply. I will try to register it in bugzilla little by little. 2024-06-03 17:04 に giova...@paclan.it さんは書きました: On 6/3/24 1:10 AM, Tomohiro Hosaka wrote: Slight correction. 2024-06-03 07:55 に Tomohiro Hosaka さんは書きました: Here $rc is dualvar. https://metacpan.org/pod/DBI#execute This is not dualvar, exactly. However, the patch is unchanged. Evaluated as a bool, it is "0E0" true; evaluated as a number, it is the number of cases. You may use $cnt for more simplicity. Hi, could you please open bug reports on https://bz.apache.org/SpamAssassin/ so that we can track them ? Thanks Giovanni
