Registration and validation of "abuse-c" and "abuse-mailbox"

Original Language Español Date Published 05/03/2018 Last Modified 16/10/2018
Last Call for Comments Period Does not apply Date Ratified Does not apply Implementation Date Does not apply
Status Under discussion Download TXT PDF XML DOCX
See other versions 1.0 2.0 3.0 (compare)


Name: Jordi Palet Martinez
Organization: The IPv6 Company

Proposal Data

Policy Type: LACNIC
Id: LAC-2018-5
Last version: 3


The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific format, nor as to whether this applies to other whois records.

As a result, some organizations that have received resources from LACNIC may not have this contact information registered for their resources. There are even cases of LIRs/ISPs, end users or others 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 by ensuring the existence of a proper abuse-c contact and a process for its utilization.


The Internet community is based on collaboration. In many cases, however, this is not enough and we need to be able to contact those LIRs or other recipients of LACNIC resources that may be experiencing a problem in their networks but 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.

In this case, the abuse-c attribute – which has so far only been referenced for the “aut-num” object – becomes mandatory in the “inetnum” objects (for both IPv4 and IPv6), 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.


Current text: N/A

New text:

Note (not to be included in the Policy Manual): Current Section “12. Appendixes” would now be Section “A. Appendixes” and located at the end of the Manual. The entire Policy Manual would be updated to reflect this change of numbering. As the Manual “grows,” any new section added would not require any renumbering. Therefore, the text of this proposal would become Section 12.

12. Registration and validation of “abuse-c” and “abuse-mailbox”.

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources allocated by LACNIC 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 LACNIC 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.

12.2. 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 abuse reports, e.g. in case of spam, where the message 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 or logical, as it would place the cost of processing abuses on those who submit the claims and are therefore their victims, instead of being paid by the 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, sending in that first report 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 other reporting services, keeping costs at a minimum for both parties involved.

12.3. Objectives of “abuse-c”/”abuse-mailbox” validation

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

1) A simple process that guarantees its functionality and allows the helpdesks that deals with abuse reports to verify that validation requests actually come from LACNIC and not from third parties (which might involve security risks), avoiding, for example, a single “direct” URL for validation.
2) Avoid 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) “Initial” validation period not to exceed fifteen (15) days.
5) If validation fails, “escalate” to the recipient of the resources (LIR, end user, etc.) and set a new validation period not to exceed fifteen (15) days.

LACNIC may modify the “initial” and “escalated” validation periods if it sees fit, informing the community of the reasons for doing so. For instance, these periods might be shortened once the initial validation of a high percentage of contacts has been completed, in which case the quality of the contacts would increase and response times in case of abuse would decrease.

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

12.4. Validation of “abuse-c”/”abuse-mailbox”
LACNIC 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 twice a year and whenever LACNIC sees fit.

This validation frequency may be modified by LACNIC if it sees fit, informing the community of the reasons for doing so. For instance, a single validation might be carried out during the first year to make it easier to adapt to the policy, after which the number of annual validations might gradually increase, perhaps even to a quarterly or monthly frequency, to increase the quality of the contact information.

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

Should an organization fail to comply, this will initially result in the blocking of “milacnic” for all the resources associated with said organization, except for the purpose of updating the abuse-c/abuse-mailbox contacts, so that they can be re-validated to allow the unblocking of “milacnic”.

LACNIC will perform a more exhaustive follow-up and, if the following automatic validation confirms that the non-compliance continues, will act in accordance with the relevant policies and procedures in force, especially “7.1. Resource recovery.”

12.5. Escalation to LACNIC

To avoid fraudulent behavior (for example, an “abuse-mailbox” that only replies to LACNIC'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 case of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocated by LACNIC, a mailbox will be available (for example, “”) to escalate such situations, thus allowing LACNIC to trigger re-validation according to section 12.4 above or even intermediation by LACNIC and, where appropriate, the application of the relevant policies/procedures, especially “7.1. Resource recovery.”

Additional Information

Example of the validation procedure.
1) LACNIC automatically initiates the validation, sending TWO consecutive emails to the “abuse-mailbox”.
2) These emails will contain plain text only.
3) 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.
4) The second email will contain a unique alphanumeric validation code.
5) The person in charge of the “abuse-mailbox” must go to the URL and enter the code received in the second email in the form.
6) 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.
7) The alphanumeric code will be valid for a maximum of two (2) working days.
8) If the code is not entered within this time frame, the system will mark the “abuse-c” as “temporarily invalid” and will alert LACNIC staff so that they can initiate a personalized follow-up with the resource recipient.
9) If no reply is received confirming that the situation has been corrected, after an additional period of three (3) working days, the “abuse-c” will be permanently marked as “invalid”.
10) 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.


Ninety (90) days, to be confirmed by LACNIC, to allow both the staff to develop the tool and the LIRs to update their abuse-c contacts.


A similar proposal is under discussion in the RIPE region, though at the date on which this proposal was submitted it had not yet reached consensus. It is a much simpler version, and a new version equivalent to this proposal has been presented. In APNIC, a version equivalent to this proposal has reached consensus. In AfriNIC the same proposal has been presented.

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - version 2

LACNIC Staff's Interpretation of the Proposal
This proposal would apply to RIRs, requiring that they provide a valid abuse contact.

Modifications to the current text
According to the modifications presented in policy proposal 2018-4, the Policy Manual would be modified as specified below.

• Addition of the following sections:
o 12. Registration and validation of "abuse-c" and "abuse-mailbox"
o 12.1. Description of "abuse-c" and "abuse-mailbox"
o 12.2. "abuse-mailbox” characteristics
o 12.3. Purpose of validating "abuse-c"/"abuse-mailbox"
o 12.4. Validation of "abuse-c"/"abuse-mailbox"
o 12.5. Escalation to LACNIC

• Section 12. Appendixes would be renumbered as section 13. Appendixes.

LACNIC Staff Comments

• Sections 12.4 and 12.5 specify that “Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant LACNIC policies/procedures, especially 7.1. Resource recovery. However, it is not clear how LACNIC should proceed – whether policy 7.1 should be applied in every case.

• It should be noted that in order to implement this proposal LACNIC would need to invest new resources to handle those cases requiring follow-up. 

• This proposal makes reference to inetnum6 objects. LACNIC's whois only references inetnum objects, both for IPv4 and IPv6.

• LACNIC recommends not numbering the Appendix, but instead including it as A. (appendix). The purpose of this recommendation is to avoid having to update appendix numbers each time a section is added to the manual, as this could potentially result in errors due to the large number of references to the appendix (section 12) that appear throughout the text of the Policy Manual.

Impact of the policy on the registration system and address management
This proposal would involve developing a process to automatically monitor abuse-c and abuse-mailbox.

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - version 3

Interpretación de la propuesta por el staff de LACNIC

Esta propuesta se aplicaría a los receptores de recursos de LACNIC para que registren un contacto de abuso válido, tanto para ASNs, IPv4 e IPv6.

Modificación del texto actual
De acuerdo a las modificaciones presentadas en la propuesta 2018-5, el manual de políticas quedaría como se muestra a continuación en las siguientes secciones:

• Se agregan las secciones:

o 12. “Registro y Validación de "abuse-c" y "abuse-mailbox”
o 12.1 “Descripción del "abuse-c" y "abuse-mailbox”
o 12.2. “Características del "abuse-mailbox"
o 12.3. Objetivos de la validación del "abuse-c"/"abuse-mailbox
o 12.4. Validación del "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado a LACNIC

• La sección 12. Apéndices deja de tener numeración para poder incorporar nuevas secciones sin necesidad de renumerar los apéndices constantemente.

Comentarios del staff
• Cambios con respecto a la versión anterior la propuesta:
o Incorpora las recomendaciones del staff de LACNIC de las versiones anteriores sobre:
- usar el término inetnum tanto para IPv4 como para IPv6
- poner la sección de apéndices sin numeración
o Agrega que el procedimiento establecido por LACNIC debe impedir que el proceso de validación sea exclusivamente automatizado.
o Modifica que el plazo de validación inicial no debe ser superior a 15 días hábiles en lugar de 2.
o Indica que, si el contacto de abuso no se valida correctamente en la etapa inicial, se escala con el receptor del recurso en un plazo no superior a 15 días, en lugar de 3.
o Agrega que los plazos de validación “inicial” y “escalado” pueden ser modificados por LACNIC.
o Cambia la validación periódica que LACNIC debería hacer de una vez cada 3 meses a 2 veces al año. Además, permite que LACNIC modifique la frecuencia de validación si lo considera oportuno.
o Propone una alternativa para el caso de incumplimiento:
- Bloqueo inicial de milacnic para todos los recursos de la organización, excepto para la actualización de contactos abuse-c/abuse-mailbox
- Si se actualizan correctamente los contactos de abuso, serán revalidados para permitir el desbloqueo de milacnic.
- En el caso de que se siga incumpliendo se procedería a aplicar la sección 7.1. Recuperación de recursos.

• En la sección 12.4 y 12.5, cuando se indica “El incumplimiento, implicará un seguimiento más exhaustivo, de conformidad con las políticas/procedimientos pertinentes de LACNIC y especialmente "7.1. Recuperación de recursos", no especifica cómo deberá proceder LACNIC, si deberá aplicar la política 7.1 en todos los casos o no.

• Se observa que para la implementación de esta propuesta LACNIC necesitará invertir nuevos recursos para atender el seguimiento de todos los casos que lo necesiten.

• Se recomienda que la propuesta no defina plazos, sino que determine acciones y que los plazos necesarios se definan en base a razones operativas.

• Con respecto a la información adicional que menciona la propuesta, indica que “una propuesta similar sobre el contacto de abuso alcanzó consenso en RIPE NCC en junio del 2018”. (
La propuesta 2017-2 de RIPE NCC es más flexible: no indica plazos y la validación que implementará RIPE es más simple, revisará que exista un dominio y que haya un servidor de correo configurado únicamente.

Impacto en el sistema de registro
Esta propuesta implicará la creación de un proceso para el control automático del abuse-c y abuse-mailbox.

Privacy Policy