Ce qui a changé
Aucun changement de politique ne peut être établi, car la chronologie vérifiée est vide et aucune version, modification ou étape de traitement n’est fournie.
RIPE NCC · Veille des RIR
Commencez ici pour consulter l’historique, proposition par proposition : ce qui a changé, pourquoi cela comptait, qui a défendu quoi, comment les positions ont évolué, ce qui a été décidé et quelles lacunes subsistent dans les preuves.
Faits sourcés
Qui a réellement façonné le débat ?
Analyse BTW
Aucun changement de politique ne peut être établi, car la chronologie vérifiée est vide et aucune version, modification ou étape de traitement n’est fournie.
L’objet substantiel du débat ne peut pas être déterminé à partir des faits fournis : aucun message, argument, participant, acteur formel ou position codée n’est enregistré.
Les données ne documentent ni discussion ni décision. Avec zéro message, zéro participant et zéro acteur formel enregistrés, elles ne permettent pas de distinguer une adoption, un rejet, un retrait, un abandon ou une lacune documentaire.
Tous les indicateurs de participation et de concentration sont nuls parce que le corpus mesuré ne contient aucun message ni participant. Ces valeurs ne démontrent donc ni une participation équilibrée ni une concentration de l’influence ; aucune distribution effective de la participation n’est observable.
Aucun point de blocage procédural, institutionnel ou argumentatif ne peut être identifié : aucune étape chronologique, intervention d’acteur formel, position attribuée ou décision n’est fournie.
Receipt of abuse reports · Version 2.0 replaces the detailed mailbox-handling passage with three requirements: recipient intervention, no mandatory reporting form, and guaranteed receipt of reports and supporting logs, examples or headers. It removes the express no-filtering wording and the explanatory guidance about automatic replies, evidence resubmission and ticket continuity. Guaranteed receipt remains a requirement; the shorter wording does not establish permission to discard reports.
Emails sent to "abuse-mailbox" require manual intervention by the recipient at some point, and may not be filtered, because in certain cases this might prevent receiving abuse reports, for example in a spam case where the abuse report could include the spam message itself or URLs or content usually classified as spam.Faits sourcés ↗
2.0 About the "abuse-mailbox" Emails sent to "abuse-mailbox": Require intervention by the recipient Must not require the reporter to complete a form Must guarantee that abuse reports and related logs, examples, or email headers are receivedFaits sourcés ↗
Validation procedure safeguards · Version 2.0 removes the explicit objectives of authenticating RIPE NCC validation requests and avoiding exclusively automated validation. It still requires confirmation that the resource holder understands the policy, monitors the mailbox, takes measures and responds to reports. The initial and escalation periods remain capped at 15 days each, with escalation now expressly directed to other LIR contacts.
A simple process that guarantees its functionality and allows the helpdesks that deal with abuse reports to verify that validation requests actually come from the RIPE NCC and not from third parties (which might involve security risks), avoiding, for example, a single "direct" URL for validation. Avoid exclusively automated processing.Faits sourcés ↗
A simple process that guarantees the abuse contact is able to fulfil its intended purpose. Confirm that the resource holder understands the procedure and the policy, that they regularly monitor the abuse-mailbox, that measures are taken, and that abuse reports receive a response.Faits sourcés ↗
Non-binding implementation example · Version 2.0 omits the earlier non-policy example involving two validation emails, a separate code, CAPTCHA, acknowledgement checkbox and invalid-contact states. Its additional-information section instead explains discretion over validation periods and frequency. This removes suggested implementation detail rather than repealing a previously binding two-email procedure.
The second email will contain a unique alphanumeric validation code. The person in charge of the "abuse-mailbox" must go to the URL and paste the code received in the second email in the form. This URL must be designed in such a way that it prevents the use of an automated process (for example, "captcha").Faits sourcés ↗
As a matter of clarification, the “initial” and “escalation” validation periods may be modified by the RIPE NCC, if deemed appropriate, provided it informs the community of its motivation for doing so. For example, in the implementation phase, the periods could be extended, and adjusted as a higher percentage of contacts become accurate.Faits sourcés ↗
Regional comparison · The historical comparison changes ARIN from a region where a similar proposal was under discussion to one where it was abandoned. APNIC remains listed as having accepted a similar proposal, while LACNIC and AFRINIC remain under discussion. These are statements in the compared snapshots, not a claim about current regional policy.
c. Alignment with other RIRs: A similar proposal has been accepted in APNIC (being implemented) and is under discussion in the LACNIC, AFRINIC and ARIN regions.Faits sourcés ↗
Alignment with other RIRs A similar proposal has been accepted in APNIC, abandoned in ARIN and is under discussion in the LACNIC and AFRINIC regions.Faits sourcés ↗
Scope of mailbox validation · Version 3.0 narrows validation to whether the abuse-mailbox attribute is present and can receive messages. It expressly excludes checking how abuse cases are processed and says the intent is not to examine mailbox monitoring or case handling. This replaces version 2.0's confirmation that the holder monitors the mailbox, takes measures and responds to reports.
Confirm that the resource holder understands the procedure and the policy, that they regularly monitor the abuse-mailbox, that measures are taken, and that abuse reports receive a response.Faits sourcés ↗
This validation process will not check how the abuse cases are processed. The community should escalate/report back to the RIPE NCC, so anonymised statistics can be collected and periodically published.Faits sourcés ↗
Validation timing and escalation · Version 3.0 retains a six-month default but allows the RIPE NCC to change it according to contact accuracy, expressly giving a move to annual validation as an example. It omits the two explicit 15-day validation periods and the express creation/update validation trigger from version 2.0, while retaining follow-up under relevant RIPE policies and procedures after failure.
Initial validation period of no longer than 15 days. If validation fails, escalate to other LIR contacts and set a new validation period not to exceed 15 days.Faits sourcés ↗
*The RIPE NCC may change the validation period depending on the level of accuracy of the contacts. For example, switching from a six-month to one-year period once contact accuracy has improved.Faits sourcés ↗
Abuse-report transport · The new proposed policy incorporates the requirement to receive both automatic and manual reports into the abuse-mailbox definition, names X-ARF/RFC5965/RFC6650 as automatic-report examples, and retains the prohibition on forcing the sender to use a form. The former separate requirement for recipient intervention is absent from that definition.
2.0 About the "abuse-mailbox" Emails sent to "abuse-mailbox": Require intervention by the recipient Must not require the reporter to complete a form Must guarantee that abuse reports and related logs, examples, or email headers are receivedFaits sourcés ↗
The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute, which must receive messages, either for automatic (e.g. X-ARF/RFC5965/RFC6650) or manual reports about abusive behaviour originating in the resource holders' networks and must not force the sender to use a form.Faits sourcés ↗
Community reporting and statistics · The earlier section explicitly invited reports of fraudulent or non-compliant mailbox behaviour for re-validation. Version 3.0 instead calls for community escalation/reporting so anonymised statistics can be collected and periodically published, with the additional explanation that the community can use them for further decisions. It does not retain the earlier enumerated fraud examples or promise that every such report triggers the former section 4.0 re-validation.
5.0 Escalation to the RIPE NCC Fraudulent behaviour (for example, an "abuse-mailbox" that only replies to the RIPE NCC's emails or to messages with a specific subject or content), or failure to comply with the remaining aspects of this policy (incorrect or lack of responses to abuse cases) can be reported to the RIPE NCC for a re-validation as per section 4.0.Faits sourcés ↗
The community should escalate/report back to the RIPE NCC, so anonymised statistics can be collected and periodically published.Faits sourcés ↗
Appeal history · The version 3.0 snapshot adds a dated account of the proposer's 5 October 2020 appeal and the WG Chairs Collective's 26 October 2020 decision to uphold the Anti-Abuse Working Group co-chairs' decision. The version 2.0 snapshot has no corresponding appeal account. The addition records process history; it does not demonstrate adoption of the proposal.
This proposal aims to solve this problem by ensuring the existence of a proper abuse-c contact and establishing a process for its utilisation.Faits sourcés ↗
Appeal: The proposer appealed against the decision of the WG Chairs on October 5, 2020 https://www.ripe.net/ripe/mail/archives/policy-announce/2020-October/000569.html Outcome of the Appeal: October 26, 2020 - The WG Chairs Collective (WGCC) decided to uphold the decision of the Co-Chairs of the Anti-Abuse Working Group. https://www.ripe.net/ripe/mail/archives/policy-announce/2020-October/000571.htmlFaits sourcés ↗
Regional comparison · Version 3.0 describes APNIC's similar proposal as implemented and LACNIC's as accepted, keeps AFRINIC under discussion, and says ARIN has a similar policy. The preceding snapshot described LACNIC as under discussion and an ARIN proposal as abandoned. These statements are preserved as historical snapshot differences, without treating a policy's existence and a particular proposal's outcome as equivalent.
Alignment with other RIRs A similar proposal has been accepted in APNIC, abandoned in ARIN and is under discussion in the LACNIC and AFRINIC regions.Faits sourcés ↗
References: A similar proposal has been accepted in APNIC (already implemented) and LACNIC. It is under discussion in AFRINIC. ARIN has a similar policy.Faits sourcés ↗
Partielle
Première capture: 30 juin 1992
Dernière capture: 30 oct. 2026