Release Notes – WP_DNSBL – Version 2.0.7
- [DNSBLWP-60] – False positives shown with fraudbl
In DNBL v5.0.5 (API release) an advanced whitelisting system is introduced. At first, this whitelist system was implemented in a leaf-application (the honeypot system) but since it’s better to implement it directly at the blacklist entry, this has been done instead.
For example, if we’d like to whitelist Telia mailservers in the DNSBL, we could simply add their SPF inclusions in the system. By adding _spf-a.telia.net, _spf-b.telia.net, etc the DNSBL will check each added ip address if it matches against either a IPv4/IPv6 address that belongs to the SPF pointer or if it is located within a CIDR-based range in the pointers. So if we whitelist _spf-a.telia.net and a blacklist request contains an address in the range of 188.8.131.52/32, that address will be considered whitelisted and throw an exception.
In the primary whitelist the only SPF-exceptions is _spf.tornevall.net and _spf.tornevall.se. Other addresses that also will be whitelisted is the following (that will prevent internal server blacklistings):
127.0.0.0/8 172.16.0.0/12 10.0.0.0/8 192.168.0.0/16
The prior weekend our mail server was moved to a completely new place, so we also decided to shut down the old mailserver.
However, the old server contained important files that handled the blacklist functions (methods that automatically updates and changes the zone data in the zone tornevall.org). As this service has been shut down, an update for the DNSBL API has been deployed since we have been unable to rewrite zone data since then.
This also means that all removals from the removal interface should be instant if everything goes as planned (tests has been successful) – and not hourly.
Just remember that even if removals are instant, your blacklisted IP may still be present in caches around the workd, and won’t be updated instantly.