You're looking at an older version: 1
The current (published) version is 3The current policy, “Abuse Contact Management in the RIPE Database” does not provide sufficient validation of the actual availability of the abuse-mailbox.
As a result, some resource-holders (LIRs and end-users) might not keep this contact information up to date, might use a non-responsive mailbox (which could be full or not actively monitored), or might even use a 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 and ensure the existence of a proper abuse-c contact and the process for its utilisation.
[…]
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.
[…]
The RIPE NCC will validate the “abuse-mailbox:” attribute at least every six months, as per the procedure stated in this policy. 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.
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.
The "abuse-mailbox" may initially send an automatic reply, for example assigning a ticket number, applying classification procedures, requesting further information, etc. However, it should not require that the abuse reporter fills a form, as this would imply that each entity that needs to report an abuse case (a task that is typically automated) would be forced to develop a specific interface for each resource holder in the world that mandates filling forms. That scenario would be neither feasible nor logical, as it would place the cost of processing the abuse on those who submit the claim and are therefore victims of the abuse, instead of being paid for by those whose clients cause the abuse (and from whom they obtain income).
By way of information, it is worth noting that it is reasonable to expect that the abuse reporting procedure sends, with the initial abuse report, the logs, a copy of the spam message (attaching an example of the spam email or its full headers), or equivalent evidence (depending on the abuse type). Likewise, it is reasonable to expect that the initial auto-reply email could specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender an opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved. Commonly, if a ticket number has been generated, it should be kept (typically as part of the subject) through successive communications.
The procedure, which will be developed by the RIPE NCC, must meet the following objectives:
The “initial” and “escalation” validation periods may be modified by the RIPE NCC, if deemed appropriate, informing the community about the motivation. For example, it could be longer for the first validation, once this policy is implemented, and shortened afterwards once the percentage of failures decreases, so the quality of the contacts increases and consequently a decrease in the average abuse response times could be expected.
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 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.
The frequency of the periodic validation could be modified if the RIPE NCC deems this appropriate and informs the community of its reasons. For example, a single validation could be done in the first year, to facilitate adherence to the policy, and then the number of annual validations could progressively increase, reaching even quarterly ones, with the aim of improving the quality of the contacts.
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 response to cases of abuse) can be reported to the RIPE NCC for a re-validation as per section 4.0.
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 who are unaware of the situation.
This proposal solves this problem by means of a simple, periodic verification, and establishes the basic rules for performing such verification. It thus avoids unnecessary costs to third parties that need to contact the persons responsible for solving the abuses of a specific network.
The proposal guarantees that the cost of processing the abuse falls on the resource-holder causing the abuse (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 in an extreme case, thus avoiding costs (investigation and in the worst-case lawyers, solicitors, etc.) and saving time for both parties.
Having an equivalent policy in different regions, has the advantage of improving overall response to abuse cases, reduces the cost for handling them, and facilitates the work of all the people involved in the operation of Internet.
RIPE NCC members have to verify and update (if required) their abuse-c objects periodically.
A similar proposal has been accepted in APNIC (being implemented) and is under discussion in the LACNIC, AFRINIC and ARIN regions.
The following text is an example of the validation procedure, considering common practices in helpdesk, that for example disallow them to click a link in an html email in order to avoid phishing, etc. Even if this is not part of the policy text, it is strongly suggested that the RIPE NCC consider it, as this is advice that has been provided by the community in the existing abuse-c policy proposal discussion.