You are here: Home > Participate > Policy Development > Policy Proposals > Validation of "abuse-mailbox"

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 if it accepts new messages 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, up-to-date or might use a non-responsive mailbox (which could be full or not actively monitored), or might even use a 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.

The RIPE NCC impact analysis of 2017-02, which turned into ripe-705, already recognised that false negatives and false positives are possible, and that there is a need to avoid them. insert: </p>

insert: <p>

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.  delete: </p> delete: <p>  

Policy Text:

a. Current Policy text Text ( ripe-705 )

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.  insert: </p>

insert: <p>

The “abuse-c:” will be mandatory for all aut-nums. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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

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: <p> delete: <strong>   delete: </strong> purposes.

b. New Policy text Text

1.0 Abuse Contact Information

[…] delete: </p> delete: <p> The RIPE NCC will validate the 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 minimise the workload on resource holders. Internet number resources need to have an “abuse-c:” attribute.  insert: </p>

insert: <p>

The “abuse-c:” will be mandatory for all aut-nums. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute, which must receive messages, either for automatic (e.g. X-ARF/RFC5965/RFC6650) or manual reports about abusive behaviour originating in the resource holders' networks and must not force the sender to use a form. insert: </p>

insert: <p>

The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques. insert: </p>

insert: <p>

The RIPE NCC will validate if the “abuse-mailbox:” attribute is present and can receive messages at least every six months, as per the procedure stated in this policy. Where the attribute is deemed incorrect, it will follow up months*. If the validation fails, the RIPE NCC will follow-up in compliance with the relevant RIPE Policies and RIPE NCC procedures. insert: </p>

insert: <p>

This validation process will not check how the abuse cases are processed. The community should escalate/report back to the RIPE NCC, so anonymised statistics can be collected and periodically published.

As per current practice, other "e-mail:" attributes can be included for any other purposes.  delete: </p> delete: <h4> 2.0 About the "abuse-mailbox" delete: </h4> delete: <p> Emails sent to "abuse-mailbox" require manual intervention by the recipient at some point, and purposes. insert: </p>

insert: <p>

*The RIPE NCC 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 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 change the validation period depending 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 the level of accuracy of the contacts. For example, switching 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 a six-month to one-year period once contact accuracy 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 improved. insert: </p>

insert: <h3>

Additional information: insert: </h3>

insert: <p>

It should be kept (typically as part of the subject) through successive communications. delete: </p> delete: <h4> 3.0 Objectives of "abuse-mailbox" validation delete: </h4> delete: <p> The procedure, clear that the policy intent is not to look into how the abuse mailbox is monitored or how abuse cases are handled. insert: </p>

insert: <p>

However, the community should report any situation to the RIPE NCC, which will be developed by the RIPE NCC, must meet the following objectives: delete: </p> delete: <ol> delete: <li> A simple process that guarantees 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. delete: <br /> delete: <br /> delete: </li> delete: <li> 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. delete: <br /> delete: <br /> delete: </li> delete: <li> Validation period of no longer than 15 days. delete: <br /> delete: <br /> delete: </li> delete: <li> If validation fails, escalate to the LIR and set a new validation period not to exceed 15 days. delete: </li> delete: </ol> delete: <p> The “initial” and “escalation” validation periods may be modified by the RIPE NCC, if deemed appropriate, informing the community can provide (anonymous) periodical statistics to the community, which can take further decisions 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. delete: </p> delete: <h4> 4.0 Validation of “abuse-mailbox" delete: </h4> delete: <p> 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. delete: </p> delete: <p> 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. delete: </p> delete: <h4> 5.0 Escalation to the RIPE NCC delete: </h4> delete: <p> 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. delete: </p> delete: <p>   that.

Rationale:  Rationale:

a. Arguments Supporting the Proposal

The Internet community is based on collaboration. However, in many cases this is not enough enough, and we need to be able to contact those resource-holders 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 periodical 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 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 Internet. delete: </p> delete: <p>   the Internet. 

b. Arguments Opposing the Proposal Proposal 

RIPE NCC members have to verify and update (if required) their abuse-c objects periodically. delete: </p> delete: <p>   delete: </p> delete: <h3> c. Alignment with other RIRs: delete: </h3> periodically.  insert: </p>

insert: <h2>

References: insert: </h2>

A similar proposal has been accepted in APNIC (being (already implemented) and LACNIC. It is under discussion in the LACNIC, AFRINIC and AFRINIC. ARIN regions. delete: </p> delete: <p>   delete: </p> has a similar policy. insert: </p>

insert: <hr />
insert: <h2>

insert: <a id="impact-analysis"> insert: </a> Impact Analysis insert: </h2>

insert: <h2>

A. The RIPE NCC's Understanding of the Proposed Policy insert: </h2>

Additional information: Definition of “abuse-mailbox:” attribute

The following text is In the context of “ insert: <a href="http://www.ripe.net/publications/docs/ripe-705" data-linktype="external" data-val="http://www.ripe.net/publications/docs/ripe-705"> Abuse Contact Management in the RIPE Database insert: </a> ” and this impact analysis, the term ““abuse-mailbox:” attribute” refers to an example of the email address that is entered in role objects in the RIPE Database. These role objects are referenced as “abuse-c:” attributes directly or indirectly to Internet Number resource objects (such as inetnum, inet6num, aut-num). insert: </p>

insert: <h3>

Scope insert: </h3>

insert: <p>

It is the RIPE NCC’s understanding that this policy change aims to change the abuse-mailbox validation procedure, considering common practices in helpdesk, that process not to just check if the attribute is configured correctly but to ensure that the mailbox can receive messages. insert: </p>

insert: <p>

This proposal also increases the frequency of the validations to every six months. Whilst increasing the current frequency of the validations it also provides the RIPE NCC a possibility to change this frequency in the future again, should the accuracy of the contacts improve. It does not provide an indicator of the levels of accuracy required for example disallow them to click a a change in frequency, leaving it open for the future interpretation of the RIPE NCC.  insert: </p>

insert: <p>

It is the RIPE NCC’s understanding that this policy change considers ““abuse-mailbox:” attributes” which force the sender to use a form in violation of this policy. However, during the validation process the RIPE NCC will only check if “abuse-mailbox:” attribute can receive messages. If the RIPE NCC receives a report with the  insert: <a href="../../../../../resolveuid/b52147b8f01347f7a3ac36a266768ab2" data-linktype="internal" data-val="b52147b8f01347f7a3ac36a266768ab2"> report form insert: </a> that the “abuse-mailbox:” forces the sender to use the form, it will have to follow up in compliance with relevant RIPE Policies and RIPE NCC procedures.. insert: </p>

insert: <p>

Not in scope are “abuse-mailbox:” attributes that are solely referenced in Internet number resources with the status LEGACY. The RIPE Policy “ insert: <a href="http://www.ripe.net/publications/docs/ncc-services-to-legacy-holders#1-2-scope" data-linktype="external" data-val="http://www.ripe.net/publications/docs/ncc-services-to-legacy-holders#1-2-scope"> RIPE NCC Services to Legacy Internet Resource Holders insert: </a> ” requires other RIPE policies to mention legacy resources explicitly in their scope if they are to apply to legacy resources. This is not the case with the proposed policy change. insert: </p>

insert: <p>

Also not in scope for this validation are scenarios where the “abuse-mailbox:” can receive messages but reports are not followed up in a way that the reporter would like. The proposal states that the community should report back such cases to the RIPE NCC, so that anonymised statistics can be collected and periodically published. These reports can be submitted with the  insert: <a href="../../../../../resolveuid/b52147b8f01347f7a3ac36a266768ab2" data-linktype="internal" data-val="b52147b8f01347f7a3ac36a266768ab2"> report form insert: </a> however the RIPE NCC will make clear on its response that it has no mandate to interfere with the internal abuse handling procedures of resource holders and it will only archive the report. insert: </p>

insert: <h3>

Current Validation method insert: </h3>

insert: <p>

The RIPE NCC has already a process to proactively validate “abuse-mailbox:” attributes on a yearly basis, based on the accepted policy proposal 2017-02, “Regular abuse-c Validation”. insert: </p>

insert: <p>

The current validation process starts with a verification tool which checks that there are no formatting errors in the email address, verifies DNS entries, looks for bogus or honeypot emails, and uses ping to check that the mailbox exists and can accept mail. This tool does not send any emails and won’t require any action on the part of the abuse contact. 92.5% of the abuse mailbox addresses passed this automated validated check. insert: </p>

insert: <p>

After running the tool, email addresses that failed the test are marked as invalid, we send a validation link in an html email in order to avoid phishing, etc. Even if only to these addresses and tickets are created in our system. There were about 6000 tickets created during the implementation of the proposal 2017-02 in 2019. insert: </p>

insert: <p>

A separate ticket is created for each LIR organisation abuse mailbox (~3,900 tickets in 2019). insert: </p>

insert: <p>

LIR resource abuse mailboxes are grouped per corresponding LIR. The LIR needs to make sure that the abuse mailbox is validated (~600 tickets in 2019). insert: </p>

insert: <p>

End User abuse mailboxes are grouped per sponsoring LIR. The sponsoring LIR needs to make sure that the abuse mailbox is validated (~1,500 tickets in 2019). insert: </p>

insert: <p>

If the validation link on the ticket is clicked or the abuse-mailbox attribute is updated and the verification tool recognises it as valid within three weeks, the ticket is closed without any manual input needed from the RIPE NCC. insert: </p>

insert: <p>

In about 30% of the cases, manual intervention is required from the RIPE NCC to follow up with the LIRs.  insert: </p>

insert: <p>

A more detailed report on the current validation method is available on insert: <a href="https://labs.ripe.net/Members/angela_dallara/how-we-will-be-following-up-with-invalid-abuse-contacts"> this is not RIPE Labs article insert: </a> . insert: </p>

insert: <h3>

New Validation method insert: </h3>

insert: <p>

If this policy change is accepted, the RIPE NCC can no longer use the verification tool as part of the policy text, it is strongly suggested that the RIPE NCC consider it, validation process as this is advice that process does not send emails thus it cannot ensure that emails are received. insert: </p>

insert: <p>

The rest of the validation process will remain as it currently stands. The only difference will be that the RIPE NCC will send validation links to each abuse-mailbox in the RIPE database. Previously, it was only sent to addresses deemed invalid. insert: </p>

insert: <p>

The RIPE NCC expects that each validation round will need the creation of more than 32,000 tickets according to the categories below: insert: </p>

insert: <ol>
    insert: <li>
  1. Tickets created for LIRs (abuse-c listed in their organisation object/one ticket per LIR): insert: <ol style="list-style-type: lower-alpha;">
      insert: <li>
    1. Number of unique LIRs: ~25,000 insert: </li>
    2. insert: <li>
    3. Number of unique abuse mailboxes in LIR organisation object: ~21,700 insert: </li>
    4. insert: </ol>
    insert: </li>
  2. insert: <li>
  3. Tickets created for LIRs (abuse-c listed in their resources/1 ticket per unique LIR) insert: <ol style="list-style-type: lower-alpha;">
      insert: <li>
    1. Number of unique LIRs with at least one resource with an abuse-c: ~4,500 insert: </li>
    2. insert: <li>
    3. Number of unique abuse mailboxes listed in LIR resources: ~56,700 insert: </li>
    4. insert: </ol>
    insert: </li>
  4. insert: <li>
  5. Tickets created for LIRs acting as sponsoring LIR (1 ticket per unique sponsoring LIR) insert: <ol style="list-style-type: lower-alpha;">
      insert: <li>
    1. Number of unique LIRs, sponsoring at least one End User: ~2,800 insert: </li>
    2. insert: <li>
    3. Number of unique abuse mailboxes listed in End User resources who have an agreement with a sponsoring LIR: ~16,300 insert: </li>
    4. insert: </ol>
    insert: </li>
  6. insert: </ol>
insert: <h3>

Impact on Members insert: </h3>

insert: <p>

If this policy change is accepted there will be an increased workload for RIPE NCC members who are sponsoring End Users or have an abuse-c contact listed in their resources. We will rely on these LIRs to validate more than 70,000 abuse mailboxes. The RIPE NCC will send the validation links to all abuse mailboxes. However, it will open tickets only with the corresponding members. These members will need to follow up with their End Users/customers to make sure that they validate the abuse mailbox. insert: </p>

insert: <h2>

B. Impact of Policy on Registry and Addressing System insert: </h2>

insert: <p>

If this proposed policy change reaches consensus, an improvement of the registry data is expected as more “abuse-mailbox:” attributes will be current and correct. insert: </p>

insert: <p>

The proposal does not have an impact on fragmentation and the routing system. insert: </p>

insert: <h2>

C. Impact of Policy on RIPE NCC Operations/Services insert: </h2>

insert: <p>

The RIPE Database contains around 93,000 distinct abuse-mailbox attributes. The RIPE NCC expects that each validation round will need the creation of more than 32,000 tickets or 64,000 tickets per given year (in 2019 we opened around 6,000 tickets). insert: </p>

insert: <p>

While the process will be automated as much as possible, a considerable number of these tickets (around 30% according to 2019’s figures) will need to be checked manually (~19,200 tickets per year). insert: </p>

insert: <p>

The estimated workload would exceed the current capacity of Registration Services. A significant increase in FTEs (employee on a full-time basis) would be required to handle this regular workload (10 times the current level). In comparison, three additional temporary FTEs were needed in 2019 to handle the manual workload generated by the initial validation of the current policy. insert: </p>

insert: <p>

This amount of workload will continue until the RIPE NCC decides that the level of accuracy of the abuse mailbox attribute in the RIPE database has improved and the frequency of validation sessions can decrease. At this point, the RIPE NCC cannot reliably estimate when this may happen. insert: </p>

insert: <p>

A slight increase of workload is expected from reports of abuse mailboxes forcing members to use a form. insert: </p>

insert: <p>

The  insert: <a href="../../../../../resolveuid/244b4130-d14c-41b4-ad28-820749df0fc4" data-linktype="internal" data-val="244b4130-d14c-41b4-ad28-820749df0fc4"> ARC insert: </a>  process can play a supporting role, especially if there are indications that the incorrect “abuse-mailbox:” attributes are part of a bigger issue of incorrect contact information for an LIR. In such situations, an ARC can be scheduled immediately. However, full coverage via the ARC process is not possible due to the differing scope and frequency of the processes. This policy change would require the validation every six months of all abuse contact email addresses (for allocated and independent resources), while the ARC process aims to verify the registration details of LIRs only. insert: </p>

insert: <h2>

D. Legal Impact insert: </h2>

insert: <p>

If the policy proposal reaches consensus, it will impose the following two criteria for a valid “abuse-mailbox:” attribute: it must receive messages and it must not force the sender to use a form. During the validation process the RIPE NCC will only check that the attribute is present and can receive messages. Cases of “abuse-mailbox:” attribute that forces the sender to use a form, if brought to the RIPE NCC’s attention, will also constitute policy violation and RIPE NCC will follow up as per relevant RIPE Policies and RIPE NCC procedures, such as “Closure of Members, De-registration of Internet Resources and Legacy Internet Resources” procedural document. insert: </p>

insert: <p>

If this policy proposal reaches consensus, the RIPE NCC will make sure that all email validation checks are performed in accordance with the EU data protection legislation. insert: </p>

insert: <p>

The RIPE NCC may also need to update relevant procedural documents, including the RIPE NCC procedural document “Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources”. insert: </p>

insert: <h2>

E. Implementation insert: </h2>

insert: <p>

With the information currently available, it is expected that implementation of the proposal would have a medium impact (about three months) in terms of the software development needed to facilitate the policy change. All current “abuse-mailbox:” attributes will be validated in batches. insert: </p>

insert: <p>

The start of the implementation of this proposal requires a significant increase in FTE’s which would need to be included in the RIPE NCC Draft Activity Plan and Budget. This document is published in September and reviewed by the RIPE NCC membership during the autumn General Meeting. The PDP cycle of this proposal is expected to finish after the upcoming publication. This might considerably delay the start of the implementation. insert: </p>

insert: <p>

The implementation will be considered completed after every “abuse-mailbox:” attribute 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, validated 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 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> time. insert: </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

1.0 Abuse Contact Information insert: <br />
insert: <a href="#2-0-attribution" data-linktype="anchor" data-val="1"> insert: <strong> 2.0 Attribution insert: </strong> insert: </a> insert: </p>

insert: <p>

  insert: </p>

insert: <h3>

insert: <a name="1-0-abuse-contact-information"> insert: </a> 1.0 Abuse Contact Information insert: </h3>

insert: <p>

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. insert: </p>

insert: <p>

The “abuse-c:” will be mandatory for all  insert: <strong> aut-num insert: </strong> s.

insert: <td>insert: </tr>insert: </tbody>insert: </table>
delete: <a href="#2-0-attribution" data-linktype="anchor" data-val="1"> delete: <strong> 2.0 Attribution delete: </strong> delete: </a> delete: </td> delete: <td> delete: <p> delete: <strong> delete: <a href="#2-0-about-the--abuse-mailbox-" data-linktype="anchor" data-val="6"> delete: <span class="newdifftext"> 2.0 About the "abuse-mailbox" delete: <br /> delete: </span> delete: </a> delete: <a href="#3-0-objectives-of--abuse-mailbox--validation" data-linktype="anchor" data-val="7"> delete: <span class="newdifftext"> 3.0 Objectives of "abuse-mailbox" validation delete: <br /> delete: </span> delete: </a> delete: <a href="#4-0-validation-of--abuse-mailbox-" data-linktype="anchor" data-val="8"> delete: <span class="newdifftext"> 4.0 Validation of “abuse-mailbox" delete: <br /> delete: </span> delete: </a> delete: <a href="#5-0-escalation-to-the-ripe-ncc" data-linktype="anchor" data-val="9"> delete: <span class="newdifftext"> 5.0 Escalation to the RIPE NCC delete: <br /> delete: </span> delete: </a> delete: <a href="#6-0-attribution" data-linktype="anchor" data-val="6"> delete: <span class="newdifftext"> 6.0 Attribution delete: </span> delete: </a> delete: </strong> delete: </p> delete: </td> delete: </tr> delete: </tbody> delete: </table> delete: <p>   delete: </p> delete: <h3> delete: <a name="1-0-abuse-contact-information"> delete: </a> 1.0 Abuse Contact Information delete: </h3> delete: <p> 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. delete: </p> delete: <p> The “abuse-c:” will be mandatory for all  delete: <strong> aut-num delete: </strong> s. delete: </p>

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.

insert: </td>
insert: <p>

Due the hierarchical nature of IP address objects, at least every direct allocated insert: <strong> inetnum insert: </strong> and insert: <strong> inet6num insert: </strong> needs to have an “abuse-c:”. Inherited objects might have their own “abuse-c:” attribute or they will be covered by the higher insert: <em> - insert: </em> level objects. insert: </p>

insert: <p>

The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute insert: <em> , insert: </em> which insert: <span class="newdifftext"> must receive messages, either for insert: </span> automatic  insert: <span class="newdifftext"> (e.g. X-ARF/RFC5965/RFC6650) or insert: </span> manual reports about abusive behavio insert: <em> u insert: </em> r originating in the resource holders’ networks insert: <span class="newdifftext"> and must not force the sender to use a form insert: </span> . insert: </p>

insert: </td>

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

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: <h3> delete: <a name="2-0-attribution"> delete: </a> 2.0 Attribution delete: </h3>

The RIPE NCC will validate insert: <span class="newdifftext"> if insert: </span> the “abuse-mailbox:” attribute insert: <span class="newdifftext"> is present and can receive messages insert: </span> at least delete: <em> every six months, as per the procedure stated in this policy delete: </span> . delete: </em> Where the attribute is deemed incorrect, it months*. If the validation fails, the RIPE NCC insert: </span> will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures. insert: </p>

insert: <p>

insert: <span class="newdifftext"> This validation process will not check how the abuse cases are processed. The community should escalate/report back to the RIPE NCC, so anonymised statistics can be collected and periodically published. insert: </span>

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

delete: <h3> delete: <a name="2-0-about-the--abuse-mailbox-"> delete: </a> delete: <span class="newdifftext"> 2.0 About the "abuse-mailbox" delete: </span> delete: </h3> delete: <p> delete: <span class="newdifftext"> Emails sent to "abuse-mailbox" require manual intervention by the recipient at some point, and insert: <p>

insert: <span class="newdifftext"> *The RIPE NCC 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: </span> delete: </p> delete: <p> delete: <span class="newdifftext"> 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). delete: </span> delete: </p> delete: <p> delete: <span class="newdifftext"> 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: </span> delete: </p> delete: <p> delete: <span class="newdifftext">   delete: </span> delete: </p> delete: <h3> delete: <a name="3-0-objectives-of--abuse-mailbox--validation"> delete: </a> delete: <span class="newdifftext"> 3.0 Objectives of "abuse-mailbox" validation delete: </span> delete: </h3> delete: <p> delete: <span class="newdifftext"> The procedure, which will be developed by the RIPE NCC, must meet the following objectives: delete: </span> delete: </p> delete: <ol> delete: <li> delete: <span class="newdifftext"> A simple process that guarantees 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: </span> delete: <br /> delete: <br /> delete: </li> delete: <li> delete: <span class="newdifftext"> Avoid exclusively automated processing. delete: </span> delete: <br /> delete: <br /> delete: </li> delete: <li> delete: <span class="newdifftext"> 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. delete: </span> delete: <br /> delete: <br /> delete: </li> delete: <li> delete: <span class="newdifftext"> Validation period of no longer than 15 days. delete: </span> delete: <br /> delete: <br /> delete: </li> delete: <li> delete: <span class="newdifftext"> If validation fails, escalate to the LIR and set a new change the validation period not to exceed 15 days. delete: </span> delete: </li> delete: </ol> delete: <p> delete: <span class="newdifftext"> The “initial” and “escalation” validation periods may be modified by the RIPE NCC, if deemed appropriate, informing the community about the motivation. depending on the level of accuracy of the contacts. For example, it could be longer for the first validation, switching from six-month to one-year period 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. delete: </span> delete: </p> delete: <p> delete: <span class="newdifftext">   delete: </span> delete: </p> delete: <h3> delete: <a name="4-0-validation-of--abuse-mailbox-"> delete: </a> delete: <span class="newdifftext"> 4.0 Validation of "abuse-mailbox" delete: </span> delete: </h3> delete: <p> delete: <span class="newdifftext"> 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. delete: </span> delete: </p> delete: <p> delete: <span class="newdifftext"> Lack of compliance will lead to a more exhaustive follow-up, in accordance with the relevant RIPE NCC policies, procedures or contractual requirements. delete: </span> delete: </p> delete: <p> delete: <span class="newdifftext"> 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. delete: </span> delete: </p> delete: <p> delete: <span class="newdifftext">   delete: </span> delete: </p> delete: <h3> delete: <a name="5-0-escalation-to-the-ripe-ncc"> delete: </a> delete: <span class="newdifftext"> 5.0 Escalation to the RIPE NCC delete: </span> delete: </h3> delete: <p> delete: <span class="newdifftext"> 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. delete: </span> delete: </p> delete: <p>   delete: </p> delete: <h3> delete: <a name="6-0-attribution"> delete: </a> delete: <span class="newdifftext"> 6.0 Attribution delete: </span> delete: </h3> contact accuracy has improved. insert: </span> insert: </p>

insert: <p>

  insert: </p>

insert: <h3>

insert: <a name="2-0-attribution"> insert: </a> 2.0 Attribution insert: </h3>

This document is developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Tobias Knecht

 

Get Involved

The Anti-Abuse Working Group is open to anyone with an interest in combating network abuse. Areas such as cybersquatting and hosting illegal content are beyond the scope of the WG. The WG advises relevant parties such as Internet service providers (ISPs), governments and law enforcement agencies on both technical and non-technical methods of tackling abuse. This mailing list was previously the “anti-spam-wg”, the archives of which are still publicly available on the RIPE NCC website. To post a message to the list, send an email to anti-abuse-wg@ripe.net. Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.