Abuse reports to the networks' abuse desks

Beside the reputation report to AbuseIPDB, the controller can mail the abuse desk of the network an attacker comes from — one mail per banned address, a person's words with an X-ARF v4 document attached, so the desk's tooling and the desk's people both get it. Off by default: a mail in your name is a deliberate act (owner_reports: {enabled: on}, or Settings → Reporting → Abuse reports).

When a mail leaves

A ban by a rule on any machine of the fleet. Which rules count is yours to choose (rules: {only: […], except: […]}, patterns allowed — a redirect-blind crawler may not deserve a mail, an SSH brute force does); a network can be switched on or off on its own (Lists → Networks), and default says what a network without a setting gets. The ban waits delay (fifteen seconds) so the one or two log lines that arrive late are in the report, then leaves through your SMTP account — the reports' own account when you give one, so answers and bounces come back where the controller reads.

Bounds: one mail per address, never twice within a day; daily_limit (200) mails a day over the fleet; per_network (20) a day to one desk.

Who receives it

The desk is the block's, not the network's: a registry publishes an abuse contact per block, and a network that leases blocks to customers (Gold IP, NetAssist) has a different desk on each. It is found from the banned address itself and kept a month under the block the answer came with — a network's page lists its desks by block:

The registries' own data, kept locally — the RIPE Database and the AFRINIC database dumps (the two registries that publish abuse mailboxes in bulk), fetched weekly under <state>/registries/ and searched for the most specific block holding the address: its abuse-c role's abuse-mailbox, else its organisation's, else its mnt-irt, else the mailbox of its admin or tech contact. No network call at mail time, and the block comes with the answer.
Abusix Abuse Contact DB — a DNS lookup of the address, answered with the abuse mailbox the regional registries publish. Free, fast, no registration, every registry; no block in its answer, so the desk is kept for the /24 or /48 around the address. When it names several desks — the parent's beside the block's — the block's own RDAP record says which one. Every mail it addressed carries the acknowledgement Abusix asks for.
RDAP — the registry's live API, when the two above know nothing (ARIN, APNIC and LACNIC blocks, mostly): the abuse entity of the block or of its parent, an abuse-looking address of any entity failing that, with the block's range. A registry that rate-limits pauses the lookup for as long as it asks.

Your own word wins over all three: an address set by hand for a network (Lists → Networks → the network's page) is used as long as it stands.

A mail that bounces marks the report bounced and the desk as bouncing; the next address the registry publishes for the block (technical, administrative) takes over and the report goes there once; a desk with no other address is left alone for a month. The desks' answers are read back from the mailbox (IMAP, within seconds) and sorted: a ticket number, an acknowledgement, "we acted", a refusal ("use our form"), a request for more, a person's words — the last three wait for a person under Reports, the rest need nobody. A desk that says its mailbox is not read is a refusal, and the report's thread keeps the desk's ticket in every answer you send.

The operator's word. A network's page lists its desks by block and says when they differ — N desks over M blocks: the reports go by block, the address shown is the last one resolved — because a wholesale network (ColoCrossing, for one) has as many desks as customers. Two ways to override the registry, and their order:

A desk for one block (Set… on the block's row, or Desk for a block… with a prefix): that block alone, the most specific one winning when two nest. The customer's own desk when the registry's record is wrong or silent. Clear goes back to the registry's.
A desk for the whole network (Set by hand… at the top): every address of the network — every block, every customer. A block's own desk still wins over it. Use it for a network that is one operator, never for one that leases its blocks.

PATCH /v1/networks/{asn}/owner {block, contact} is the first, {contact} the second; GET answers blocks (each with its desk, source and bounce state) and desks, how many differ.

What it says

The mail's text is a template you can change and preview (Settings → Abuse reports, template and subject). As shipped:

Subject: Abuse report about 203.0.113.7 - Mon, 21 Sep 2026 08:10:11 +0000 [SL-1e59994c]

Source IP: 203.0.113.7
Network: AS64500 Example Networks
Date (UTC): 2026-09-21 08:07:14
Category: login_attack
Target: www.example.org
Server hit: web01.example.net (192.0.2.10, 2001:db8::10)
Rule: ssh-bruteforce (12 events)

203.0.113.7 was banned by our server on 2026-09-21 08:07:14 UTC: repeated failed logins over SSH…

Log lines, UTC then as the server wrote them:
2026-09-21T08:07:12Z  Sep 21 10:07:12 web01 sshd[4242]: Failed password for root from 203.0.113.7 port 51022 ssh2
…

Previously banned on our servers: 2026-09-14 (http-scan), 2026-08-30 (ssh-bruteforce)

AbuseIPDB has a confidence score of 100% that this IP is an active attacker; verify the score and other reports at https://www.abuseipdb.com/check/203.0.113.7

The same report is attached as an X-ARF v4 document (xarf.json, connection/login_attack).
Reported by Example Hosting (example.net), abuse@example.net, with Shieldlist (https://shieldlist.eu/).
The recipient address comes from the Abusix Abuse Contact DB (…); Abusix is neither responsible nor liable for this message. If you are not the right contact, please ask your RIR to update the abuse-c record.

When the machine keeps an attribution log — a second access_log with the TCP source port — each log line is followed by src port 51234 in the mail and src_port=51234 in the X-ARF payload, with source_port/source_ports at the document's top: the one thing a desk behind a carrier-grade NAT needs, with the time, to find the subscriber.

Line by line: the source address and its network; when; the X-ARF category; the site or domain aimed at ({target}, what the log lines named) and the machine hit with every address it carries; the rule and how many events tipped it; a short paragraph on what the address did, why it is a problem, why it was blocked and what the desk can do (the rule's own report words — never a threshold, the report is public — or yours per rule, rule_texts); the log lines that convicted the address (lines, three by default), in UTC then as the server wrote them; the address's previous bans on your servers (ten at most, nothing for a first offender); AbuseIPDB's confidence score when one is known — from your own report of this ban, or from a reputation check on record — with the link to verify it; the pointer to the attachment; who says so (reporter: {org, contact, domain}); and the line acknowledging where the recipient's address came from (Abusix, a registry's dump under its terms, or RDAP). A line whose placeholder came out empty is dropped. The [SL-…] tag at the end of the subject ties every answer back to the report.

The X-ARF document

xarf.json, attached to every mail unless format: text, one document per source address, version 4 of the format as its samples are written:

the core: report_id, timestamp, reporter and sender (your reporter identity), source_identifier (the address), first_seen / last_seen, evidence_source: firewall_logs, confidence;
the category and type the rule's report preset implies — the connection category (a login attack, a vulnerability scan, scraping, a port scan, an injection, a flood) or messaging (spam) — with the fields that type requires: the port closed or targeted, destination_ip and destination_servers (the machine hit and its addresses), destination_hosts (the sites aimed at);
the evidence: the log lines as an attachment inside the document, base64 with their SHA-256 and size, described (how many lines, which server, which rule, when banned).

The same document is what Export → X-ARF gives on a network's or an address's page in the console, so what you send by hand and what the controller sends say the same thing.

What is not sent

Nothing about the machine beyond its name and addresses; no configuration, no other visitor's line, no account name of yours. The log lines are the offender's own requests, as the server wrote them — read them once with Preview before switching a rule on: a request line can carry a path or a query of your users' site.

Where it is written down

Every mail is on record with its outcome (sent, bounced, failed) and what came back — the Reports page of the console, a network's page, GET /v1/owner-reports/list. The configuration keys are in Configuration and the configuration reference; the data sources and their terms in Credits.