Changes to Validation of "abuse-mailbox"
| Legend | (+) Added | (-) Deleted |
|---|---|---|
| Changed | Tag Added | Tag Deleted |
Summary of Proposal:
The current policy, “Abuse Contact Management in the RIPE Database” does not provide sufficient validation of 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 resource holders (LIRs and end-users) End Users) might not keep this contact information up to date, or might use a non-responsive mailbox (which could be full or not actively monitored), or might even use a or fake mailbox. delete: </p> delete: <p> 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 by ensuring the existence of a proper abuse-c contact and the establishing a process for its utilisation. 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.
delete: <p> delete: <strong> delete: </strong> delete: </p>b. New Policy text
1.0 Abuse Contact Information
[…]
The RIPE NCC will validate the “abuse-mailbox:” attribute at least every six months, as per the procedure stated in this policy. 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. purposes.
2.0 About the "abuse-mailbox"
Emails sent to "abuse-mailbox" require manual "abuse-mailbox": insert: </p>
insert: <ul>- insert: <li>
- Require 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. delete: </p> delete: <p> 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 insert: </li> insert: <li>
- Must not require the reporter to complete a form insert: </li> insert: <li>
- Must guarantee 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 reports and related logs, examples, or email headers are therefore victims of the abuse, instead of being paid for by those whose clients cause the abuse (and from whom they obtain income). delete: </p> delete: <p> 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. delete: </p> received insert: </li> insert: </ul>
3.0 Objectives of "abuse-mailbox" validation
The procedure, which will be developed by the RIPE NCC, must meet the following objectives:
- A simple process that guarantees the abuse contact is able to fulfil 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. delete: <br /> delete: <br /> delete: </li> delete: <li> Avoid exclusively automated processing. intended purpose.
- Confirm that the person performing the validation resource holder understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", abuse-mailbox, that measures are taken, and that the abuse report receives reports receive a response.
- Validation Initial validation period of no longer than 15 days.
- If validation fails, escalate to the 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. delete: </p> delete: <p> 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.
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 response to cases of abuse) responses to abuse cases) can be reported to the RIPE NCC for a re-validation as per section 4.0.
insert: <h3>
Additional information: insert: </h3>
insert: <p>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. insert: </p>
insert: <p>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. insert: </p>
insert: <p>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. insert: </p>
insert: <p>insert: </p>
Rationale: 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) 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 who need to contact the persons responsible for solving the abuses of abuse from a specific network.
The proposal guarantees that the cost of processing the abuse report falls on the resource-holder causing the abuse 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 in an extreme case, thus avoiding claim. This avoids costs (investigation and in the worst-case in terms of investigations (and lawyers, solicitors, etc.) and saving etc. in the worst-case) and saves time for both parties.
Having an equivalent policy in different regions, regions has the advantage of improving the overall response to abuse cases, reduces the cost for handling them, and facilitates the work of all the 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.
c. Alignment with other RIRs: RIRs
A similar proposal has been accepted in APNIC (being implemented) APNIC, abandoned in ARIN and is under discussion in the LACNIC, LACNIC and AFRINIC and ARIN regions.
delete: <p> delete: </p> delete: <h3> Additional information: delete: </h3> delete: <p> 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. delete: </p> delete: <ol> delete: <li> The RIPE NCC initiates the validation automatically, sending TWO consecutive emails to the "abuse-mailbox". delete: </li> delete: </ol> delete: <ol start="2"> delete: <li> These emails will be sent containing plain text only. delete: </li> delete: </ol> delete: <ol start="3"> delete: <li> At the discretion of the RIPE NCC, in general or in specific cases (for example, for confirmation in cases of escalation under 5.0, the RIPE NCC may use domains other than ripe.*, and even modify the subject and body of the message, in order to perform said validations more effectively. delete: </li> delete: </ol> delete: <ol start="4"> delete: <li> The first email will contain the URL where the validation is to be performed ("validation.ripe.net") and may contain information about the procedure, a brief summary of this policy, etc. delete: </li> delete: </ol> delete: <ol start="5"> delete: <li> The second email will contain a unique alphanumeric validation code. delete: </li> delete: </ol> delete: <ol start="6"> delete: <li> 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. delete: </li> delete: </ol> delete: <ol start="7"> delete: <li> 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. delete: </li> delete: </ol> delete: <ol start="8"> delete: <li> The alphanumeric code will only be valid for a maximum of 15 days. delete: </li> delete: </ol> delete: <ol start="9"> delete: <li> If the code is not entered within that time, the system will mark the "abuse-c" as "temporarily invalid” and will alert RIPE NCC staff so that they can initiate a personalised follow-up with the LIR. delete: <br /> delete: <br /> delete: </li> delete: <li> If no reply is received confirming that the situation has been corrected, after an additional period of 15 days, the "abuse-c" will be permanently marked as "invalid". delete: <br /> delete: <br /> delete: </li> delete: <li> The RIPE NCC must ensure that all possible means of “warning” the resource-holder are put in place, such as periodic emails to other email boxes, alert pop-ups, etc. All those must contain the policy text and reminders about consequences in case of continued policy violation. Means of blocking access to certain services should be also considered. delete: </li> delete: </ol> delete: <ol start="12"> delete: <li> Once the issue has been resolved, the validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the "abuse-c" will be marked as "valid"; otherwise it will be considered in breach of the policy. delete: </li> delete: </ol> delete: <ol start="13"> delete: <li> There must be tools such as a form, mailbox, or others in the future, which allow to escalate lack of compliance with this policy. This would allow for a re-validation (according to section 4. above) and even intervention by the RIPE NCC and, where appropriate, the application of the relevant policies, procedures or contractual requirements. delete: </li> delete: </ol> delete: <p> delete: </p>How to read this draft document:
This document relates to the policy proposal 2019-04, “ delete: <a href="../../../../../resolveuid/01c22a908fc14676a254b2b9b76ee098" data-linktype="internal" data-val="01c22a908fc14676a254b2b9b76ee098"> insert: <a href="../../../../../resolveuid/9fb6b39a52a849099c956838a47b4333" data-linktype="internal" data-val="9fb6b39a52a849099c956838a47b4333"> Validation of "abuse-mailbox" ”. If approved, it will modify ripe-705, “ Abuse Contact Management in the RIPE Database ”.
To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.
We indicate changes to existing text in the document like this:
| ORIGINAL TEXT | NEW TEXT |
|---|---|
| The text from the current policy document that will be replaced is displayed here. | The proposed text change will be displayed here. |
Abstract
This policy originated from the work of the Abuse Contact Management Task Force. The task force examined the collection and maintenance of resource registration information in the RIPE Database, including potential areas for improvement and alternative approaches.
This policy introduces a new contact attribute named "abuse-c:”, that can be included in inetnum , inet6num and aut-num objects.
Content
| 2.0 Attribution | 2.0 About the "abuse-mailbox" |
1.0 Abuse Contact Information
The "abuse-c:" will reference a role object holding abuse contact information. The positioning of the “abuse-c:” attributes will make use of the hierarchical nature of the resource data to minimize the workload on resource holders. Internet number resources need to have an “abuse-c:” attribute.
The “abuse-c:” will be mandatory for all aut-num s.
Due the hierarchical nature of IP address objects, at least every direct allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited objects might have their own “abuse-c:” attribute or they will be covered by the higher level objects.
The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders' networks.
The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.
This document is developed by the RIPE community.
The following people actively contributed by making proposals through the RIPE Policy Development Process:
Tobias Knecht