What’s going on?
This release of the DNSBL for WordPress is a half-minor update. In a few days back in time a raised act against our contact forms has been observed. ContactForm7 is used on most of the tornevall.net-sites, so it has become frustrating when spam passes through the forms without the ability to instantly blacklist the posts (except for moments when akismet for example helps with the job). So I’ve just added support for WPCF7 into the plugin.
By means, if anything bad arrives via the mail, that has been posted via the contact form there’s just a few seconds between me and a complete blacklist of the sender. In this particular case I’m activating flag 16 (IP_MAILSERVER_SPAM) in the detection configuration and for v2.0.8 a new setting under “Protective options”, called “Turn on support for WPCF7”.
The issue tracker has this case added at https://tracker.tornevall.net/browse/DNSBLWP-63 and has been tested with WPCF7 5.1.4 this far.
dnsbl.tornevall.org has been the primary subname for blacklists several years now. However, it still seems that our 13 year old subname opm.tornevall.org is still going strong. The new DNSBL wasn’t supposed to support that part, however since there’s still quite a lot of resolvers running this check it has been reinstated in the API. The DNSBL has only been running a few days so the loss is probably not even notable, but if there’s time for it there might be built a blacklist validator, to see how many hosts missing this opm-part.
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 184.108.40.206/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.