Validation of "abuse-mailbox"

Summary of Proposal:

The current policy, “Abuse Contact Management in the RIPE Database” does not sufficiently validate the actual availability of the abuse-mailbox. It provides a technical validation that the mailbox/server exists – but not whether it will accept new messages, whether it belongs to the right person/team to follow up the abuse case, or even if it is monitored.

As a result, some resource holders (LIRs and End Users) might not keep this contact information up to date, or might use a non-responsive or fake mailbox. In practice, this contact becomes ineffective to report abuse and generally gives rise to security issues and costs for the victims.

This proposal aims to solve this problem by ensuring the existence of a proper abuse-c contact and establishing a process for its utilisation.

Policy Text:

a. Current Policy text (ripe-705)

1.0 Abuse Contact Information

[…]

The RIPE NCC will validate the “abuse-mailbox:” attribute at least annually. Where the attribute is deemed incorrect, it will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures.

As per current practice, other "e-mail:" attributes can be included for any other purposes. 

b. New Policy text

1.0 Abuse Contact Information

[…]

The RIPE NCC will validate the “abuse-mailbox:” attribute at least every six months. Where the attribute is deemed incorrect, it will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures.

As per current practice, other "e-mail:" attributes can be included for any other purposes.

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 received

3.0 Objectives of "abuse-mailbox" validation

The procedure, which will be developed by the RIPE NCC, must meet the following objectives:

1. A simple process that guarantees the abuse contact is able to fulfil its intended purpose.
   
   
2. 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.
   
   
3. Initial validation period of no longer than 15 days.
   
   
4. If validation fails, escalate to other LIR contacts and set a new validation period not to exceed 15 days.

4.0 Validation of “abuse-mailbox"

The RIPE NCC will validate compliance with the items above, both when the "abuse-c:" and/or "abuse-mailbox:" attributes are created or updated, as well as periodically, not less than once every six months, and additionally whenever RIPE NCC sees fit.

Lack of compliance will lead to a more exhaustive follow-up, in accordance with the relevant RIPE NCC policies, procedures or contractual requirements.

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.

Additional information:

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.

Similarly, the frequency of the periodic validation can be modified if the RIPE NCC deems this appropriate and informs the community of its reasons for doing so.

For example, a single validation might be done in the first year to facilitate adherence to the policy. The number of annual validations could increase over time, perhaps becoming quarterly, with the aim of improving the quality of the contacts.

Rationale:

a. Arguments Supporting the Proposal

The Internet community is based on collaboration. However, in many cases this is not enough and we need to be able to contact those resource-holders (LIRs or End Users) who may be experiencing a problem in their networks and are unaware of the situation.

This proposal solves this problem by means of a simple, periodic verification, and establishes basic rules for performing such verification. It thus avoids unnecessary costs to third parties who need to contact the persons responsible for solving abuse from a specific network.

The proposal guarantees that the cost of processing the abuse report falls on the resource holder responsible (or its customers, from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to a legal claim. This avoids costs in terms of investigations (and lawyers, solicitors, etc. in the worst-case) and saves time for both parties.

Having an equivalent policy in different regions has the advantage of improving the overall response to abuse cases, reduces the cost for handling them, and facilitates the work of all people involved in the operation of the Internet.

b. Arguments Opposing the Proposal

RIPE NCC members have to verify and update (if required) their abuse-c objects periodically.

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.