Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] New proposal: Abuse Contact Policy Update

Wed Oct 10 19:30:06 UTC 2018

Hi Amreesh,


First of all, thanks for contributing!


Not really. What I’m proposing is to have it mandatory and verified.


Naming it IRT or abuse-c/abuse-mailbox is not the key thing.


In fact, we can keep both, the IRT object and the abuse-c and make the whois in such way that respond with the same data to queries for IRT or abuse-c.


This was we suggested in APNIC, which have also IRT (while the other RIRs have the abuse-c).






De: Amreesh Phokeer <amreesh.phokeer at>
Fecha: miércoles, 10 de octubre de 2018, 21:20
Para: Jordi Palet Martinez <jordi.palet at>
CC: <rpd at>
Asunto: Re: [rpd] New proposal: Abuse Contact Policy Update


Hi Jordi,


Currently there is the "mnt-irt" attribute (IRT object) which is optional in inet(6)num and aut-num objects, which I suppose was intended to have the similar purpose as the "abuse-c" you are proposing.

Indeed, the use of the IRT objects in the WHOIS database is almost nil [1], mainly due to the fact that it is optional. 


That's the IRT object:


$ whois -t irt

% This is the AfriNIC Whois server.


irt:            [mandatory]  [single]     [primary/lookup key]

address:        [mandatory]  [multiple]   [ ]

phone:          [optional]   [multiple]   [ ]

fax-no:         [optional]   [multiple]   [ ]

e-mail:         [mandatory]  [multiple]   [lookup key]

abuse-mailbox:  [mandatory]  [multiple]   [inverse key]

signature:      [optional]   [multiple]   [ ]

encryption:     [optional]   [multiple]   [ ]

org:            [optional]   [multiple]   [inverse key]

admin-c:        [mandatory]  [multiple]   [inverse key]

tech-c:         [mandatory]  [multiple]   [inverse key]

auth:           [mandatory]  [multiple]   [inverse key]

remarks:        [optional]   [multiple]   [ ]

irt-nfy:        [optional]   [multiple]   [inverse key]

notify:         [optional]   [multiple]   [inverse key]

mnt-by:         [mandatory]  [multiple]   [inverse key]

changed:        [mandatory]  [multiple]   [ ]

source:         [mandatory]  [single]     [ ]


Would making the "mnt-irt" mandatory solve parts referring to “abuse-c” and “abuse-mailbox” in your proposal?


+1 for the two-factor verification mechanism proposed








[views are my own]


On Thu, Aug 23, 2018 at 12:54 PM Ernest Byaruhanga <ernest at> wrote:


A new policy proposal has been received as follows, for which the community is encouraged to study and constructively discuss, as it touches a sensitive and important aspect of whois data accuracy:



Proposal: Abuse Contact Policy Update
Amends: CPM article 8.0 (“Abuse” contact information)
Author: Jordi Palet Martinez

1.0  Summary of the problem being addressed by this proposal

The current policy doesn’t imply the obligation to register an abuse contact and specifies a format for personal communication and for “automatic reporting”, which - compared to other RIRs, becomes confusing, as a single email will be more efficient, as at the end, reports get copied to both emails.

As a result, some LIRs may not have this contact information registered for their resources. In fact, there are even cases of LIRs that use a non-existent mailbox or one that is not actively monitored.

In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues and costs for the victims.

This proposal aims to solve the problem and ensure the existence of a proper abuse-c contact and the process for its utilization, which is more uniform across all the RIRs, in order to facilitate cross-region abuse reporting.

2.0  Summary of how this proposal addresses the problem

The Internet community is based on collaboration. In many cases, however, this is not enough and we all need to be able to contact those LIRs which may be experiencing a problem in their networks and may not be aware of the situation.

This proposal creates a new section in the Policy Manual to solve this problem by means of a simple, periodic verification, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties who 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 LIR whose client is causing the abuse (and 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 the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties.

For this, the abuse-c attribute becomes mandatory in the “aut-num”, "inetnum" and "inet6num" objects, as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the "abuse-mailbox" attribute.

The proposal is expected to be implemented in 90 days, to be confirmed by AfriNIC, a reasonable time frame to allow both the staff to develop the tool and the LIRs to update their abuse-c contacts.

3. Proposal

Amending 8.0 of the CPM, as follows:
(Side by side of current vs proposed content at

8.1 Introduction

This policy specifies a mandatory object that must be used to publish abuse public contact information within the AFRINIC service region.

The mentioned object must be referenced in the inetnum, inet6num and aut-num objects in the AFRINIC whois Database. It provides a more accurate and efficient way for abuse reports to reach the correct contact.

8.2 Description of “abuse-c” and “abuse-mailbox”

All resources allocated by AFRINIC must include a mandatory "abuse-c" contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving manual or automatic reports regarding abusive behavior, security issues, and the like.

The "abuse-mailbox" attribute must be available in an unrestricted way via whois, APIs and future techniques.

Considering the hierarchical nature of IP address objects, child objects of those directly distributed by AFRINIC may be covered by parent objects or they may have their own "abuse-c" attribute.

Following usual practices, other "e-mail" attributes may be included for other purposes.

8.3 About the "abuse-mailbox"

Emails sent to "abuse-mailbox" must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of the abuse reports, for example – in the case of spam, as it would 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 may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, which is 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 by those whose client causes the abuse (and from whom they obtain income).

By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start and in that first report, sending the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved.

8.4 Objectives of "abuse-c"/"abuse-mailbox" validation

The procedure, which is to be developed by AFRINIC, must meet the following objectives:

a) A simple process that guarantees its functionality and allows the helpdesks that deal with abuse reports to verify that validation requests actually come from AFRINIC and not from third parties (which might involve security risks), avoiding, for example, a single "direct" URL for validation.

b) Avoid automated processing.

c) Confirm that the person performing the validation understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", that measures are taken, and that the abuse report receives a response.

d) Validation period should be no longer than two (2) business days.

e) If validation fails, escalate to the LIR and set a new validation period not to exceed three (3) business days.

(By way of example, a detailed procedure is included in this policy proposal under "Additional Information").

8.5 Validation of "abuse-c"/"abuse-mailbox"

AFRINIC 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 three months, and whenever AFRINIC sees fit.

At the discretion of AFRINIC, in general or in specific cases (for example, for confirmation in cases of escalation under 8.6), AFRINIC may use domains other than afrinic.*, and even modify the subject and body of the message, in order to perform said validations more effectively.

Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant AFRINIC policies / procedures, especially those related to revocation of resources.

8.6 Escalation to AFRINIC

To avoid fraudulent behavior (for example, an "abuse-mailbox" that only replies to AFRINIC’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) and, therefore, to guarantee the quality of the services in the region with the resources allocated by AFRINIC, a mailbox will be available (for example, "abuse-escalation at"), to escalate such situations, thus allowing for a re-validation (according to section 8.5 above) and even the intermediation by AFRINIC and, where appropriate, the application of the relevant policies/procedures, especially those related to revocation of resources.

8.7 Additional Information

Example of the validation procedure.

a) AFRINIC initiates the validation automatically, sending TWO consecutive emails to the "abuse-mailbox".
b) These emails will be sent containing plain text only.
c) The first email will contain the URL where the validation is to be performed ("") and may contain information about the procedure, a brief summary of this policy, etc.
d) The second email will contain a unique alphanumeric validation code.
e) 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.
f) This URL must be designed in such a way that it prevents the use of an automated process (for example, "captcha"). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", that measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a "checkbox" that must be accepted in order to proceed.
g) The alphanumeric code will only be valid for a maximum of two working days.
h) If the code is not entered within that time, the system will mark the "abuse-c" as "temporarily invalid” and will alert AFRINIC staff so that they can initiate a personalized follow-up with the LIR.
i) If no reply is received confirming that the situation has been corrected, after an additional period of three business days, the "abuse-c" will be permanently marked as "invalid".
j) The validation process will be repeated automatically (items ‘a’ to ‘g’ above). If satisfactory, the "abuse-c" will be marked as "valid"; otherwise it will be considered in breach of the policy.

4. Revision History

Date 12 March 2018 | Version 1: AFPUB-2018-V6-005-DRAFT01
Details :Initial Draft Posted to rpd

5. References

A similar proposal has been discussed in the RIPE region and is waiting for co-chairs to declare consensus.

RPD mailing list
RPD at



Amreesh Phokeer

IPv4 is over
Are you ready for the new Internet ?
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list