Generator Labs Nagios and Zabbix Plugins for Blacklist and Certificate Monitoring

Leave a reply
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

Leave a reply
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

Leave a reply
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.

QUIC in PHP, Built on OpenSSL’s Native Stack

I have spent the last while building php-quic, a PHP extension that exposes raw QUIC transport, both client and server, with first-class access to QUIC streams. The thing I am most happy about is what is not in it: no ngtcp2, no quiche, no Rust, no FFI. It is built directly on OpenSSL 3.5’s native QUIC stack, so the only dependency is an OpenSSL you very likely already have.

Why Bother

QUIC has been the transport under HTTP/3 for a few years now, and it is creeping into other protocols too: DNS-over-QUIC, SMB, and a growing list of custom things people are building when they want streams, TLS, and congestion control without standing up TCP plus a separate TLS layer. PHP had no real way to speak it. If you wanted QUIC you reached for a C library with its own TLS stack bolted on, wrapped it in FFI or a custom extension, and inherited a second copy of all the certificate and crypto logic you already trust OpenSSL to handle.

The reason this is suddenly worth doing is OpenSSL 3.5. It ships a native QUIC implementation, client and server, that reuses the same TLS engine everything else in your stack already uses. That removes the entire argument for pulling in a Rust or C QUIC library just to get a handshake. So php-quic is thin on purpose: it is a binding to a transport that is already there, not a reimplementation of QUIC.

What It Actually Does

It gives you the transport and gets out of the way. You get connections, you get streams, you get the event-loop primitive to multiplex them. What you do not get is protocol framing. HTTP/3, DNS-over-QUIC, or whatever you are building on top, that is yours to write. I made that split deliberately. The transport is the hard, fiddly, easy-to-get-wrong part, and the framing is the part that differs for every protocol.

The API is small. Three classes and a poll function:

  • Quic\Connection: a client connection, with openStream(), acceptStream(), close(), and certificate and crypto inspection.
  • Quic\Listener: the server side, bind a host and port and accept() connections.
  • Quic\Stream: the actual data path, with write(), read(), end(), and reset(). Bidirectional or unidirectional.
  • Quic\poll(): the event-loop primitive for non-blocking, multiplexed I/O across many streams.

A client connection is about as short as you would hope:

$conn = new Quic\Connection('cloudflare-quic.com', 443, ['alpn' => 'h3']);
$control = $conn->openStream(false);
$control->write("\x00\x04\x00");

That opens a QUIC connection, negotiates the h3 ALPN, and opens a unidirectional control stream. Everything past that first byte is HTTP/3 framing that you write yourself.

A Concrete Example: DNS-over-QUIC

DNS-over-QUIC is a clean fit for QUIC: one query per bidirectional stream, a two-octet length prefix, done. With php-quic the transport part collapses to a few lines:

$conn = new Quic\Connection('dns.adguard-dns.com', 853, ['alpn' => 'doq']);
$stream = $conn->openStream();
$stream->write(pack('n', strlen($query)) . $query, true);

The true on the write sends the FIN with the data, which is exactly what DoQ wants: one query, stream half-closed, read the response back. That is the whole transport. If you want to see DNS-over-QUIC running against a real resolver without any of this, mrdns.com has the diagnostic tooling.

Non-Blocking by Default

QUIC multiplexes many streams over one connection, so a blocking read-one-thing-at-a-time model throws away the entire point. The poll() primitive lets you wait on a set of streams and act on whichever is ready:

Quic\poll([[$stream, Quic\POLL_READ | Quic\POLL_ERROR]], 1.0);
$chunk = $stream->read(65535);

That is enough to drive a real event loop, and on the server side a Quic\Listener can fan out across processes with SO_REUSEPORT so you scale horizontally without a load balancer in front doing connection-aware routing.

Requirements and Install

You need PHP 8.4 or newer (8.5 on Windows) and OpenSSL 3.5.0 or newer built with the native QUIC stack. The OpenSSL version is the real gate here, since 3.5 is recent. The easy path is PIE:

pie install mikepultz/php-quic

Or build it the usual way and add extension=quic to your php.ini:

phpize
./configure --with-quic
make && make test
sudo make install

What It Does Not Do Yet

I would rather be honest about the edges than oversell this. A few QUIC features are not in the first cut: no unreliable datagrams (RFC 9221), no 0-RTT early data, and no connection migration. There is also a small per-stream memory retention, on the order of 300 bytes, that matters only on very long-lived connections opening enormous numbers of streams. None of these block the protocols I built it for, but if your use case depends on datagrams or 0-RTT, know that going in.

Try It

The code is on GitHub under BSD-3-Clause. If you have wanted to speak QUIC from PHP, whether that is HTTP/3, DoQ, or something of your own, I would genuinely like to hear what you build with it and where the API gets in your way. Issues and pull requests welcome.

Monitoring Your Email Reputation with Microsoft Smart Network Data Services

Leave a reply

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.