Proving a range changed hands: the four dates a delisting request can call day one

First, whether this needs an argument at all

Before building anything, stop whatever is still originating from the range. No custody argument survives abuse that is currently happening, and the operators say so directly: Abusix warns that delisting without fixing the cause often causes a relisting and a delay before you can delist again. Then work out which kind of listing you are looking at, because most of them come off without anyone reading a word you write. The automated families lapse on their own once the triggering behaviour stops. On the pages we read on 27 August 2026, SpamCop described a reported address staying listed for only 24 hours absent further reports, Spamhaus put CSS expiry at generally three days after the last detection, UCEPROTECT put Level 1 at seven days after the last spamtrap hit and described Level 2 and Level 3 as removed automatically once the network no longer matches the criteria, and Abusix gave roughly 5.2 days after the last bad event. Spamhaus says XBL entries expire automatically once the behaviour is no longer detected, without publishing how long that takes. Every one of those figures is a published parameter that can change, so carry the date you read it. Against that, Spamhaus's SBL page describes removal as request-driven and publishes no automatic expiry at all. Building an exhibit for a listing that was going to lapse this week spends goodwill you will want later, and on the request-driven ones goodwill is most of what you have.

Custody is four dates, and they disagree

The first date is the closing in your contract, and it is the one to be honest with yourself about: it leaves no public trace whatsoever. Nobody outside the deal can check it, so it can appear in your account of events but it cannot carry the argument. The second is the registry holder change. This is the most legible of the four and the most over-read. APNIC defines its inetnum last-modified as a system-generated timestamp for when the object was last modified, which says nothing about when control moved, and RIPE marks both created and last-modified as generated by the database rather than supplied by the user. The delegated statistics files are worse for this purpose than they look: the RIR Statistics Exchange Format says the date column is the date the allocation was made, and that where a resource has been transferred from another registry the date is the first allocation date received from the original RIR. It says nothing about a transfer inside a single registry, which is the majority case, so treat delegated stats as unusable for dating an inter-RIR move and undocumented for the rest. The transfer logs the RIRs publish in a common format are the better artefact, with two catches worth knowing before you go looking. The schema makes only three members mandatory, source registry, recipient registry and type, so the transfer date itself is optional and an entry may carry none. And an organisation in that schema is a free-text name and a country code with no registry handle, so entries cannot be joined to registry objects by key and have to be matched on name.

The third date is the first time collectors saw your ASN originating the prefix, and for many transfers it is not a separate event at all: the 2020 study cited below found 64 percent of transferred prefixes advertised consistently across the year either side of the reported transfer date, and a buyer may start announcing before the paperwork, long after it, or never. Where there is a change to date, the honest phrasing matters more than the number. A routing timeline is a sample: RIPE NCC describes its own collector peer recruitment as convenience sampling with an unknown bias, RIPEstat's routing history drops routes seen by fewer than ten full-feed peers, and a long-range query returns coarse buckets, twelve days wide on a sixteen-year window when we ran one on 27 August 2026. So the claim is first observed originating on a date, never first announced. The fourth is the rewriting of the routing authorisations, and it proves less than people assume. RFC 6480 says plainly that RPKI certificates do not attest to the identity of the subject and that the system provides authorization but not authentication, so a ROA, the object that decides whether an announcement is dropped as RPKI invalid, is a statement that whoever held the parent credential authorised an origin, not a statement about who owns the space. Its timestamps are weaker still. RFC 6483 says a ROA's validation lifetime is controlled by the valid times of the certificate that signed it, and ARIN's RPKI FAQ, read on 27 August 2026, says its ROAs auto-renew every 90 days, so a current validity window reflects the last renewal rather than the original decision. A signing time is mandatory in the object itself since RFC 9589 updated the signed-object profile in May 2024, but that records when the signature was applied, which is a different question from when the authorisation was decided. Dating when a ROA first appeared means reaching for a third-party archive, such as the daily RPKI repository archive RIPE NCC publishes, rather than asking the object.

Assembling something the recipient can check

One test decides what belongs in the exhibit: every artefact must be independently reproducible by the recipient from public sources, which is easier to state than to satisfy for the before record: RIPE exposes object versions only through the command-line whois interface and only back to the most recent re-creation, and ARIN releases its bulk directory copy only under a signed agreement, so for much space the before record comes from an archive rather than from the registry itself. An artefact only you can produce is a claim, not evidence. That rules out screenshots of your own portal and rules in a small, dull set. Start with a before-and-after pair of registration records and diff them field by field rather than pasting both in full: the organisation reference, the netname, the abuse and tech contacts, the allocation status, which in the RIPE database is a controlled vocabulary where a move between values like ALLOCATED PA and ASSIGNED PI is visible, and the record's own last-changed date. Add the transfer log entry. Add the last date the previous origin was observed announcing the prefix, hedged exactly as your own first-seen date is, because an announcement that falls below the collectors' visibility floor looks the same as one that stopped. Read that way it is often more useful than your own first-seen date, because it is the seller's footprint ending rather than yours beginning. Reverse DNS turnover can go in as colour, but be precise about what it shows: someone with control of the delegated zone changed the names on a date, which is not the same as a handover.

Two cautions belong in the same commit as the exhibit. Registry snapshots have a cadence, so the earliest date on which a change is visible is an upper bound on when it happened, not the date it happened. And the paper trail is erasable: RIPE documents that an object's history stretches back only to the most recent time the object was re-created, so a delete and recreate wipes the earlier versions. Check the routing authorisations while you are here, because a leftover object is both a reachability problem and a bad look. On pages we read on 27 August 2026, ARIN's transfer best-practices post of 13 November 2025 puts the duty to clear stale ROAs on the transferring party and notes that a single-prefix ROA is removed automatically at transfer while a multi-prefix ROA has to be edited by hand, which is where the risk concentrates, and RIPE NCC says a member's certificate and published ROAs are updated automatically when resources move. Route objects are the stickier half: RFC 7682 observed in 2015 that operators cannot proactively remove stale objects on behalf of holders who do not maintain them, though registry mechanisms have narrowed that since. RIPE documents a force delete available to the maintainer of the covering allocation, listing an existing route object blocking a new exact match among the cases it covers, and under RIPE-731 a RIPE-NONAUTH object in conflict with a ROA for fourteen consecutive days is deleted. Elsewhere it is still a support ticket, and RADb documents a previous owner's leftover object as a reason a registration fails, with contacting support as the remedy rather than any self-service takeover.

Three shapes of a listing against your day one

Once you have picked a date, every listing falls into one of three shapes. Incurred cleanly before it is the easy case and the one the exhibit was built for. Incurred after it is not a custody question at all, it is yours, and no amount of registry paperwork will move it. The straddle is the case worth writing carefully, and it is worth understanding why an operator meets it with more suspicion than you expect. A 2020 measurement study of transfers reported between October 2009 and August 2019 found that transferred address space was 16 percent of total space but covered 61 percent of blocklisted addresses, and, more awkwardly for the new-owner argument, that blocklist reports for transferred addresses peak within a year after the transfer date for every abuse type it measured. For the subset of prefixes already visible in the authors' scans at least a month before the transfer, the peak still fell after it. The authors read that as recipients of transferred space being more prone to abusing it, though that reading rests on the same reported transfer dates the next paragraph shows do not track a change in origin, so it is an interpretation rather than an attribution. So "it was the previous holder" is a claim operators have good reason to test, and the study does not measure how much of the post-transfer listing was inherited rather than new.

The same work found the dates disagreeing at scale, which is the strongest argument for stating plainly which one you are using: the reported transfer date did not correlate with a change in origin AS for 65 percent of transferred prefixes, and in 15 percent of cases the buyer was already advertising the prefix a year before the reported transfer date. That last figure cuts both ways and you should expect it to be used against you. Write the straddle up rather than around it. Concede the overlap, date it, separate what the previous holder's traffic did from what your customers did, and say which of the four dates you are claiming and why that one. An account that volunteers the awkward interval reads very differently from one that quietly picks the most flattering date and hopes nobody checks the other three.

Where the exhibit runs out

The honest ending is that a complete exhibit obliges nobody. Across thirteen operator pages we read on 27 August 2026, covering Spamhaus, Barracuda, SpamCop, UCEPROTECT and Abusix, none published a change of ownership, new management or transfer as a ground it would consider for removal. The only ownership language we found was a check on who may file: Spamhaus says removal requests must be made by the registered owner of the domain or IP, and that submitting a request does not guarantee it will be granted. Invaluement is excluded from that finding because its delist page returned an error to us that day, which is the honest way to state an absence. Nor is there a timetable to promise anyone: Barracuda's page gave a typical turnaround of about 12 hours, and SpamCop's dispute resolution page, read on 6 September 2026, asks for up to one day for a response; those were the only response times we found on any operator page, and none of them published a success rate. For what actually moves each cause, the levers table for newly acquired ranges is the more useful map.

Four other limits are worth stating before you set expectations internally. An undated listing cannot have its date inferred from the evidence around it, so a straddle you cannot date is not an argument you can make. Private receiver reputation is untouched by any of this: a successful delisting is a state change on one list, not a reset at a mailbox provider, and the sending pattern is the only thing that moves that. We could find no published measurement of what fraction of transferred ranges arrive already listed, so treat any percentage you are quoted, including ours if we ever quote one, as unsourced. And the archive cannot attribute a listing to a specific previous tenant, customer or activity. It can date what was visible and when, which is the part of the argument that is checkable, and that is also the part worth building.