<![CDATA[SpamAssassin rule `RCVD_IN_VALIDITY_CERTIFIED` related queries are failing, causing them to trigger on every message.]]>I've been noticing the past week or so that these seem to be included on every single email:

RCVD_IN_VALIDITY_CERTIFIED RBL: Sender in Validity Certification - * Contact certification@validity.com * [Excessive Number of Queries | <https://knowledge.validity.com/hc/en-us/articles/20961730681243>]

I get that for the following three built-in SpamAssassin rules:

  • RCVD_IN_VALIDITY_CERTIFIED
  • RCVD_IN_VALIDITY_RPBL
  • RCVD_IN_VALIDITY_SAFE

I was looking at https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS?language=en_US and it looks like they say the following for when these errors are seen:

I get a 127.255.255.255 response on all my queries to Validity reputation data. What does this mean?

127.255.255.255 | Excessive Number of Queries

This query response code indicates that you are querying Validity reputation data via a DNS resolver / IP address that is unregistered or making an excessive number of queries. Consequently, the query is blocked, and it will return no reputation data.

To avoid excessive queries, Validity recommends avoiding public DNS resolvers. Instead, run a local caching, non-forwarding DNS server as the system resolver on your mail server.

I only recently noticed this, it definitely wasn't present when I was making all my SpamAssassin rule tweaks last month, so this is something new. I did find this though from the same KB article:

Validity will allow up to 10,000 requests to anonymous users over a 30-day period. If you require the ability to query in larger volumes then a contractual agreement is needed.

This makes me think that if the email server goes over 10,000 queries in a month, then it's triggered. So I suppose this means I've reached over 10,000 queries in a 30 day period. Since this is built-in to SpamAssassin, I've temporarily disabled them by 0.0 otherwise the scores all get triggered because of the "too many queries" issue, which is odd behaviour but it at least will no longer distort the totals tagged to each message.

Perhaps this can be avoided by using a local cache as it suggests? Since it's a built-in rule to SpamAssassin, I'm hoping maybe we can have the Cloudron DNS server be a local cache perhaps, if that's how that works.

]]>https://forum.cloudron.io/topic/13751/spamassassin-rule-rcvd_in_validity_certified-related-queries-are-failing-causing-them-to-trigger-on-every-message.RSS for NodeSun, 19 Apr 2026 18:27:18 GMTFri, 09 May 2025 04:24:16 GMT60<![CDATA[Reply to SpamAssassin rule `RCVD_IN_VALIDITY_CERTIFIED` related queries are failing, causing them to trigger on every message. on Fri, 09 May 2025 15:19:27 GMT]]>@girish Oh that is interesting, I didn’t realize we could customize the DNS server. This is helpful. Thanks so much! 🙂

]]>https://forum.cloudron.io/post/106874https://forum.cloudron.io/post/106874Fri, 09 May 2025 15:19:27 GMT<![CDATA[Reply to SpamAssassin rule `RCVD_IN_VALIDITY_CERTIFIED` related queries are failing, causing them to trigger on every message. on Fri, 09 May 2025 15:10:00 GMT]]>@d19dotca right, what I mean is that disabling the rule by setting to 0 for the validity.com rule is the correct approach .

As for caching, you can experiment with custom configs for unbound - https://docs.cloudron.io/networking/#unbound . The default Cloudron config uses cache-max-negative-ttl as 30 and cache-max-ttl as 300 . If you change these, it will have side effects on the DNS propagation checks at app installation time. Maybe unbound has a way to have low ttl for your own domains but not the rest, not sure.

]]>https://forum.cloudron.io/post/106872https://forum.cloudron.io/post/106872Fri, 09 May 2025 15:10:00 GMT<![CDATA[Reply to SpamAssassin rule `RCVD_IN_VALIDITY_CERTIFIED` related queries are failing, causing them to trigger on every message. on Fri, 09 May 2025 14:55:02 GMT]]>@girish It’s a built-in SpamAssassin rule set, I don’t think there’s a way to just “not use their servers” unfortunately because they’re built-in. The annoying thing is it litters all the matched spam rules for each incoming message since after the 10,000 it seems to trigger all the Validation rules on every message due to the query failure.

The best I have found so far is setting the scores to 0 so that they’re at least non-impacting when triggered.

I wonder if it’d be helpful to expose the caching settings of the DNS servers so we can adjust to our own requirements? Or if there’s a way we can start locally downloading the lists? I think SpamHaus recommends something similar too for any servers with a high enough query count. Maybe some people might be hitting these limitations as Cloudron grows, and we may need to think of how to handle that.

I will see if there’s a way to force SpamAssassin to no longer even trigger those rules at all, that might help too for those who are hovering over the 10,000 messages a month, but I’m not sure if it’d be possible through what’s exposed to us in Cloudron yet. I’ll look into that. 🙂

]]>https://forum.cloudron.io/post/106870https://forum.cloudron.io/post/106870Fri, 09 May 2025 14:55:02 GMT<![CDATA[Reply to SpamAssassin rule `RCVD_IN_VALIDITY_CERTIFIED` related queries are failing, causing them to trigger on every message. on Fri, 09 May 2025 10:46:44 GMT]]>@d19dotca the mail container already uses unbound which is a local caching, non forwarding DNS server. However, the caching is intentionally low so that we can "fresh" results for latest DNS values etc. I don't think there is an easy fix for this. I suggest simply not using their servers .

There's a number of reports of the same issue on the web and some posts even saying validity has gone fully paid (https://lists.apache.org/thread/m4s61n1h7glpjt9nngm3lch9nht026zc). Some bug reports - https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8278 and https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8244 . So, I think disabling the rule by setting it to 0 is the correct approach .

]]>https://forum.cloudron.io/post/106850https://forum.cloudron.io/post/106850Fri, 09 May 2025 10:46:44 GMT