Definitely confusing so ignore any previous responses I sent :-) Speaking for the Apache SpamAssassin project, I want to make sure this is compliant with our free for some RBL inclusion policy [1] at SpamAssassin but I think the 3 follow-up emails clarified it DOES work out of the box for low volume without a key.
I would also suggest you look at the URIBL_BLOCKED rule and returning a quad that allows an administrator to know why they are blocked. We can add a rule for that. Can you make a suggested rule and email to the SA Dev list or put in a bugzilla request, Please? [1] See https://cwiki.apache.org/confluence/display/spamassassin/DnsBlocklistsInclusionPolicy Regards, KAM On 10/30/2019 10:20 AM, Simon via mailop wrote: > >> On 30 Oct 2019, at 12:01, Heiko Schlittermann via mailop >> <mailop@mailop.org <mailto:mailop@mailop.org>> wrote: >> >> Still it is not clear, if Spamhaus doesn't answer, or of there is some >> device in between. > > Worth a separate post as we see the potential for confusion here. > > On 30th September, in a Spamhaus posted blog: > > "A new range containing return codes (127.255.255.0/24) has been added > to return possible errors related to the DNSBL queries themselves, > which should NOT be interpreted as any sort of reputation related to > the data being queried. While it will be quite uncommon for most > Spamhaus users to encounter these codes, it is vitally important that > software developers implement all return codes correctly, and NOT > treat these error codes as any sort of reputation or "listed" values. > The first two new error codes, and links to pages further explaining > their meaning, are: > > > Return CodeZoneDescription > 127.255.255.254AnyQuery via public/open resolver > 127.255.255.255AnyExcessive number of queries" > > Full article at > <https://www.spamhaus.org/news/article/788/spamhaus-dnsbl-return-codes-technical-update>. > > However, it is unlikely that these return codes will be used in anger > for quite some time as the internet moves very sloooowwwwly at times. > Especially when updating software and baked in practices are concerned. > > Simon > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
