Name: Jordi Palet Martinez
Email: jordi.palet@theipv6company.com
Organization: The IPv6 Company

Name: Jordi Palet Martinez
Email: jordi.palet@theipv6company.com
Organization: The IPv6 Company

This proposal allows ensuring and validating an organization's WHOIS abuse contacts (abuse-c and abuse-mailbox) and thus reporting and solving cases of abuse.

It seeks to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization.

This proposal allows ensuring and validating an organization's WHOIS abuse contacts (abuse-c and abuse-mailbox) and thus reporting and solving cases of abuse.

It seeks to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization.

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 on record for their resources, and there are even cases of LIRs/ISPs, end users or others that use a non-existent email address or one that is not actively monitored.

Because these contacts are not validated, cases of abuse cannot be effectively reported. This creates security issues and costs for the victims.

To solve this problem, a simple, periodic verification of abuse contacts is proposed that will avoid unnecessary costs to third parties.

The proposal guarantees that the cost of processing an abuse falls on the recipient of the resource who is responsible for the abuse, either directly or indirectly (through a customer, from whom they are possibly receiving financial compensation for the service), instead of falling on the victim. Bear in mind that this will keep the problem from escalating and will save time and legal costs for both parties involved if the matter is taken to court.

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.

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 on record for their resources, and there are even cases of LIRs/ISPs, end users or others that use a non-existent email address or one that is not actively monitored.

Because these contacts are not validated, cases of abuse cannot be effectively reported. This creates security issues and costs for the victims.

To solve this problem, a simple, periodic verification of abuse contacts is proposed that will avoid unnecessary costs to third parties.

The proposal guarantees that the cost of processing an abuse falls on the recipient of the resource who is responsible for the abuse, either directly or indirectly (through a customer, from whom they are possibly receiving financial compensation for the service), instead of falling on the victim. Bear in mind that this will keep the problem from escalating and will save time and legal costs for both parties involved if the matter is taken to court.

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:

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

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

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

12.2. About the “abuse-mailbox”

Email messages sent to the “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. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “abuse-mailbox” may initially return 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 mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports. This would not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy of the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it is reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

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

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

1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automated process should be avoided.
3) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
4) An “Initial” validation period of fifteen (15) days.
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

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

12.4. Validation of “abuse-c”/“abuse-mailbox”

LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while the system remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a checkbox or other similar mechanism. As technology evolves, other equivalent mechanisms may be adopted.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.6. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managing cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Current text:

N/A

New text:

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

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

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

12.2. About the “abuse-mailbox”

Email messages sent to tThe “abuse-mailbox”: m
• 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. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “ab• Muse-mailbox” may initially return 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 mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports. This wo
• Muld not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy lof the spam message or its full, headers, or equivxalent information as applicable for each type of abuse). Likewise, it is reasonabletc. for the initial auto-reply emailng to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

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

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

1) ItA simuple process that guarantees its functionality and allow the hefulpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automateds purpocess should be avoided.
32) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
43) AInclude an “Initial” validation period of fifteen (15) days.
54) If this validation fails, “escalate”, toby theany porigssinable rmecipieans, t of the resourcest (LIR,of thend usavailabler, econtac.)ts forwithin an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

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

12.4. Validation of “abuse-c”/“abuse-mailbox”

LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while the system remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a checkbox or other similar mechanism. As technology evolves, other equivalent mechanisms may be adopted.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.65. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or incmproperrectly mattenagtiong to cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Current text: N/A

New text:

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

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

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

12.2. About the “abuse-mailbox”

Email messages sent to the “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. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “abuse-mailbox” may initially return 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 mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports. This would not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy of the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it is reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

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

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

1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automated process should be avoided.
3) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
4) An “Initial” validation period of fifteen (15) days.
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

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

12.4. Validation of “abuse-c”/“abuse-mailbox”

LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while the system remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a checkbox or other similar mechanism. As technology evolves, other equivalent mechanisms may be adopted.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.6. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managing cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Current text:

N/A

New text:

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

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

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

12.2. About the “abuse-mailbox”

Email messages sent to tThe “abuse-mailbox”: m
• 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. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “ab• Muse-mailbox” may initially return 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 mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports. This wo
• Muld not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy lof the spam message or its full, headers, or equivxalent information as applicable for each type of abuse). Likewise, it is reasonabletc. for the initial auto-reply emailng to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

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

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

1) ItA simuple process that guarantees its functionality and allow the hefulpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automateds purpocess should be avoided.
32) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
43) AInclude an “Initial” validation period of fifteen (15) days.
54) If this validation fails, “escalate”, toby theany porigssinable rmecipieans, t of the resourcest (LIR,of thend usavailabler, econtac.)ts forwithin an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

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

12.4. Validation of “abuse-c”/“abuse-mailbox”

LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while the system remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a checkbox or other similar mechanism. As technology evolves, other equivalent mechanisms may be adopted.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.65. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or incmproperrectly mattenagtiong to cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Note (not to be included in the Policy Manual):
Current Section “12. Appendixes” would become Section “A. Appendixes” and be located at the end of the Policy Manual. In addition, the entire Manual would be updated to reflect this change of numbering. Then, as the Manual continues to grow, renumbering would not be necessary when a new section is added. The text of this proposal would therefore be included in the Policy Manual as Section 12 or any other number deemed appropriate by the staff at the time of its implementation, once consensus has been reached.

The following text is an example of a validation procedure based on typical helpdesk practices which, for example, does not require clicking on an html link sent via email to prevent phishing or other malicious actions. While this text is not part of the policy, we recommend its consideration, as it is the result of the discussions on abuse-c policies that have taken place among the global community.

1) LACNIC automatically initiates the validation by sending TWO consecutive emails to the “abuse-mailbox”.
2) These emails will contain plain text only (thus hiding any URLs intended as phishing or other types of attacks).
3) At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 12.6), LACNIC may use domains other than lacnic.* and even modify the subject and body of the message in order to increase the efficiency of said validations.
4) The first email will contain the URL where the validation is to be performed (“validacion.lacnic.net”) and may contain information about the procedure, a brief summary of this policy, etc.
5) The second email will contain a unique alphanumeric validation code.
6) The recipient responsible for the “abuse-mailbox” must go to the URL and paste the code they received in the second email in the form.
7) 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 appropriate 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.
8) The alphanumeric code will be valid for a maximum of 15 days.
9) If the code is not entered within this period, 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's recipient.
10) If no reply is received confirming that the situation has been corrected, after an additional period of 15 days, the “abuse-c” will be marked as permanently “invalid”.
11) 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.
12) LACNIC will have mechanisms in place (a form, an email address and possibly others in the future) to facilitate the escalation in cases where reporting a breach of this policy is desired. This will allow re-validation (12.4) and LACNIC's intervention in applying the policies, procedures and contractual requirements in force.

Note (not to be included in the Policy Manual):
Current Section “12. Appendixes” would become Section “A. Appendixes” and be located at the end of the Policy Manual. In addition, the entire Manual would be updated to reflect this change of numbering. Then, as the Manual continues to grow, renumbering would not be necessary when a new section is added. The text of this proposal would therefore be included in the Policy Manual as Section 12 or any other number deemed appropriate by the staff at the time of its implementation , once consensus has been reached.

TheLACNIC may fmollowdingfy thex “init isal” and “exscample of ated” validation procedure based ion typical helpdesk practices which, for example, does not require clicking on an html link sent via emails fito, preovidend t phishing orat other maliciommus actions. While thy is text is nfot partmed of the policy, we recasommend its cfonsideration, asuch it is tchanges. For esuxamplt ofe, the discussions on abuse-c policieriods tmighat havbe extaken placded amoduring the global commuinity.

1) LACNIC automatically implemenitiates the validation by phase anding TWOthen cpronsgrecutssive emails to they “abdjuse-mailbox”.
2) Thested emails will contain plahin tghextr ponly (rthus hidiong anyof URLs icontended acts phishing or othver typifiesd. of attacks).
3) At
Similarly, the discfretioquency of LACNIC, in gtheneral or in specrifodic casves (for example, for conifirmcation in cmasy bes modif iescalation under 12.6),by LACNIC mayif uit sees domafins other, than lacnic.* andso evein formodifyng the subject and bodmmunity of the mressage isons for der to increase the efficiencyg sof. saidFor vexamplidae, tions.
4) The first yemail willr conta sin the URL where thgle validation mis ghto be pecarformied (“validacion.lacnic.neut”) andto mfay contain linformation about the comproliancedure, a brwief summary ofth thise policy, etc.
5) The secoand email will contaihen a unique alphanumberic of validation code.
6)s Tmighe recipient responsible fprogr the “abuse-masivelbox” must go to the URLy aind pcreaste the code, thpey received in the apse cond email ucting the form.
7) This URL mqusart be designed in such a warly, thato it mpreovents the quseality of an automathed process (for exntample, “captcha”)s. In

The additifon, it must cllontawin ag text that confirms thatn the xamplerson performingf thea validation understands the procedure bansed the policy, thatn they regularly monpitor the “cabuse-mailbox”, that appropriate measures are taken to solve reported cases of abuse, and that the abusek reporact reiceives a response, with a cheickbox that must, be accepted in forder to proceed.
8) The xalmphanumeric code will be, valid for a maximum of 15 days.
9) If the code is not entrequired wclithckin thisg period, the system willn markn the “abuse-c” as “temporarily invalid” and will alert LACNICk staff so that they can init viate a personmalized follow-up with the resource's precipivent.
10) If no reply his recehivedng confirming that other smalicitous action has. beWhilen corrected,his afterxt an additios nalot peariodt of 15 days, the “abuse-polic”y, will be marked as percomanmently “invalid”.
11) The validations prcocesns will bde repeated automaticallyon, (itemas 1 ito 7 above). If satisfactory, the “abuse-c” will be marked as “vaulid”;t of therwise, it wdill be scussionsidered ion abrusea-ch of the policy.
12) LACNICies willthat have mechtanisms iken place (a form, an email address and possibly others ing the future) tglo fbacilitate the escalatiommun inty. cas
(Sees wheprevious rveportsiong a breach of thise proposalicy, isthe desifored.m This wilonly allows re-va lidatmion (12.4) anted LACNIC's intumbervention in applying the policies,f procedures hand contractual requirements in force.)

-

-