AFPUB-2018-GEN-001-DRAFT03-5
30 removals
58 lines
21 additions
51 lines
AFPUB-2018-GEN-001-DRAFT03
AFPUB-2018-GEN-001-DRAFT05
8.1 Introduction
8.1 Introduction
This policy specifies a mandatory object that must be used to publish abuse public contact information within the AFRINIC service region.
This policy specifies a mandatory attribute (abuse-c) 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.
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”
8.2 Description of “abuse-c” and “abuse-mailbox”
Resources allocated/assigned 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.
Resources allocated/assigned by AFRINIC must include a mandatory "abuse-c" contact attribute (abuse contact), pointing to a person or role, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving 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.
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.
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.
Following usual practices, other "e-mail" attributes may be included for other purposes.
8.3 About the "abuse-mailbox"
8.3 About the "abuse-mailbox"
Emails sent to "abuse-mailbox" must require manual intervention by the recipient at some point, and may not be filtered, because in certain cases this might prevent receiving the 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 will imply that each company that needs to report abuse cases (a task that is typically automated), would be forced to develop a specific interface for each ISP in the world that mandates filling forms, 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 for by the those whose client causes the abuse (and from whom they obtain income).
Emails sent to "abuse-mailbox":
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).
• Require intervention by the recipient.
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.
• Must not require the reporter to complete a form.
Commonly, if a ticket number has been generated, it should be kept (typically as part of the subject) through successive communications.
• Must guarantee that abuse reports and related logs, examples, or email headers are received.
8.4 Objectives of "abuse-c"/"abuse-mailbox" validation
8.4 Objectives of "abuse-c"/"abuse-mailbox" validation
The procedure, which will be developed by AFRINIC, must meet the following objectives:
The procedure, which will be developed by AFRINIC, must meet the following objectives:
1) 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.
1. A simple process that guarantees the abuse contact is able to fulfil its intended purpose.
2) Avoid exclusively automated processing.
3) 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.
4) Validation period of no longer than 15 days.
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.
5) If validation fails, escalate to the LIR and set a new validation period not to exceed 15 days.
3. Initial validation period of no longer than 15 days.
The “initial” and “escalation” validation periods may be modified by AFRINIC, 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.
4. If validation fails, escalate to other LIR contacts and set a new validation period not to exceed 15 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"
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 6 months, and whenever AFRINIC sees fit.
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 6 months, and whenever AFRINIC sees fit.
Lack of compliance will lead to a more exhaustive follow-up, warnings and blocking of certain services, at AFRINIC discretion, in accordance with the relevant policies/procedures.
The frequency of the periodic validation could be modified if the AFRINIC 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.
8.6 Escalation to AFRINIC
8.6 Escalation to AFRINIC
In order to allow escalation of 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), an escalation method should be provided, thus allowing for a re-validation (according to section 8.5 above).
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) can be reported to AFRINIC for a re-validation (as per section 8.5 above).