Re: Fwd: [mailop] SORBS Closing.
On 2024-06-05 04:44, Rob McEwen via users wrote: From "Frido Otten" mailto:fr...@0tten.nl>> So is there anything that needs to be done to prevent false positives happening right after the shutdown? They said they were emptying the zone files, not actually "listing the world" - so this shouldn't cause false any positives - but might cause some false negatives, especially for anyone who was overly relying on SORBS in their spam filtering? But yet - after some years - lists like this - once they've been dead for many many years - do /sometimes/ "list the world" as a final push to get others to stop using them - if that even ever happens with SORBS? And if it ever did, I doubt that would happen anytime soon. But definately make sure that your spam filter is ONLY ever acting on specific and valid SORBS return codes - and NOT treating ANY query being resolved that isn't NXDOMAIN - as a listing. Anyone */misusing/* SORBS in that way - might one day have a very bad day. But that's a general truth for all DSNBLs - make sure your rules/setup for its usage only treat it as a valid listing when specific return codes are returned, that match that DNSBL's instructions, and thus */NOT/* taking action just because /some /IP address was resolved by the query. /(I think any built-in/default SpamAssassin rules for SORBS - already does all of this correctly.)/ Rob McEwen, invaluement 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 ? Thanks, - J
AW: RCVD_IN_RP_CERTIFIED always -3
Thanks a lot Kris.
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.
Mark
-Ursprüngliche Nachricht-
Von: Kris Deugau [mailto:kdeu...@vianet.ca]
Gesendet: Donnerstag, 6. Juni 2024 19:48
An: users@spamassassin.apache.org
Betreff: Re: RCVD_IN_RP_CERTIFIED always -3
hostmas...@audiogen.ch wrote:
> I found the related
> configuration in 20_dnsbl_tests.cf:
>
> /#
>
---/
>
> /# Return Path Certified:/
>
> /# https://www.returnpath.net/internetserviceprovider/certification//
>
> /# (replaces RCVD_IN_BSP_TRUSTED, RCVD_IN_BSP_OTHER,
> RCVD_IN_SSC_TRUSTED_COI)/
>
> /header RCVD_IN_RP_CERTIFIED eval:check_rbl_txt('ssc-firsttrusted',
> 'sa-trusted.bondedsender.org.')/
>
> /describe RCVD_IN_RP_CERTIFIED Sender in ReturnPath Certified -
> Contact cert...@returnpath.net/
>
> /tflags RCVD_IN_RP_CERTIFIED net nice/
>
> /reuse RCVD_IN_RP_CERTIFIED/
These were renamed/rebranded some time ago. Run sa-update to get
current rules.
Note that the live rules your system references should be under
/var/lib/spamassassin on most systems. Some distribution packages will
also ship a rules snapshot in /usr/share/spamassassin, however these
should be considered more or less unusable unless you are trying to run
SA in a very extremely security-restricted environment.
> Regarding the SpamAssassin 4.x rules - are they backward compatible to
3.4.4?
Pretty much, although rules that rely on new features won't work well or
at all, and some rules will have poor performance as some of the code
that extracts data they reference has been updated and refined.
-kgd
Re: RCVD_IN_RP_CERTIFIED always -3
hostmas...@audiogen.ch wrote:
I found the related
configuration in 20_dnsbl_tests.cf:
/#
---/
/# Return Path Certified:/
/# https://www.returnpath.net/internetserviceprovider/certification//
/# (replaces RCVD_IN_BSP_TRUSTED, RCVD_IN_BSP_OTHER,
RCVD_IN_SSC_TRUSTED_COI)/
/header RCVD_IN_RP_CERTIFIED eval:check_rbl_txt('ssc-firsttrusted',
'sa-trusted.bondedsender.org.')/
/describe RCVD_IN_RP_CERTIFIED Sender in ReturnPath Certified -
Contact cert...@returnpath.net/
/tflags RCVD_IN_RP_CERTIFIED net nice/
/reuse RCVD_IN_RP_CERTIFIED/
These were renamed/rebranded some time ago. Run sa-update to get
current rules.
Note that the live rules your system references should be under
/var/lib/spamassassin on most systems. Some distribution packages will
also ship a rules snapshot in /usr/share/spamassassin, however these
should be considered more or less unusable unless you are trying to run
SA in a very extremely security-restricted environment.
Regarding the SpamAssassin 4.x rules - are they backward compatible to 3.4.4?
Pretty much, although rules that rely on new features won't work well or
at all, and some rules will have poor performance as some of the code
that extracts data they reference has been updated and refined.
-kgd
AW: RCVD_IN_RP_CERTIFIED always -3
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)
I should have written I'm on an older Ubuntu, might have helped to avoid
confusion.
Regarding the SpamAssassin 4.x rules - are they backward compatible to 3.4.4?
Thanks a lot
Mark
-Ursprüngliche Nachricht-
Von: Reindl Harald (privat) [mailto:ha...@rhsoft.net]
Gesendet: Donnerstag, 6. Juni 2024 16:29
An: hostmas...@audiogen.ch; users@spamassassin.apache.org
Betreff: Re: RCVD_IN_RP_CERTIFIED always -3
"RCVD_IN_RP_CERTIFIED" don't exist anywhere and the stuff which exsists
is correctly using response-codes
the nonsense below would also trigger with 127.255.255.255 responses
which indicates you are using a shared DNS - complain to the individual
which was writing blacklist/whitelist rules without response codes -
that don't happen in any official rules because it's plain wrong
header RCVD_IN_VALIDITY_CERTIFIED eval:check_rbl('ssc-firsttrusted',
'sa-trusted.bondedsender.org.', '^127\.0\.0\.')
describe RCVD_IN_VALIDITY_CERTIFIED Sender in Validity Certification -
Contact certificat...@validity.com
tflags RCVD_IN_VALIDITY_CERTIFIED net nice publish
reuse RCVD_IN_VALIDITY_CERTIFIED RCVD_IN_RP_CERTIFIED
header RCVD_IN_VALIDITY_CERTIFIED_BLOCKED
eval:check_rbl('ssc-firsttrusted', 'sa-trusted.bondedsender.org.',
'127.255.255.255')
describe RCVD_IN_VALIDITY_CERTIFIED_BLOCKED ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
tflags RCVD_IN_VALIDITY_CERTIFIED_BLOCKEDnet publish
reuse RCVD_IN_VALIDITY_CERTIFIED_BLOCKED
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED
Am 06.06.24 um 14:13 schrieb hostmas...@audiogen.ch:
> Every email postfix receives gets a RCVD_IN_RP_CERTIFIED=-3 score. This
> leads to SPAM passing the filter.
>
> My findings so far
>
> From what I think I understood, RCVD_IN_RP_CERTIFIED checks against a
> list of “trusted” servers, which are considered to not send SPAM. The
> list is maintained by “Return Path” (Validity). I found the related
> configuration in 20_dnsbl_tests.cf:
>
> /#
> ---/
>
> /# Return Path Certified:/
>
> /# https://www.returnpath.net/internetserviceprovider/certification//
>
> /# (replaces RCVD_IN_BSP_TRUSTED, RCVD_IN_BSP_OTHER,
> RCVD_IN_SSC_TRUSTED_COI)/
>
> /header RCVD_IN_RP_CERTIFIED eval:check_rbl_txt('ssc-firsttrusted',
> 'sa-trusted.bondedsender.org.')/
>
> /describe RCVD_IN_RP_CERTIFIED Sender in ReturnPath Certified -
> Contact cert...@returnpath.net/
>
> /tflags RCVD_IN_RP_CERTIFIED net nice/
>
> /reuse RCVD_IN_RP_CERTIFIED/
>
> It seems Returnpath/Validity have gone out of service - is this
> correct? Neither the URL above is working nor can I resolve
> sa-trusted.bondedsender.org. Even worse, sa-trusted.bondedsender.org is
> blacklisted by UCEPROTECTL3.
>
> If RP is dead, is there an alternative? Or am I missing something here?
RCVD_IN_RP_CERTIFIED always -3
Hi all
Setup
Postfix with amavis, spamassassin and pyzor
Problem
Every email postfix receives gets a RCVD_IN_RP_CERTIFIED=-3 score. This
leads to SPAM passing the filter.
My findings so far
>From what I think I understood, RCVD_IN_RP_CERTIFIED checks against a list
of "trusted" servers, which are considered to not send SPAM. The list is
maintained by "Return Path" (Validity). I found the related configuration in
20_dnsbl_tests.cf:
#
---
# Return Path Certified:
# https://www.returnpath.net/internetserviceprovider/certification/
# (replaces RCVD_IN_BSP_TRUSTED, RCVD_IN_BSP_OTHER, RCVD_IN_SSC_TRUSTED_COI)
header RCVD_IN_RP_CERTIFIED eval:check_rbl_txt('ssc-firsttrusted',
'sa-trusted.bondedsender.org.')
describe RCVD_IN_RP_CERTIFIED Sender in ReturnPath Certified - Contact
cert...@returnpath.net
tflags RCVD_IN_RP_CERTIFIED net nice
reuse RCVD_IN_RP_CERTIFIED
It seems Returnpath/Validity have gone out of service - is this correct?
Neither the URL above is working nor can I resolve
sa-trusted.bondedsender.org. Even worse, sa-trusted.bondedsender.org is
blacklisted by UCEPROTECTL3.
If RP is dead, is there an alternative? Or am I missing something here?
Thanks a lot for your support,
Mark
