Sent
The address came from the connection itself — fail2ban saw it, or Postfix logged who connected. There is nothing between you and the attacker to lie about it.
Your firewall and your mail filter already caught them. TrueAbuse takes what they caught, works out which network the address belongs to, writes the complaint, and sends it to the people who can actually shut it down.
sshd[2847]: Failed password for root
from 198.51.100.23 port 51224 ssh2
The ninth failure from that address in two minutes. fail2ban bans it.
198.51.100.0/24 → AS64496
[email protected]
Asked the registry who holds the address, and who they publish for complaints.
Subject: SSH brute force from 198.51.100.23
Evidence: 9 failures, 03:25:47–03:27:25Z
One report, not nine emails. Repeats inside the window join the same complaint.
Nothing new to instrument. The agent follows the logs your existing tools write, and understands four of them out of the box.
Every ban, from every jail — over its socket, or from its log if you would rather not grant that.
Ban 198.51.100.23 · jail sshd
The JSON audit log. The rule that fired decides what the attack is called, and the request path is kept without its query string.
rule 942100 · sql injection · /search?[redacted]
Mail that was rejected, with the score and the checks that produced it.
reject · score 14.2 · DMARC_POLICY_REJECT
The address that actually connected, read from the maillog — not the address the sender claimed in the envelope.
connect from unknown[198.51.100.23]
A file path and a regular expression with a named capture for the address. If it writes a log, it can be a source.
pattern = banned (?P<ip>[0-9a-f.:]+)
An abuse report is an accusation against somebody's customer. Sent on thin evidence it wastes an abuse desk's time, and eventually it costs you their attention. So some reports are deliberately not sent.
The address came from the connection itself — fail2ban saw it, or Postfix logged who connected. There is nothing between you and the attacker to lie about it.
A web firewall that reads the client address out of a request header is reporting whatever the sender wrote there. Unless a proxy you actually run rewrote that header, the report is held. It appears on your map as a dot with no wire out, and nothing leaves the building.
The same instinct runs through the rest of it: a contact that bounced or complained is suppressed rather than retried, and sending pauses itself when the day's limit is reached instead of queueing a backlog nobody asked for.
A complaint an abuse desk can act on without writing back to ask for the basics: one address, what it did, when, and how often.
To: [email protected]
Subject: SSH brute force from 198.51.100.23
Between 03:25:47Z and 03:27:25Z on 2026-02-14, the address
198.51.100.23 made 9 failed SSH authentication attempts
against a host we operate.
Feb 14 03:25:47 sshd[2847]: Failed password for root
from 198.51.100.23 port 51224 ssh2
Feb 14 03:26:02 sshd[2851]: Failed password for root
from 198.51.100.23 port 51238 ssh2
… 7 more
The address was blocked locally. We are reporting it so the
network it belongs to can act. No reply is required.
One binary. No interpreter, no package repository, no dependency tree to keep patched. It reads logs and talks to one endpoint.
Invite the rest of the team with the access they need: owners and admins change policy, operators work the queue, viewers can look but not send. Every send, every change of policy and every invitation is written to a log that can be added to and never edited. One customer's reports are unreachable from another's — enforced by the database itself, not by remembering to filter.
Register a host in the portal, run the installer it gives you, and leave it for a day. Whatever your firewall catches tonight is a complaint that gets filed by morning.