False-Positive Protection (Whitelists, Tor & dnswl)

False positives are the biggest risk for any blacklist service. The Attack Defense Network uses five independent layers to prevent mis-listing legitimate infrastructure:

1. Cautious listing principle: a single report (token or anonymous - every report counts equally) only reaches the watchlist. Two independent reports list the IP (soft-listed), critical categories (malware, botnet) list with one report - this prevents arbitrary listings.
2. Reporter reputation: trusted reporters weigh more, false-positive-prone reporters are automatically downweighted.
3. Internal whitelist: administrators maintain CIDR whitelists; whitelisted IPs are never listed.
4. dnswl.org reputation: mail servers listed on the dnswl.org whitelist receive reduced signal weight for mail services (smtp-auth, imap, pop3) - a whitelisted server can still be compromised, so we soften but do not silence.
5. Tor exit handling: tor exit nodes are flagged in the evidence instead of being treated like normal attackers; they are never notified to abuse desks (shared infrastructure, operators cannot act).

Tor exit nodes generate constant attack traffic from shared IP addresses. Blocking a tor exit affects all users of that exit - a policy decision each administrator must make for themselves.

How we handle tor exits

• Reports from tor exits are still scored (the attacks are real).
• The evidence is flagged with tor-exit - filter it in your firewall rules if you want to allow tor.
• No abuse-desk notifications are sent for tor exits (the operators cannot act on them).

The list is refreshed hourly from check.torproject.org/torbulkexitlist.

dnswl.org maintains a DNS-based whitelist of mail servers with verified good sending behaviour. We query it for reports against mail services (smtp-auth, imap, pop3).

Effect

• Trust level 0-1: no adjustment (unknown or low trust).
• Trust level 2-3 (medium/high): signal weight is halved and the evidence is flagged with dnswl-2 / dnswl-3.

Why not exclude entirely? A whitelisted mail server can be compromised and start sending attacks. Reduced weight means the listing still happens - it just needs more corroboration. This mirrors how blocklist.de uses dnswl.org, with a finer-grained response.

Note: We do not use the commercial Spamhaus whitelist feed; dnswl.org covers the same protection goal via public DNS.

Never list your own infrastructure: add your IP ranges to the internal whitelist so your monitoring and security systems are not reported by accident.

Whitelist requests: contact us with the CIDR ranges you operate. Whitelisted ranges are excluded from all listing decisions and are visible in the check API as whitelisted: true.