Summary

  • An IPv4 lease can terminate cleanly while adverse classifications continue. Public blocklists, private mail-receiver ratings, fraud and bot scores, proxy or VPN labels, geolocation records and security-vendor observations are separate systems with different evidence, refresh cycles and appeal routes.
  • There is no complete global blocklist or reputation dataset from which to measure every post-lease tail. Published studies illuminate selected lists, cloud environments or leasing samples. Their results establish that address reuse and residual classification are real problems, but they should not be presented as universal incidence rates.
  • Every adverse signal should identify the address or prefix, event time, observation source, classification reason, confidence, scope, last confirmation, expected review or expiry rule, and the party responsible for the decision. A current score without provenance can turn an old tenant's conduct into a permanent claim about a later user.
  • Good-faith successors need a portable change-of-control packet: dated lease or transfer evidence, prior and current routing observations, registration history, reverse-DNS and geofeed updates, cleanup records, current service description and an authenticated contact. Sensitive commercial terms can be redacted while the operational transition remains verifiable.
  • Lessors and lessees should take baseline snapshots, monitor during the term, preserve incident records and perform a reputation handback at expiry. Contract terms should allocate cleanup cooperation, historical appeals, notice, evidence retention and measurable remediation costs rather than promising an impossible universally clean address.
  • Reputation providers should separate observation from decision, use decay suited to the underlying behavior, narrow prefix-level generalization, disclose listing and removal criteria, accept direct private appeals and avoid making present users prove a negative about periods before their control.
  • The policy answer is not to prohibit short leases. It is to make operational periods legible and to require time-aware, source-aware correction. A market with accountable handback and appeal can price history; a market without them quietly charges innocent successors for someone else's conduct.

The contract ends before the Internet forgets

A hosting company leases a /24 for ninety days. During the term, one customer deploys residential proxies and another account is compromised. The lessee closes both accounts, but some addresses appear on spam and security lists. The lease ends. Routes are withdrawn, reverse DNS is removed and the prefix returns to the lessor.

Two weeks later, a regional software company leases the same /24 for transactional email and customer logins. Its systems are newly built. Its domain authentication is correct. Its users have opted in. Yet some recipients defer mail, a fraud service challenges ordinary customer sessions, a travel site locates the addresses in the former country of use and a security product labels part of the range as a proxy network.

The new lessee did not cause the earlier activity. The lessor may have completed every contractual handback. The prior lessee may have remediated the immediate problem. Still, several independent memories remain. Some are explicit entries on public lists. Some are private scores inferred from historical traffic. Some are stale location data. Some are classifications copied into products that the affected operator cannot identify.

This is the reputation tail: the period during which a past observation continues to influence decisions after the operational relationship that produced it has ended.

The tail is not always an error. A malicious actor can rotate addresses and return. A short lease can be used deliberately to burn space and move. A provider that instantly erases all history at every claimed change of control would make evasion cheap. The design problem is therefore not simple deletion. It is deciding how much old evidence remains probative, for which decision, with what confidence, and against whom.

That inquiry requires time. An observation that was strong on 1 June may say little about a new operator on 1 August. It requires scope. One compromised host does not automatically establish that an entire /20 is hostile. It requires provenance. A vendor copying another vendor's label should not present the result as an independent observation. It requires appeal. The current operator must be able to show that the relevant control changed and that present behavior does not confirm the old claim.

Without those elements, reputation becomes an invisible encumbrance. The market prices an address block as available, while the services that decide whether it can send mail, pass fraud checks or appear in the correct country continue to treat it as occupied by its past.

Reputation is not one list

The phrase "IP reputation" sounds singular. Operationally, it describes many different products and judgments.

A public DNS-based blocklist can return a documented code for an address or domain. One list may identify known spam sources, another compromised machines, another dynamic end-user ranges that should not send mail directly, and another infrastructure linked to a malicious operator. Presence has meaning only in relation to that list's published criteria.

A mailbox provider may maintain a private sending reputation based on traffic it receives. Volume, complaint rate, authentication, recipient engagement, message pattern, reverse DNS and prior behavior can all matter. The provider may expose a dashboard to authenticated senders while withholding details that would help evasion. An address absent from public lists can still have poor delivery to one receiver.

A fraud-prevention service may score a login or payment using the address alongside device, account, velocity, location, hosting type and prior transactions. The address may be labelled data-centre, residential, proxy, VPN, mobile, anonymizer or recently observed in risky events. The score belongs to a transaction model, not to an objective universal character of the address.

A geolocation vendor estimates where an address is used and may also supply organization, connection type or user-type attributes. A location error can trigger tax, licensing, pricing or access consequences even though it is not an abuse classification. A move from one lessee and country to another can leave a long operational tail if vendor releases and customer updates lag.

A security service may record scanning, exploit attempts, malware callbacks, command-and-control activity or bot traffic. It may score an individual address, aggregate to a prefix or infer risk from neighboring infrastructure. The source could be a honeypot, customer telemetry, sinkhole, incident report or another feed.

Registration, routing and authorization records are different again. RDAP may show a recognized organization. BGP shows observed origin and propagation. RPKI expresses route-origin authorization. Reverse DNS shows names chosen by an operator. None of them certifies reputation, but changes in those records can help prove that operational control moved.

These distinctions matter in an appeal. A Spamhaus removal request cannot repair a private Gmail classification. A geofeed cannot erase a malware observation. A new RDAP contact does not automatically update every fraud vendor. A lessor that advertises a block as "clean" after checking three public lists may be speaking truthfully about those checks while saying almost nothing about the address's practical reception elsewhere.

The first rule is therefore linguistic discipline. State which system produced which result, when it was checked, at what granularity and for what use. Never turn a limited lookup into a universal certificate.

We do not possess a complete global tail dataset

Any serious account of residual reputation must begin with an evidence limitation. There is no comprehensive public dataset containing every blocklist entry, private mail score, fraud decision, geolocation record, security feed, customer override, listing time, removal time and lease interval for the global IPv4 space.

Many decisive systems are private. Public lists change continuously. Some permit historical research; others expose only current status. Lease terms are usually confidential. A BGP origin change may indicate a lease, transfer, mitigation event or ordinary routing change. Registration updates can lag operational control. A provider's customer may cache a commercial database after the vendor has corrected it.

Published research nevertheless demonstrates important parts of the problem. A 2020 ACM Internet Measurement Conference study, Quantifying the Impact of Blocklisting in the Age of Address Reuse, examined 151 publicly available IPv4 blocklists. Its authors developed methods to identify shared and dynamically reused addresses and found reused addresses across a substantial share of the lists. The study is evidence that address-level blocking can reach users other than the actor that generated the original signal. It is not a census of all reputation systems or commercial leases.

A 2021 study, A Comprehensive Measurement of Cloud Service Abuse, observed four cloud services over 154 days using 39 blocklists. It reported extensive listing and daily replacement of cloud addresses, making the collision between short-lived users and longer-lived classifications concrete. The environment was cloud address reuse, not the entire IPv4 lease market.

A 2020 Passive and Active Measurement paper, A First Look at the Misuse and Abuse of the IPv4 Transfer Market, combined longitudinal blacklist and routing information to study transferred prefixes. Transfer and lease are not interchangeable, but the paper shows why changes in recognized control and operational use need to be aligned with time-indexed reputation evidence.

A 2025 study, From Scarcity to Opportunity: Examining Abuse of the IPv4 Leasing Market, compared identified leased and non-leased prefixes in the datasets available to its authors and reported higher blocklist appearance for the leased sample. That result deserves attention. It also depends on how leased prefixes and lists were observed, what periods were covered and which forms of abuse the sources detected. It cannot establish that every lease is riskier or supply a global tail duration.

The honest conclusion is strong enough: address reuse, leasing and changes of control can collide with reputation mechanisms that retain history. The frequency, severity and duration vary by system and remain incompletely measured. Policy should improve the missing timestamps and provenance rather than fill the gap with a universal number.

Why the tail persists

Some tails persist because the harmful condition has not actually ended. A compromised server remains online after the lease is said to have changed. A prior customer retains credentials. A malicious route or reverse-DNS delegation survives. A new lessee is related to the old one. In these cases, continuing caution is justified.

Other tails are created by deliberate expiry policy. A list may retain an entry for a fixed period to prevent rapid recycling. A fraud model may require a run of benign observations before increasing trust. A mail receiver may warm an unfamiliar sender slowly. These controls impose cost on good-faith successors, but they can also deter bad actors from escaping consequences through nominal reassignment.

Technical refresh contributes. Vendor databases are released daily, weekly or monthly. Customers download copies on different schedules. Recursive DNS caching can delay a list change for its configured lifetime. A corrected vendor record may therefore coexist with stale customer copies.

Manual review contributes. Some entries require the network operator to explain the problem, demonstrate remediation or contact an upstream provider. If the party that caused the listing has already left, the successor may lack the original ticket, logs or authority expected by the removal process.

Aggregation contributes. A detector may classify a /24 or larger range because several addresses behaved badly, because the range belongs to a hosting category, or because individual address churn makes host-level decisions ineffective. The broader scope can protect users from rotating attackers, but it also extends the tail to addresses never observed doing harm.

Data lineage contributes. One service consumes another's feed; an integrator combines several; a customer trains a model; a case-management system stores a label; and the original entry later disappears. If lineage is not preserved, the downstream holder cannot tell whether its information remains independently supported.

Sparse observation contributes. A low-volume good sender may not generate enough events to demonstrate improvement. Google notes in its Postmaster Tools documentation that reputation reflects sending behavior and that recovery can take time; data are not real time. A successor can therefore be clean but evidentially thin.

Finally, business incentives contribute. Providers are rewarded for preventing fraud and abuse, while the cost of a false positive is distributed across users and operators. An opaque conservative score may reduce immediate loss even if it creates an expensive appeal burden elsewhere. Without measurable correction duties, old suspicion is cheap to retain.

RFC 6471 already states the core discipline for public blocklists

RFC 6471, an IRTF account of operational practices for public email DNS-based lists, remains unusually direct about the required safeguards. It calls for clear public listing and delisting criteria, says lists should follow their stated criteria, recommends temporary listings in many settings, calls for a direct non-public removal channel and sets expectations for prompt response.

The document recognizes that expiry should fit the source. Relatively static information may justify long intervals. Fast automated detection of short-lived conditions can benefit from short expiry because a corrected or reassigned address will age out while recurring behavior can be detected again. Manually created entries should be reviewed periodically.

That structure is more valuable than a universal retention period. A malware command server confirmed by several sources, a temporarily infected host, a dynamic consumer range and a policy list of addresses not intended for direct mail are different claims. They should not receive identical decay or appeal tests.

The direct private channel matters because public argument can expose security evidence, customer identity or reporter information. A successor should be able to submit proof of changed control and current remediation without publishing its contract. The list operator can authenticate the request and preserve an audit record.

Prompt response matters because the economic damage is immediate. A blocklist entry can affect mail delivery, account access or upstream willingness before a legal dispute could be resolved. A fair appeal that takes months may be no remedy for a ninety-day lease.

RFC 6471 is not binding law and does not govern private fraud models. It supplies a sound design test: clear criteria, matching removal criteria, proportionate expiry, direct contact, timely handling and continuity when the list's primary administrator is unavailable.

The missing addition for leased space is explicit change-of-control handling. A list should say what evidence it accepts when the current operator did not control the address at the observation time, whether old evidence continues to affect the range, and what benign period or current test can reduce that effect.

Time must be a first-class field

Every adverse observation should answer at least four temporal questions: when was the conduct observed, when was the record created, when was it last confirmed, and when will it be reviewed or expire?

The observation time maps conduct to an operator. Without it, a lessor cannot determine which lessee held the block and a successor cannot show that the event predates its term. A date without time zone may be limited public evidence for rapidly reassigned addresses.

The record-creation time exposes reporting lag. An entry created today from an event six months ago should not look like fresh hostile activity. Lag may be justified by an investigation, but the consumer should know it.

The last-confirmed time distinguishes continued evidence from copied history. A feed that repeats the same label daily is not necessarily observing new conduct daily. Providers should preserve the original observation and state whether a later check independently confirmed it.

The review or expiry field makes decay accountable. "Indefinite" may be defensible for a category tied to address policy rather than behavior, but it should be stated. A behavior-based claim without any review point invites permanent error.

Lease records need corresponding times: possession or service commencement, routing activation, customer activation, notice of termination, route withdrawal, handback and any transitional use. Contract signatures alone may not identify the actual operating interval.

Comparing those timelines supports a fair initial decision. If harmful traffic ended before the old route was withdrawn and the new lessee began later, the evidence points to the prior period. If the same origin, reverse DNS, customer domains and behavior continue through a paper change, skepticism is justified.

Time does not decide identity on its own. It narrows the claim. The question becomes "What evidence connects this current operator to behavior observed during a different control period?" That is far better than asking the operator to prove that an address has never been bad.

Provenance must survive copying

A reputation result should identify whether it came from direct observation, a reporter, a named feed, public registration, routing inference or another model. The source may remain confidential where disclosure would expose a sensor, but the affected party still needs a meaningful class and a way to challenge accuracy.

Direct observation should state the observing system, event type and relevant confidence. A third-party report should distinguish reporter assertion from recipient verification. A copied feed should carry the original provider and observation reference where licensing permits. An inference should state the features that can be disclosed and avoid presenting association as witnessed conduct.

Lineage prevents false corroboration. If three services all repeat one original list, a consumer should not treat them as three independent sources. If one provider delists after correction, downstream systems should be able to identify records derived solely from that entry.

Versioning matters. Geolocation and intelligence databases have release dates. A customer appealing a decision needs to know which version was used. A vendor may already have corrected its current release while the decision-maker still uses an old copy.

Reason codes should be stable enough to compare over time. "Risky" is not useful. "Observed SMTP spam at stated time," "address classified as residential dynamic space," "known proxy endpoint," "location inferred from prior deployment" and "prefix associated with repeated scanning" are claims with different remedies.

Confidence should not hide the evidence gap. A model can be mathematically confident in a stale association because its training data lacked a control-change signal. Providers should include recency and change-of-control uncertainty rather than treating the IP string as a permanent identity.

The consuming service must preserve its own decision provenance too. A payment platform may combine an address classification with account velocity and device mismatch. The operator appealing the IP label should not be told that correcting it guarantees approval. The service should clarify which component is under review and which decision remains its own.

A successor needs a portable change-of-control packet

The good-faith successor often knows that it is new but cannot prove that fact in the form each provider expects. A portable evidence packet reduces repeated argument.

The packet should identify the exact prefixes and the operational commencement time. It should include a redacted lease, service order or transfer receipt showing the parties, range and term; current authorization from the recognized holder; and an authenticated contact for both holder and operator. Price, unrelated blocks and other commercial terms can be removed.

Registration evidence should include dated RDAP or Whois observations and any more-specific record. Routing evidence should show previous and current origins, first observed announcement, withdrawal or transition, while acknowledging that BGP collectors have partial visibility. RPKI and IRR changes can support the account but do not prove customer identity.

Operational evidence should include new reverse DNS, mail authentication where relevant, service description, abuse contact, geofeed and records of prior cleanup. If the predecessor's service has ended, remove obsolete PTRs, route objects, certificates, letters of authorization and domain references that make continuity appear greater than it is.

The packet should contain baseline and current reputation checks with timestamps and provider names. It should not claim that silence from checked sources proves universal cleanliness. Its purpose is to show the starting condition, subsequent changes and which issues remain open.

For a contested listing, include the listing code, observed event time, ticket, remediation performed, current logs and the requested correction. If the event predates the successor, state that directly and ask the provider to evaluate present control separately. Do not invent a technical explanation for conduct the successor did not observe.

Cryptographic signatures or authenticated portals can make the holder's statement reusable. A reputation provider should not require the full private contract if a recognized holder can attest that operational control changed for the range at a stated time.

The packet is evidence, not absolution. Providers can compare it with routing and current behavior. Its value is procedural: a successor presents a coherent dated account instead of sending screenshots to an unknown support queue.

Geolocation has a correction path, but propagation still takes time

Geolocation illustrates the difference between authoritative input and downstream adoption. RFC 9632 defines how an operator can publish and point to a geofeed, with an optional RPKI-based authentication method. It also cautions that registration-country hints can be administrative rather than deployment-specific and describes how consumers should use the most-specific applicable data.

A new lessee deploying a prefix in a different country should publish an accurate geofeed through a supported registration reference. The file should be scoped to the addresses it controls, served over HTTPS and updated when deployment changes. It should not publish user-level precision that creates privacy risk.

Vendors also offer direct corrections. MaxMind's correction service accepts one-time requests and geofeeds, explains that accepted corrections enter later database releases and provides expected review intervals. IPinfo's correction page accepts individual ranges and bulk geofeed information.

These mechanisms improve the vendor's data. They do not instantly update every customer. A financial institution may download monthly. A content platform may cache. Another vendor may infer location independently. The successor should therefore record submission, acceptance, vendor release and observed customer correction as separate events.

Geolocation appeals also show why one address can carry several valid-looking positions. The recognized holder may be incorporated in one country, the lessee in another, the routers in several and the users distributed globally. The requested field must be clear: network deployment, user location, organization, billing address or registration jurisdiction.

Calling every difference "wrong geolocation" obscures the claim. A fair correction identifies what the service is trying to estimate and gives the operator a way to supply current, appropriately granular evidence.

Mail reputation cannot be cleaned by declaration

Email is where reputation tails become most visible because receivers make continuous private decisions and attackers rotate infrastructure aggressively. A new lease agreement cannot require a mailbox provider to trust the new sender.

Google's sender guidelines explain that activity on a shared IP affects all senders using it, that poor reputation can affect delivery, and that authentication, reverse DNS, complaint rate and responsible sending behavior matter. Postmaster Tools exposes provider-specific data to qualifying authenticated senders. It is not a universal reputation view.

The successor should begin with technical hygiene: valid forward and reverse DNS, SPF, DKIM and DMARC aligned to the actual sending arrangement; secure relays; controlled volume; complaint handling; and separation between transactional and risky marketing traffic where feasible. It should not send at maximum expected volume on the first day merely to prove the block is active.

Warm-up is not a ritual that erases old history. It is a period in which the receiver observes current authenticated behavior. If the address remains publicly listed, the operator should use the list owner's stated removal route. Spamhaus, for example, directs affected operators through its IP and Domain Reputation Checker and applies different removal paths to different lists.

An old listing may concern policy rather than abuse. Some ranges are categorized as end-user space not expected to send direct mail. Removal may require showing the intended mail-server use and correct reverse DNS, not denying past spam. The listing reason must be read before the operator asks for deletion.

The lease contract should never promise "guaranteed inbox delivery" or complete absence from every list. It can promise disclosed checks, cooperation, technical configuration and handling of identified legacy issues. The distinction protects the successor from false certainty and the lessor from an unlimited warranty over private receiver decisions.

Fraud and security scores need controlled forgetting

Fraud models face a real adversarial problem. If a bad actor can reset reputation by presenting a new lease, change-of-control claims become an evasion tool. Yet treating the address as a permanent person produces false positives whenever infrastructure changes hands.

The model should therefore preserve event history while reducing the weight assigned to a new principal after verified control change. The old event remains true as a statement about the address at a time. Its relevance to the new operator becomes a separate inference.

Several factors can test continuity: overlap of customer identities, domains, device clusters, payment instruments, origin networks, reverse DNS, service pattern, contacts and behavior. These signals should be used carefully. A shared transit provider or common hosting category is weak evidence of common control.

Decay should fit the event. A one-off compromised host remediated and reassigned may lose relevance quickly. Repeated command-and-control observations across a coordinated prefix may justify longer caution. A static classification such as known anonymization infrastructure should be reviewed when the service changes rather than aged like an incident.

The model should avoid unnecessary prefix contagion. Aggregation can detect rotating attackers, but it should record why a /24 or ASN-level inference was made and how an innocent address can exit. A single event should not silently become evidence against every future user in a larger range.

Appeals should permit machine-readable evidence and human review. The operator may not be the end user affected by a checkout decline, so vendors need a network-level correction route as well as consumer support. A reasoned response can protect detection details while saying whether the disputed attribute was corrected, retained or not material to the customer's final decision.

Controlled forgetting is not mercy. It is model hygiene. A score that cannot represent a principal change will eventually measure address history more strongly than current risk.

Reputation handback belongs in every short lease

A short lease compresses the period available to discover and remediate adverse signals. The contract should make handback an operating event, not merely a billing date.

Before activation, both parties should capture a baseline. Query agreed public lists, record geolocation from named vendors, inspect current routing, RPKI, IRR and reverse DNS, and test the services central to the intended use. Date every result. The baseline should list what was not checked.

During the term, the lessee should monitor abuse reports and material reputation changes. The lessor should not spy on ordinary customer traffic, but it can receive summary indicators and escalation when range value is threatened. The parties should identify who opens provider tickets and who can authenticate control.

At termination, the lessee should close or migrate services, withdraw routes on schedule, remove obsolete DNS and authorization, preserve relevant logs and deliver a list of unresolved complaints and correction tickets. The lessor should verify handback and prevent immediate reassignment if active harm continues.

The handback statement should distinguish current listings, pending appeals, corrected entries and unknown private state. "No known adverse public entries in the agreed checks at 12:00 UTC" is defensible. "Clean IPs" is not.

Cooperation must continue for a defined tail. A prior lessee may need to answer a provider about an incident during its term. The lessor may need to confirm the new operator. Set a period, contact and response expectation. A security deposit or holdback can cover documented cleanup cost, but it should not remain open indefinitely because one opaque private score has not improved.

Liability should be evidence-based. The prior lessee bears costs tied to conduct or breached controls during its term. The lessor bears undisclosed pre-existing issues and failure to perform promised checks. The successor bears its present operation. Reputation providers remain responsible for their own data and correction decisions.

This allocation is more realistic than forcing the last party in the chain to absorb every consequence simply because it is easiest to contact.

Price the tail without selling a cleanliness myth

Reputation affects value. A prefix suitable for ordinary web hosting may be unsuitable for immediate high-volume mail. A range with stale location data may delay a regulated service. A block carrying unresolved proxy classification may produce more user challenges. These differences can justify price, deposit, staged activation or a different use.

Pricing needs evidence. A seller or lessor should identify checks, observation time and providers. The buyer or lessee should define the intended service and which external decisions matter. A generic cleanliness premium invites disputes because each party imagines a different universe of scores.

The agreement can create acceptance tests. Mail use might require successful authenticated low-volume delivery to named receivers, not a promise about every inbox. Geolocation might require accepted correction from specified vendors and publication of a geofeed, not instantaneous adoption by all customers. Security use might require removal from named public lists and no current hostile routes.

Holdbacks should expire through objective events. If the listed cause is corrected and the provider confirms removal, release the amount. If the provider refuses despite verified changed control, the parties need a pre-agreed allocation rather than endless suspense. The lessor cannot control every third-party opinion.

Insurance or reserve pricing may develop for known tails, but reliable products require data on duration and remediation cost. That is another reason to preserve case timestamps and outcomes. Anonymous aggregate statistics can improve price discovery without publishing customer identities.

A dirty history should not make a block permanently worthless. Nor should a new contract magically erase risk. Market discipline lies between those extremes: disclose observable history, preserve evidence, price remediation and give the successor a route to establish current conduct.

How to measure tail duration honestly

A credible study would begin with observed lease transitions, not inferred moral categories. For each prefix, it would establish a control interval using agreements or authenticated attestations, then compare registration, BGP, DNS and service evidence. It would capture reputation from named sources repeatedly before, during and after handback.

The unit of analysis must match the source. Address-level entries, /24 classifications, ASN scores and domain reputation cannot be merged into one count. Public DNSBL status, private mail outcomes, geolocation and fraud challenges require separate outcome measures.

The study needs a comparison group. Similar non-leased prefixes, cloud reassignments or longer leases can help distinguish a lease tail from ordinary reputation persistence. Service type, address size, origin changes and prior use should be controlled where possible.

Define the tail explicitly: time from verified end of the relevant behavior or control period to removal, correction, score recovery or stable acceptance. These are different endpoints. Some sources may never expose enough data to calculate one.

Censoring must be visible. A listing still present when observation ends has an unknown longer duration; it should not be treated as removed on the last day. A private score that cannot be queried is missing, not clean. A vendor correction accepted but not observed by customers is an intermediate state.

Provenance analysis should identify copied signals. Correlated removals may reflect a shared upstream feed rather than independent reassessment. Provider versions and query dates must be retained.

Privacy can be protected by publishing aggregates, ranges of duration, source categories and de-identified case summaries. Researchers do not need customer names or lease prices to show where correction fails.

Until such multi-system longitudinal evidence exists at broad scale, claims should stay bounded. Selected studies and operational cases can justify better fields and appeals. They cannot produce one global percentage for "leased IPv4 reputation."

A practical ninety-day tail plan

Thirty days before an expected lease end, review active incidents, public listings, location records, reverse DNS, route authorization and customer dependencies. Open corrections that require the current lessee's authentication while it still has staff and access.

At handback, capture exact route withdrawal and service termination times. Preserve the final contact state, unresolved case references and required logs. Remove stale operational artifacts. Do not assign the prefix to the next user while obvious hostile traffic continues.

During the first seven days, monitor for surviving announcements, residual DNS, fresh complaints and provider responses. Route historical complaints to the outgoing lessee by incident time. Route current observations to the new operator.

By thirty days, recheck the named public lists, major intended-use services and geolocation releases. Escalate corrections with the change-of-control packet. Distinguish provider acceptance from downstream propagation.

By ninety days, close cases that have objective resolution, release contractual holdbacks according to agreed tests and document unresolved private uncertainty. If adverse behavior recurred under the new operator, treat it as new evidence rather than extending the old case by assumption.

The dates are a management example, not a universal decay schedule. High-risk command infrastructure may justify longer review. Rapid automated listings may clear much sooner. The value of the plan is that someone owns each check and that the successor does not discover the tail only after customers complain.

Registries can prove periods without certifying reputation

Registration services can help by issuing dated receipts for recognized holder and operational-contact changes. They can preserve historical state under controlled access, authenticate who may attest to a lease period and expose the most-specific current abuse contact.

They should not label a block clean or dirty. They do not observe every service and should not adjudicate private reputation systems. A registry receipt proves what the registry knows: a recorded relationship or contact changed at a time. It does not prove that harmful behavior stopped.

This narrow evidence is still valuable. A provider deciding an appeal can compare the incident time with authenticated control periods. A successor no longer has to disclose an entire contract to establish that it arrived later. A lessor can show continuity between handback and new use.

Historical access should be privacy-aware. The public may need organization-level period information and a relay, not personal contacts or customer lists. Sensitive records can be disclosed to an authenticated provider or lawful authority for a defined case.

Portability matters. A receipt should remain verifiable if the parties use another registration service. Reputation correction should not depend on permanent membership in one private institution. Common fields and signatures can support independent verification.

Most importantly, contact failure or an adverse report should not become a pretext to confiscate or suppress the resource. The registry improves accountability by maintaining truthful records. Enforcement of contracts, crime and service rules belongs with the parties and competent authorities that possess the relevant powers and safeguards.

Better reputation makes leasing more accountable, not less possible

Short leases create real risk. A malicious lessee can consume the value of an address range and leave. A careless lessee can impose cleanup costs on the holder and successor. A lessor that turns space too quickly can expose new customers to old harm.

Those risks do not justify a ban. Leasing supplies operators that cannot buy scarce IPv4 space, allows temporary capacity and puts idle blocks into productive use. Prohibition would not eliminate delegation, cloud tenancy or address reuse. It would reduce the incentive to document them.

The accountability model should instead make the reputation life cycle visible. Baseline before use. Named checks rather than broad assurances. Accurate abuse contacts. Monitoring during the term. Dated handback. Historical cooperation. Change-of-control evidence. Provider-specific correction. Proportionate decay. Appeal with a reasoned outcome.

Providers gain too. Better control data improves model accuracy and helps distinguish evasion from genuine succession. A bad actor claiming a fictitious lease can be tested against routing, registration, DNS, identity and continuing behavior. A good-faith operator can establish a discontinuity rather than asking for blind trust.

The resulting market will not make every address equally valuable. History, service type and remediation cost will still matter. But the discount becomes measurable and contestable instead of permanent folklore.

An address can carry memory without carrying guilt. The event record may remain: this address was observed doing a particular thing at a particular time. The decision about today's operator must be made again, using current control and current behavior.

That is the governing distinction. Preserve history; do not fossilize identity. A short lease should not buy instant absolution for an abusive user, and it should not impose an endless sentence on the next one.

The Internet will never forget in one coordinated moment because it never remembers through one system. Fairness therefore depends on each system stating what it knows, when it knew it, where the claim came from and how a changed operator can be heard.

Sources