Hi,
On 17/05/2026 01:53, J Doe wrote:
Hi Arnaud,
On 5/15/26 16:10, Arnaud de Prelle via users wrote:
On 2026/05/14 01:13:18 Tom Bartel wrote:
Support Intelligence acknowledges that the DBL is not signed
currently. They've removed all the DNSSEC from the zone for the moment,
until they can sign the zone. Keep an eye on it, and if I get word it's in
place, I'll post here.
Hi Tom & J.,
Thank you for having raised this thread as I was wondering since a while the root cause of these DNS errors in my logs.
I tried deploying an NTA for this via: rndc but I was still getting the:
FORMERR's that you listed in your logs.
I then opted for a: validate-except { } clause in my BIND options, and that
reduced the log spam.
- J
Btw, now that this service — which I was not previously aware of — has been discussed in relation to recent DNS issues, I have a
couple of concerns about it.
As far as my research goes, I have not found documentation for this specific provider within the SpamAssassin project. By
contrast, other DNSBL & URIBL providers (Spamhaus, SURBL, uribl.com, ...) are well documented.
Given that URIBL_RHS lookups inherently expose queried domains (and therefore parts of inbound mail traffic), this raises
questions about trust and data exposure. Even if limited to DNS queries, it effectively acts as a passive telemetry sink for
message URIs processed by participating systems.
Additionally, I have seen mixed operational reports in the community (false positives, instability, ...), which makes it more
difficult to assess whether this feed meets the same bar as other DNSBLs used by the project.
So my main question is not about SpamAssassin itself, but rather :
- Is there any maintained documentation that I may have missed?
- If not, would it make sense to formally document its status (experimental, third-party, unmaintained, ...) in the official
SpamAssassin documentation for clarity?
From an operational perspective, I think it would help administrators distinguish between recommended reputation providers and
third-party optional feeds that may have different trust, privacy, and operational characteristics.
Kind regards,
Arnaud
