Category Archives: Generator Labs

Reading a Spamhaus Listing Without Panicking

The first reaction to a Spamhaus listing is usually to find the delisting form. That is almost always the wrong first move, because the return code already tells you which of several unrelated problems you have, and three of them cannot be fixed by delisting at all.

The Code Is the Diagnosis

A DNSBL answers with an address in 127.0.0.0/8, and the last octet identifies which dataset matched. Querying the combined zone gives you one lookup and a code that says which list you are on:

$ dig +short 2.0.113.203.zen.spamhaus.org A
127.0.0.4

Note the reversed octets. The address 203.0.113.2 becomes 2.0.113.203 in the query. The codes map like this:

127.0.0.2    SBL       manually researched spam source
127.0.0.3    CSS       automatically detected low-reputation sender
127.0.0.4    XBL       compromised or exploited machine
127.0.0.9    DROP      resource controlled by bad actors
127.0.0.10   PBL       dynamic space, declared by the ISP
127.0.0.11   PBL       dynamic space, inferred by Spamhaus
127.0.0.20   AuthBL    credential bruteforcing or hijacking
127.0.0.30   BCL       malware command and control

An empty answer means not listed. Always fetch the TXT record too, since it carries the reference URL for that specific listing.

What Each One Means for You

PBL, 127.0.0.10 or 127.0.0.11, is not a reputation problem and it is the most common cause of confusion. It says the address is in a range that should not be running a mail server, either because the ISP declared it dynamic or because Spamhaus inferred it. You have done nothing wrong. If you are sending from a residential or default cloud IP, the fix is to send through a proper relay or get static space with a matching declaration from the provider. Delisting an address whose range is still marked dynamic accomplishes nothing durable.

XBL, 127.0.0.4, means the address is emitting traffic characteristic of a compromised machine. Treat it as an incident. Something is infected, or something is being proxied through, or you have an open relay or a web form somebody is abusing. Delist after you find it and the listing returns within hours, which at least confirms the diagnosis.

CSS, 127.0.0.3, is automated and driven by sending behavior: poor list hygiene, high bounce rates, spam-trap hits, sudden volume changes from a cold address. This is the one that most often reflects marketing practice rather than a technical fault, and the technical team frequently cannot fix it alone.

SBL, 127.0.0.2, is manually researched by a human at Spamhaus. Something specific and documented happened, the TXT record will point to the evidence, and there is no automated path out. Read the reference before contacting anyone.

DROP and BCL are severe. DROP marks space believed to be under criminal control, and BCL marks malware command-and-control infrastructure. If either appears against space you own, the conversation is with your provider and probably with an incident responder.

Delisting Without Fixing the Cause

Every automated list re-lists. That is the point of automation. Requesting removal while the underlying condition persists buys hours, and it also trains you to treat the listing as the problem instead of the symptom.

The order that works is to identify the code, find and fix the cause, verify the cause is actually gone, and then request removal. For CSS in particular, verification means watching your own outbound metrics for long enough to know the behavior changed, since a quiet weekend proves nothing.

Check the Basics While You Are There

Listings frequently arrive alongside configuration problems that make delivery worse independently. Reverse DNS that does not exist or does not match the HELO name, SPF that does not cover the sending host, DMARC set to a policy nobody tested. None of those cause a Spamhaus listing directly, and all of them compound the damage while you are listed.

$ dig +short -x 203.0.113.2
mail.example.com.
$ dig +short mail.example.com A
203.0.113.2

Forward and reverse should agree. The email health check on mrdns.com runs that alongside SPF, DKIM, and DMARC in one pass, and the blacklist check covers the wider set of lists in case this is not the only one you are on.

One operational note if you are querying at any volume: the free DNS interface is intended for individual mail servers checking their own inbound traffic. Anything programmatic or repeated belongs on Spamhaus’s data query service, and running bulk lookups against the public zone will get you blocked, which then looks exactly like a clean result.

Generator Labs Nagios and Zabbix Plugins for Blacklist and Certificate Monitoring

Generator Labs Nagios plugin GitHub repository

If you run Nagios or Zabbix, Generator Labs monitoring data can now flow directly into your existing infrastructure monitoring stack. Updated plugins for both platforms are available on GitHub, adding support for certificate monitoring alongside the existing blacklist monitoring checks.

Nagios Plugin

The Nagios plugin is a bash script that calls the Generator Labs API and maps the response to standard Nagios exit codes:

  • OK when no issues are detected
  • CRITICAL when active listings or certificate errors are found
  • UNKNOWN on API or configuration errors

Two check types are supported:

  • rbl: checks for active blacklist listings on a host
  • cert: checks for active certificate errors on a monitor

Install by copying check_generator.sh to your Nagios plugins directory and adding the command and service definitions. A complete example configuration is included in the repository.

Zabbix Plugin

The Zabbix plugin uses the same API and exposes the same check types as Zabbix external checks. Import the provided template, set your Account SID and API token as macros, and hosts are automatically discovered and mapped to Zabbix items and triggers.

Both plugins replace the legacy RBLTracker plugins. If you were running the old versions, remove them and install the updated ones. The check syntax is unchanged, so existing service definitions don’t need to be updated.

Documentation

Query Your Generator Labs Monitoring Data from Any AI Assistant

Generator Labs MCP server documentation page

Generator Labs now runs a hosted MCP (Model Context Protocol) server, which means any MCP-aware AI tool can read your monitoring data and run on-demand checks directly from the chat interface. No switching tabs, no copying host names, no manual lookups.

What You Can Ask

Once connected, your AI assistant has access to your full account data and can answer questions like:

  • “Which of my hosts are currently listed on any RBL?”
  • “Show me certificates expiring in the next 30 days.”
  • “Run a check on mail.example.com and tell me what flagged it.”
  • “What alerts went out this week, and to which contacts?”

The AI translates your request into tool calls, returns results in plain language, and can chain follow-up queries without leaving the conversation.

Supported Tools

Area What’s Available
Blacklist Monitoring List and inspect hosts, active listings, profiles, check history, run manual checks
Certificate Monitoring List monitors, view expiring certs, inspect errors, run compliance audits
Notifications View contacts, groups, webhooks, and recent alerts
Account Summary, balance, and server health

Connecting

The MCP endpoint is at https://api.generatorlabs.com/4.0/mcp. For Claude Desktop, add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "generator-labs": {
      "type": "http",
      "url": "https://api.generatorlabs.com/4.0/mcp",
      "headers": {
        "Authorization": "Basic <base64 of AccountSID:AuthToken>"
      }
    }
  }
}

For Claude.ai, ChatGPT, and other tools that support OAuth 2.1, add a custom connector with the endpoint URL and complete the browser-based auth flow.

Full setup instructions are in the MCP documentation.

Monitor Your Email Reputation and Certificates in Prometheus

Generator Labs Prometheus exporter GitHub repository

If your team already runs Prometheus, you can now pull Generator Labs monitoring data directly into your metrics stack. The Generator Labs Prometheus exporter exposes blacklist listing status and SSL certificate expiry as standard Prometheus metrics, making it straightforward to build Grafana dashboards or set up alerting rules alongside the rest of your infrastructure.

What It Exports

The exporter surfaces metrics for both products:

  • Blacklist monitoring: active listing status per host, listing counts by source type, last check timestamps
  • Certificate monitoring: days until expiration per monitor, active error status, chain and hostname validation results

These map cleanly to Grafana panels: a certificate expiry countdown per domain, a listing status heatmap across your host inventory, or a single alert rule that fires when any host gets listed or any cert drops below 14 days.

Installation

Three options are available depending on your environment:

Pre-built binary: download from the GitHub releases page and run directly. No dependencies.

Docker:

docker run -e GENERATOR_LABS_ACCOUNT_SID=your_sid \
           -e GENERATOR_LABS_AUTH_TOKEN=your_token \
           -p 9090:9090 \
           ghcr.io/generator-labs/prometheus-exporter:latest

Build from source: requires Go 1.21 or later.

Configuration

The exporter takes two credentials: your Account SID and API token from your Generator Labs account settings. Supply them as flags (--account-sid, --auth-token) or the environment variables above. The metrics endpoint is exposed on port 9090 by default.

Add a scrape config to your prometheus.yml:

scrape_configs:
  - job_name: 'generator-labs'
    static_configs:
      - targets: ['localhost:9090']

Full setup guide on GitHub.

Monitoring Your Email Reputation with Microsoft Smart Network Data Services

Standard blacklist monitoring tells you whether your sending IPs appear on public RBLs. It doesn’t tell you how Microsoft specifically views your mail. That’s a separate reputation system, and it matters a lot: Outlook.com, Hotmail, and MSN together represent a significant share of consumer email. Generator Labs now integrates directly with Microsoft Smart Network Data Services (SNDS) inside your blacklist monitoring dashboard.

What SNDS Provides

SNDS is a free Microsoft program that gives senders data about mail flowing from their IP addresses into Microsoft’s mail infrastructure. The metrics it returns include:

  • Message volume from each IP
  • Spam complaint rate
  • Spam trap hits
  • Overall IP status (Green / Yellow / Red)
  • Filter result breakdown

A Red status from SNDS means Microsoft is actively blocking or heavily filtering mail from that IP. Yellow is a warning that reputation is declining. Most teams only discover this when customers start reporting missing mail.

Why It’s Worth Monitoring Separately

SNDS status doesn’t always correlate with your RBL status. You can be clean on every public blocklist and still have a Yellow or Red SNDS rating because of complaint rates, trap hits, or sending patterns that Microsoft’s filters flag specifically. The inverse is also true: an SNDS Green rating doesn’t mean you’re clean on all public RBLs.

Treating SNDS as a separate signal, alongside your regular blacklist monitoring, gives you a more complete picture of your sending reputation and catches Microsoft-specific issues before they escalate.

Setup

Go to RBL Monitoring > SNDS in the portal and add your SNDS access key. Microsoft issues one key per registered IP range. Once connected, Generator Labs pulls your SNDS data automatically and surfaces status changes alongside your other monitoring results.

Setup instructions are in the SNDS documentation.