A report lands in abuse@: deciding whether the address is yours, whether the complaint is actionable and what you answer

What is actually in front of you

The message gives you an address, a time and some lines out of somebody else's log, and asks you to stop it. Nothing is listed yet, no upstream has written and the reporter has not said which zone the time is in.

A lookup on that address verifies none of it. It files nothing, it tells nobody you read the message and it holds nothing about the minute the reporter names. The two questions it can answer are narrower than the ticket, and neither is the one the reporter asked: whether the address sits inside space you answer for, and what that space is already known for. The complaint itself is answered somewhere else entirely, by the procedure the abuse desk post already sets out, which this one does not repeat. So the shape of what follows is fixed: two reads, four answers, one reply, and between the reads a grading of what the message itself left out. If you know both reads already, the four answers are a table, and everything between here and it is why each row says what it says.

What a lookup puts on a single page is the registered block the address resolves to together with the allocation standing above it, on the Registration panel walked row by row already for an allowlist ticket. Where the registry serves exactly one block and it is not the thing you typed, the panel heads itself Registration followed by that block, so an address lookup arrives titled by the assignment the address sits in rather than by the address. Underneath, past a collapsed Registry contacts table, a second collapsed table headed Enclosing blocks carries Block, Name, Type and Country for the objects the registry puts above it. Those two together are the read that decides your first branch, and the rest of this post is what they do and do not prove.

No standards document obliges you to answer, and that has been true from the beginning. RFC 2142, the May 1997 document where abuse@ was written down, gives the name a three word job, Inappropriate public behaviour, and files it under customer relations. What it requires is about the mailbox rather than the mail: the name must be supported, resulting in delivery to a recipient appropriate for the referenced service or role, and supported at the organisation's own domain rather than only on the hosts whose customers generate the complaints. The one line it spends on answering is a suggestion rather than a duty, that an automatic acknowledgement is usually helpful, with a caution about mail loops, and the site has said where that comes from.

Is the address yours: the registered block read against the allocation above it

Read the Registration heading first, which means going to it rather than scrolling to it: the panel sits near the foot of the report, and the section rail down the side has an entry that jumps there. The heading has already settled a question you would otherwise have run yourself, so a customer assignment inside a larger allocation is the first thing on the panel rather than something you derive. On a live lookup on 17 September 2026 an address in RIPE space resolved to a /21 assignment with a larger allocation standing above it, and that allocation appeared three times on the same page in two shapes: as the registry's own start and end addresses twice, once in the Enclosing blocks table and once on the Routing panel's Less specific row, and once as an aligned prefix with its size and its net name inside the finding headed Part of something bigger. The routing row is always on screen. The table sits behind a line that counts its rows, and the findings panel shows five before it puts the rest behind a control, so that finding, which is the last one the report adds, is in plain sight on a quiet address and one click down on a busy one.

The chain has a region in it, and this is the counterweight to carry in the same breath as the read. The enclosing objects are built from one registry's address space hierarchy, so the table does its work in RIPE space and nowhere else. Lookups on 17 September 2026 in the ARIN, APNIC, LACNIC and AFRINIC regions each returned a single enclosing entry that is a placeholder rather than a parent, with no finding naming one: a span starting at the bottom of the address space, usually running to the top of it under a name that says as much and carrying a remark that the block is not managed by the RIPE NCC, and on some subjects a shorter span under a different placeholder name with no such remark. Worse, the Routing panel's Less specific row is read from the same hierarchy with no guard against a placeholder, so outside RIPE space the one row always on screen prints that span as a range, which makes it the row most likely to be misread at 09:12. Read past it. Where the layer above survives at all it is in the JSON, under Raw JSON response at the foot of the Sources panel, which is the only place the registry's own keys are kept: on the ARIN address looked up that day the range, the prefix, the net type, a parent handle and a referral server were all there. On the APNIC and LACNIC addresses no parent key was published at all, so in those regions the report does not hold the layer above and the registry's own query interface is the only place to get it.

Next the Abuse contact row, which is the one most often over-read. It is a single resolved value: the report walks the registry's own abuse entity first, then an abuse source, then the whois attribute, and prints whichever answered. So it is the contact that resolves and never the level that published it, and a sub-block answering with your own mailbox settles nothing about which record published it. What matters at the desk is the direction of the inference: a contact that resolves to you says where complaints land, not who is answerable for traffic. Which of the two ARIN record shapes produced it is settled in the reassignment post.

Two more places on the same panel finish the read. The Registry contacts table is where a separately published abuse role appears when a customer has one; read its Role column knowing that the site joins the registry directory's own role words into one comma separated line where a contact holds several, that a contact with no role at all reads unknown and that a missing name, organisation or email reads n/a. Where nothing resolves at all the row is not there to read: the report drops it and says so in a finding headed Nowhere to report abuse, stating that complaints have no published destination; that finding needs a registry record to exist, so a subject with no registration gets neither the row nor the finding. And read the Type row in the same pass, handing its vocabulary straight to what a status actually lets a holder do, because an assignment, a sub allocation and an allocation are three different positions in the same chain and only one of them is somebody's customer.

What the name on the record proves varies by how it got there, and that decides how much weight the branch can carry. In ARIN's manual, version 2025.1 of 3 March 2026, new organisation records are created on a request from an authorised contact representing an entity ARIN is able to validate, and a reallocation or a detailed reassignment is rejected unless the receiving organisation is already in the database and "associated with at least one validated POC object", with ARIN emailing every contact on that organisation whether the request succeeded or not. A simple reassignment name has been through none of that, as the reassignment post says. ARIN's own data model page adds the reason such a name can look like a dead end: "Customers do not have a direct relationship with ARIN and, at present, may only be associated with one network registration", although the same page documents a customer endpoint and a search by handle and by name, so the record is reachable even when it leads nowhere else. A short contact list is not evidence of anything either: section 3.3 of the same manual lets an organisation privatise points of contact with the exception that at minimum one must stay viewable, and the residential privacy clause still requires the upstream's abuse and technical contacts to stay visible on the record.

Your own terminal is the cross check, and it is yours to run rather than something this site runs for you. RIPE's database documentation, read the same day, states that a plain query on an address returns the exact match if one exists and otherwise the object with the smallest less specific range, which is exactly why a desk sees one object and assumes it is the whole story. The hierarchy is there for the asking, and the flag this read wants is the one that returns the exact match together with every larger range. A separate flag asks for the abuse contact, and an empty answer from it means no abuse contact was found on the object or in anything enclosing it rather than that the address is unregistered. Those are whois query flags: the documentation writes them for the command line and the structured search takes the same set under longer names, so the place they are awkward is a form built to return one object. One caution while you are in there. The same documentation says the incident response team object "should not be used to handle general abuse complaints" and is being returned to incident response teams, and that a reference to one on a network object applies to all more specific space beneath it, so a routine complaint aimed at that object in that region reaches a team that did not want it.

One region asks the most of the holder, and the extra it asks for is speed, which is worth knowing if you hold space there. APNIC's policy document, version 015 of 20 February 2025, says the contacts on the mandatory incident response team object "must be regularly monitored and any abuse complaints sent to these contacts must be responded to promptly to resolve the complaints". That is a duty on the account holder rather than on you as a reader, with no deadline attached and no sanction stated for a slow answer, and it sits at the opposite end of the range from the finding already on the site that no adopted policy in two of the other regions requires a person to read the mailbox at all. The whole read is one lookup, but the panel does not print it in the order the read wants: the heading first, then the abuse contact on the last of the rows beneath it, then any remarks the registry published, then the contacts table, and last the Enclosing blocks table, which carries the layer the first branch turns on and which outside RIPE space holds a placeholder and sends you to the JSON instead. So read the heading, drop to the foot of the panel for the block above it, then work back up the rows. Everything after that is judgement.

Is the complaint actionable: what the reporter gave you and what nothing here corroborates

What a report needs before a desk can act on a paying tenant is written down already from the reporter's side, so read this section as a grading rather than as instructions: what the message is missing decides whether the answer is a request for the one thing it lacks, and nothing more. One item on that list has a published default behind it. In the structured report format the incidents field is optional and its absence implies the report covers a single incident, and RFC 6650's security considerations say what batching costs: reporting nearly identical incidents together "causes a degradation in reporting quality", and where a reporter covers only a fraction of the messages the precise details of each incident are not sent. A summarised report is harder to act on because it is built to be.

Shapelessness alone is not a reason to bin it. Published abuse mailbox addresses "SHOULD NOT reject non-ARF messages based solely on the format", because generating that format is sometimes unavailable or not applicable, with deviation left to local policy on other criteria. The scope of that is worth stating once, because it matters more here than anywhere else in the post: RFC 6650 is written throughout about emailed abuse reports, in the vocabulary of feedback providers, mailbox providers and a structured report format, and much of what it asks is asked of the reporter rather than of you. A pasted block of log lines may not be a mail complaint at all. The requirement above is the rare one pointed squarely at the receiving mailbox, and a complaint that arrives as pasted lines rather than in the format is the shape it was written about.

How the reporter found you is worth one line, because it says what they had. Deciding where to send an unsolicited report "will typically rely on heuristics", and the same document names three: the abuse addresses in the registry record of the relaying address, the abuse addresses in the registry record of the domain a reverse query returns for it and the abuse@ role at related domains. Only the first is what a lookup prints. The other two start from a reverse query, which is the next thing a lookup does not hold.

There is no reverse DNS, no PTR and no hostname on that page at all, so a name pasted into a header cannot be corroborated there and has to be checked in DNS, with the usual caveat that a name is an assertion by whoever controls the zone. A bare source address can be forged and a pasted header can be typed by anyone, so a desk acting on a header alone is acting on the weakest thing in front of it, and the rule for deciding by transport and connection state is not re-argued here. The standard says the same of its own format in its security considerations, that such reports "may be forged as easily as ordinary Internet electronic mail", and describes a reporter being duped into complaining about a message its user never received, as an attack on the party the complaint names. An informational document from June 2011 wrote down the shape of your message fifteen years before it arrived, as "IPv4 address X has done something bad at time T0", in the same passage the evidence post leans on.

Which raises what the address is rather than what it did. One address can be a carrier gateway or a shared host, and how to recognise that from the report is covered elsewhere. Whose record you are asking for is not always obvious either: the logging recommendations in BCP 162, read the same day, close by noting that they also apply to devices such as load balancers logging incoming connections on behalf of actual servers, so the clock and the record that matter may belong to a box in front of the machine the reporter thinks they found. And the boundary this post does not cross is what a record proves, and where it stops.

The standard is useful for grading what arrived, in neutral words you can borrow. It tells reporters not to send reports that "cannot be used as a basis for action by the recipient" and lists three ways one fails that test: it is not about abuse, it went to an address that will not result in action or its content or format is hard to read or use. That is a description of an unusable report addressed to the sender, not a category you are authorised to stamp on a message, and the difference is the whole of the fourth branch below. The same section grades provenance: complaints raised by end users about mail they judged abusive, or mail delivered to a spam trap or honeypot address, are "far more likely to be accurate and MAY be sent". Where the report came from is a reading the standard itself makes, and it costs you nothing to make it too. An industry body reached the same conclusion from the other end in 2007: the abuse desk practices published that year, still served at their published address today and describing themselves as options rather than an absolute set of best practices, note that most ISPs need a full Internet header before they can investigate a spam complaint, and that relatively few Internet users know this or know how to supply it. So when the message is missing the zone, the raw lines or the header, asking for the one missing thing is an answer and not a deferral. What the reporter's own logs may no longer hold has its own post, and so does the format this message would have arrived in if it were structured.

What the space is already known for, and why none of it is about the reported minute

The second read is the one the first cannot do: not who holds the space, but what the space has been observed to be. It is a row of labelled chips under the address, and above them sits a heading naming whether analysts, the site's own active checks or both put the labels there. Read the heading before the labels, because the same word from two provenances is two different statements. Each chip carries its confidence. Where a label was established against a block rather than against a whole network the chip carries that block, or, where several labelled objects carry the same label, a count of them, as blocks or as addresses depending on what was measured, with up to twelve of the members on the tooltip and a count of any beyond that, and either way a plus count stands for more specific confirmations inside it; a label scoped to a network carries no block at all, because it is a statement about the network. On the subjects looked up on 17 September 2026 every established label was network wide, so that contrast is something the page can show rather than something it showed that day.

Below the established labels a separate row is headed Suggested by automated sampling, not yet confirmed, and the heading is doing real work. Those are proposals. They are on the page because withholding them would be its own kind of dishonesty, and they carry exactly the weight the heading gives them, which at a desk deciding what to do with somebody's tenant is none.

Two findings speak directly to tenancy, which is the part of this read that sends you to your own assignment records rather than to a different row of the table. Where the feeds name a company using the space that is not the network running it, one finding says so, in a line ending is not the network that runs it where one address was checked and runs them where several were, with is becoming are by how many companies are named. Where sampled addresses report one network while the block is announced by another, a second finding says that, naming both by AS number alone, and says in its own words that this is how leased or sub-allocated space looks. Both come from sampling rather than from the registry, so they are leads and not records, and the registry side of the same question is the reassignment record you either filed or did not. The first also prints every company it names in full, which is a good reason to paraphrase that line into a ticket rather than paste it.

The current state has dates on it, and they are the wrong dates for your purpose. Near the foot of the sampling panel one click opens a per source table whose Checked column pairs the day a feed last answered with how many times it has answered, and where the block is currently carried by blocklists a red line high in the same panel, under the chips, names them in plain sight. Both describe now. Neither describes the minute in the complaint, and the gap between those two things is how a desk talks itself into a decision it cannot defend. Read them as the standing reputation of the space, and not as evidence that the reported traffic happened.

The limits belong with the reading. Readings accumulate only from lookups, so unsampled is not clean and absence of a label is never innocence, which is what a clean result actually means and part of what a single address investigation cannot reach. The history is thinner than it looks. On a live lookup on 17 September 2026 a real block drew the twelve slot chart with two months carrying a reading and ten slots empty, and another subject the same day had exactly one observed month, at which point the chart does not draw at all and one sentence stands in its place naming the month that was checked and saying no other month in the last twelve was. So a trend is something you may have and often will not. There is also no finding at all for residential, mobile or shared consumer space: the one line of that kind says an address sits in a datacenter rather than on a home or mobile connection, and it fires only where no feed has settled or disputed an anonymity flag and every sampled address rolls up the same way, so its absence is at least as likely to mean nothing was sampled as to mean the space is something else.

The four answers

The branch is chosen by the record and the report, never by the tone of the complaint or by what else is waiting. The first three rows are decided by the lookup you have already run, two of them by your own assignment records as well, and the fourth by what the message left out once that same lookup has put the block inside your allocation; each one ends in an answer you can write from what those already show. Where the block is yours, read the fourth row before the second and third: a message missing the time zone, the raw lines or the header cannot be matched against your own records or safely relayed to anyone beneath you, so the ask goes out alone and those two rows wait on the reply.

Four notes on the table. On the first row, redirect means naming the record you read and stopping, not forwarding the message onward: RFC 6650 asks reporters not to send to recipients who are uninvolved or only peripherally involved, with its own example being every network in the path between the origin and the reporter, so a redirect that hands the message to the next party up repeats the mistake it is correcting. The same section notes that a report sent to the mailbox of the party being complained about is usually meaningless, and that such reports might reveal information about the complainant.

On the third row, passing a complaint down relays whatever the reporter left in it. The redaction memo for abuse reports illustrates exactly this, a provider obscuring the complainant's own address in case the report is relayed on to the party being complained about, and its privacy considerations say it is extremely unlikely that report generating software could ever be built to recognise every way private information is expressed in written language. Where feedback arrives in the structured format under a standing arrangement there is a published route for forwarding it to the originating customer automatically. A pasted message is not that, so the trimming on this row is yours to do by hand. A sampled finding that the space looks sub-let is a lead to take to your own records and never a destination, because nothing is passed to a party the registry publishes no contact for. And passing it down transfers nothing except the work, a point the abuse desk post already makes about handing over a mailbox.

On the fourth row, asking is an answer. RFC 6650 notes that an address which cannot receive replies precludes any request for additional information and makes it likelier that further reports are discarded, so the reply that asks is a shape the format's own authors expected. The 2007 abuse desk practices record both positions on whether automatic acknowledgements were worth sending at all, and the committee that wrote them used the ones they favoured for precisely this: to say what evidence would be needed before the complaint could be processed, and to carry a tracking number that makes follow up possible.

And a note on what is not on this table. Suspension and termination are not branches here, because neither is a record read; what the hosting practices already quoted on the site say is to suspend customers who do not respond, and the rest of that sequence is your own policy. Nor is any change to a registry record. Nor is the order you work the queue in, although the same hosting practices, dated March 2015 and read at their published address on 17 September 2026, have something to say about it: they suggest designating trusted or priority reporters, with the example that a contact at a widely used blocklist may be an appropriate priority reporter, and then draw the limit themselves, that a spam complaint from that source still ranks below a denial of service issue happening at the same time. One line above their own priority chart they invert it, noting that a mass campaign may outrank the command and control presence of a dormant botnet. A published table of priorities is a starting position rather than an order of work, and the body that published that one says so on the same page. Whatever mitigation you place while you work through the rest, place it with a review rather than a timer, because the entry will outlive the reason for it otherwise.

What you write back, and the one thing you never put in it

The case for answering at all is already made, down to the acknowledgement that names a ticket and the autoresponder that answers nothing while looking like one. This section is about contents.

What a reply may safely carry is short.

1. That the report arrived.
2. Which record it was matched against, named as a block rather than as a conclusion about anyone.
3. What happens next in your own process.
4. What the reporter will and will not see, which is the only part likely to surprise them.

The boundary that list draws is yours, and it is drawn on a silence. Of the registry policies read on 17 September 2026, APNIC asks the most of the holder and LACNIC says the most about the mailbox, and neither reaches past the tending of it. LACNIC's section on abuse contacts requires the mailbox to guarantee that abuse reports, logs, headers and examples relating to the case are received. It sets objectives for the validation procedure the policy told LACNIC to build: that the person validating understands the procedure and the policies in force, monitors the mailbox regularly, takes measures and responds to the abuse report. Ignoring a case, or attending to one improperly, is reportable for re-validation. Not one clause says what a response contains. That reading is from the English web version, which the page itself says is not the controlling text, the authoritative version being the published document and the Spanish original prevailing over the translation. ARIN's manual uses the word abuse for a contact type to register and verify and for the upstream contacts that stay visible on a private residential record, and adds only that points of contact shall be representatives of the organisation and that what is given to the registry shall be the contact's organisational information rather than personal data. RIPE's policy calls the mailbox a thing intended for receiving reports and requires the attribute itself to be available without restriction through the database and its interfaces. Between them there is no clause about content at all.

A standards track document carries the same shape with a concession attached that is worth repeating honestly: although it reads its own source as suggesting that replying to feedback is not useful, it says that where a structured report arrives with no standing arrangement behind it a reply written by a person, indicating what action resulted, might be desirable, because it heads off heavier filtering by the party that sent it. The source it is reading says, in its own words, that a party consuming automated complaint feedback inside an established loop need not tell the reporting provider or its users what it did. Both were read on 17 September 2026. An industry body's hosting practices land in the same place from experience rather than from principle: most complaints a provider receives require only an acknowledgement of receipt, with high profile complaints, takedown requests and blocklist removals named as the exceptions that need more.

Then close the one door and move on. A reply never identifies a customer to a reporter. The site tells reporters to expect the effect rather than a case report, and the two posts agree on that deliberately. Whether any disclosure duty applies to you at all is a conversation with counsel rather than with a blog, which is the line the abuse desk post takes and this one does not reopen. Most of what RFC 6650's unsolicited section asks is asked of the reporter rather than of you: a provider sending reports must offer a way to request that no further reports be sent, and since no standardised mechanism exists every one of them is out of band, which means asking. That is a route out for a misfiring automated sender and not an answer to a person who took the trouble to write, and the same place carries a reason to answer that outlasts the ticket: where an unsolicited report establishes contact with a responsible and responsive party, that contact can be kept for future complaint handling, and the reporter who is answered once is the reporter who writes to you next time instead of to somebody above you.

Two things not to write. No clock, because no document read for this post puts one on answering a reporter: the strongest wording there is that the mailbox must be "regularly monitored" and complaints "responded to promptly", with no figure attached to either. The only deadlines in days anywhere near this are the fifteen day windows in LACNIC's validation procedure and the sixty days ARIN's manual gives the contacts it verifies annually, the abuse one among them, to answer that notice. All of them time the holder's answer to the registry rather than yours to the person who wrote. Whatever deadline you are working to was set by your employer. And nothing in the reply may suggest that anything was checked on your behalf. You read a public record and your own logs. Say that, or say nothing.

What this report will never settle, and where those questions live

Four questions are going to come back at you, and each has an address that is not this page. Who your customer was at the reported minute lives in your own assignment records and, where you file them, in the reassignment records you publish. Whether a host was compromised or was the customer's own tooling lives in the customer's logs and nowhere here. Whether a listing follows lives with the list operators and their own published rungs. And whether the same address comes back next week is nobody's job here: the site does not watch, alert or notify, so a holder's own scheduled lookups are the only version of that which exists.

Two absences are worth naming plainly because they look like oversights and are not. The first was named above: nothing here corroborates a hostname, because there is no reverse DNS in the report at all. The second is that no analyst or scanner label carries a date, so nothing says when a chip was applied or removed. What is dated is narrower than that: the feed readings themselves, which the verdict changes list prints per address and the history timeline repeats under its own filter. Those say what a feed said on a day. They do not say what the space was labelled on the day in the complaint.

There is also a shape of case where the answer is not yours to give at all. The informational document that catalogued address sharing put it in one line: the problems used to sit inside a single legal entity, and as large scale address sharing spreads, the same problems span several at once. The party who can answer the complaint may be somebody you have no contract with, and the honest reply says which record you read and stops there.

Which is the whole of it. The report does not settle the complaint. It narrows the question from a complaint to a record, and the record names the operator to ask, which on this address may be you.