The categorised DNSBL

The same crowd data, rendered for your mail stack — with mail abuse scored separately from web probes.

A firewall feed and a mail blocklist want different things from the same observations. Dropping an attacker's packets because they brute-forced someone's WordPress is cheap and reversible. Bouncing their mail is neither.

So the crowd data is published twice. The blocklist feed is every corroborated attacker. The DNSBL is a narrower, categorised view: one bit per kind of abuse, so a rule can ask "was this address doing mail credential abuse?" rather than "is this address bad in some way?".

Zone

bl.minsec.io

The answer for a listed address is 127.0.0.<mask>, where the mask is the OR of every category it is listed under:

Bit	Category	Meaning
2	`mail-auth`	credential abuse against mail submission or webmail
4	`mail-mx`	dictionary / RCPT abuse at the MX
8	`web-auth`	web application login brute force
16	`web-exploit`	exploitation attempt against a known vulnerability
32	`infra`	generic infrastructure abuse (SSH, FTP, panels)
64	—	reached the high-confidence tier

An address listed for mail-auth and infra answers 127.0.0.34. Rule names with no registry entry categorise as unknown, which has no bit and is never published.

A bitmask is what SpamAssassin's check_rbl_sub matches against, so one lookup answers every rule.

SpamAssassin

Ready-made rules ship in the backend repository as deploy/spamassassin/minsec.cf. The shape:

header   __RCVD_IN_MINSEC     eval:check_rbl('minsec', 'bl.minsec.io.')
describe __RCVD_IN_MINSEC     Listed by minsec

header   RCVD_IN_MINSEC_MAIL  eval:check_rbl_sub('minsec', '127.0.0.2')
describe RCVD_IN_MINSEC_MAIL  Mail credential abuse seen by the minsec crowd
score    RCVD_IN_MINSEC_MAIL  2.5

header   RCVD_IN_MINSEC_HIGH  eval:check_rbl_sub('minsec', '127.0.0.64')
describe RCVD_IN_MINSEC_HIGH  High-confidence listing
score    RCVD_IN_MINSEC_HIGH  1.5

Score mail-auth and mail-mx meaningfully; score web-auth and infra lightly or not at all. An address brute-forcing SSH is not, on that evidence, a spam source.

Score, do not reject

Use this as one input to a score. Rejecting outright on any single DNSBL — ours included — turns one bad entry into someone's lost mail.

Running a mirror

The zone is published as an rbldnsd zone file:

GET https://api.minsec.io/v1/dnsbl/v4
GET https://api.minsec.io/v1/dnsbl/v6

Unauthenticated — the contents are, by construction, the answers to public DNS queries. ETag and Last-Modified stay stable while the listing set is unchanged, so a conditional fetch returns 304 and rbldnsd does not reload for nothing. 503 zone_not_ready can occur briefly after a fresh deployment.

Why the entries are narrow

IPv4 entries are /32 and IPv6 entries /64; broader prefixes are held back deliberately. A zone that gates mail delivery should not punish a whole allocation because one aggregated report came in against it. The same reasoning drives the short TTL (300 s): cloud addresses are reassigned within hours, and a mail-facing answer has to age out faster than a firewall block.

Delisting

Mail delist@minsec.io. Delisting applies to the DNSBL and the blocklist feed together and takes effect at the next scoring tick, usually a few minutes. You can check any address on the lookup page.