| Authors | |
|---|---|
Name: Jordi Palet Martinez Email: jordi.palet@consulintel.es Organization: The IPv6 Company |
Name: Jordi Palet Martinez Email: jordi.palet@theipv6company.com Organization: The IPv6 Company |
| Summary | |
The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific fo rmat, 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 registere d for their resources. There are even cases of LIRs/ISPs, end users or others that use a non-existent mailbox or one tha t 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 util ization. |
This proposal allows ensuring and validating an organization's WHOIS abuse contacts (abuse-c and abuse-mailbox) and ther efore reporting and solving cases of abuse. It aims to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization. |
| Rationale (Describe the problem you intend to solve) | |
The Internet community is based on collaboration. In many cases, however, this is not enough and we need to be able to c ontact those LIRs or other recipients of LACNIC resources that may be experiencing a problem in their networks but may n ot 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 verificati on, 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 fr om 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 attrib ute 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 fo rmat, 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 and this generates security issu es and costs for the victims. To solve this problem, a simple, periodic verification of abuse contacts is proposed that will avoid unnecessary costs t o third parties. The proposal guarantees that the cost of processing the abuses 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 compe nsation 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 i n the “inetnum” objects (for both IPv4 and IPv6), as well as in any others that may be used in the future. This attribut e is an abuse contact, which must contain at least the “abuse-mailbox” attribute. |
| Current text | |
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” an d located at the end of the Manual. The entire Policy Manual would be updated to reflect this change of numbering. As th e Manual “grows,” any new section added would not require any renumbering. Therefore, the text of this proposal would be come 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 correspo nding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for rece iving 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 inc lude 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 classificati on procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply t hat each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a s pecific interface for each case, which is neither feasible or logical, as it would place the cost of processing abuses o n those who submit the claims and are therefore their victims, instead of being paid by the those whose client causes th e 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 sta rt, 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 em ail 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 exampl e, 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 verif y that validation requests actually come from LACNIC and not from third parties (which might involve security risks), av oiding, 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 mo nitor 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 p eriod not to exceed fifteen (15) days. LACNIC may modify the “initial” and “escalated” validation periods if it sees fit, informing the community of the reason s for doing so. For instance, these periods might be shortened once the initial validation of a high percentage of conta cts has been completed, in which case the quality of the contacts would increase and response times in case of abuse wou ld 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 crea ted 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 perf orm said validations more effectively. Should an organization fail to comply, this will initially result in the blocking of “milacnic” for all the resources as sociated 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-complia nce continues, will act in accordance with the relevant policies and procedures in force, especially “7.1. Resource reco very.” 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 resp onse to case of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocat ed by LACNIC, a mailbox will be available (for example, “escalado-abusos@lacnic.net”) to escalate such situations, thus allowing LACNIC to trigger re-validation according to section 12.4 above or even intermediation by LACNIC and, where app ropriate, the application of the relevant policies/procedures, especially “7.1. Resource recovery.” |
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 includ es 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 classifica tion 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 s pecific interface for each resource recipient to which it must report an abuse. This would not be viable, as it would pl ace 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 o f the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it i s reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information ha s 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 f or both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number wil l be maintained in all communications (typically as part of the subject). 12.3. Purpose of “abuse-c”/”abuse-mailbox” validation The procedure, which is to be developed by LACNIC, 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 valid ation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a sin gle “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 addition al 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. 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 ar e 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 occurs if it has not been validated during the “initial” or the “additional” valida tion periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all th e resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as wil l 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 it remains blocked will display a warning m essage including the text of this policy. Before the system allows the person to continue, this message must be “read” i n full and confirmed by selecting a check-box or other similar mechanism. As technology evolves, other equivalent mechan isms may be used. 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, to a specific subject or t o a certain message body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managi ng cases of abuse) may be reported to LACNIC for re-validation according to 12.4. |
| New text | |
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” an d located at the end of the Manual. The entire Policy Manual would be updated to reflect this change of numbering. As th e Manual “grows,” any new section added would not require any renumbering. Therefore, the text of this proposal would be come 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 correspo nding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for rece iving 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 inc lude 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 classificati on procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply t hat each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a s pecific interface for each case, which is neither feasible or logical, as it would place the cost of processing abuses o n those who submit the claims and are therefore their victims, instead of being paid by the those whose client causes th e 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 sta rt, 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 em ail 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 exampl e, 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 verif y that validation requests actually come from LACNIC and not from third parties (which might involve security risks), av oiding, 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 mo nitor 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 p eriod not to exceed fifteen (15) days. LACNIC may modify the “initial” and “escalated” validation periods if it sees fit, informing the community of the reason s for doing so. For instance, these periods might be shortened once the initial validation of a high percentage of conta cts has been completed, in which case the quality of the contacts would increase and response times in case of abuse wou ld 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 crea ted 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 perf orm said validations more effectively. Should an organization fail to comply, this will initially result in the blocking of “milacnic” for all the resources as sociated 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-complia nce continues, will act in accordance with the relevant policies and procedures in force, especially “7.1. Resource reco very.” 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 resp onse to case of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocat ed by LACNIC, a mailbox will be available (for example, “escalado-abusos@lacnic.net”) to escalate such situations, thus allowing LACNIC to trigger re-validation according to section 12.4 above or even intermediation by LACNIC and, where app ropriate, the application of the relevant policies/procedures, especially “7.1. Resource recovery.” |
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 includ es 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 classifica tion 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 s pecific interface for each resource recipient to which it must report an abuse. This would not be viable, as it would pl ace 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 o f the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it i s reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information ha s 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 f or both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number wil l be maintained in all communications (typically as part of the subject). 12.3. Purpose of “abuse-c”/”abuse-mailbox” validation The procedure, which is to be developed by LACNIC, 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 valid ation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a sin gle “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 addition al 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. 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 ar e 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 occurs if it has not been validated during the “initial” or the “additional” valida tion periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all th e resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as wil l 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 it remains blocked will display a warning m essage including the text of this policy. Before the system allows the person to continue, this message must be “read” i n full and confirmed by selecting a check-box or other similar mechanism. As technology evolves, other equivalent mechan isms may be used. 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, to a specific subject or t o a certain message body) or failure to comply with the remaining aspects of this policy (ignoring or incorrectly managi ng cases of abuse) may be reported to LACNIC for re-validation according to 12.4. |
| 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 (“validacion.lacnic.net”) and may con tain 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 an d 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 b e marked as “valid”; otherwise it will be considered in breach of the policy. |
Note (not to be included in the Policy Manual): Current Section “12. Appendixes” would now be Section “A. Appendixes” an d located at the end of the Policy Manual and the entire Manual would be updated to reflect this change of numbering. Th en, as the Manual continues to “grow,” any new section added would not require any renumbering. The text of this proposa l 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, avoid s clicking on an html link sent via email to prevent phishing or other malicious actions. While this text is not part of the text of the policy, we recommend its consideration, as is the result of the discussions on abuse-c policies that ha ve taken place within 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 un der 12.6), LACNIC may use domains other than lacnic.* and even modify the subject and body of the message in order to in crease 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 contai n 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 e mail in the corresponding 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 a lert 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 m arked 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. |
| References | |
A similar proposal is under discussion in the RIPE region, though at the date on which this proposal was submitted it ha d not yet reached consensus. It is a much simpler version, and a new version equivalent to this proposal has been presen ted. In APNIC, a version equivalent to this proposal has reached consensus. In AfriNIC the same proposal has been presen ted. |
In APNIC, a version equivalent to this proposal has reached consensus. In the RIPE region, a similar proposal was adopted, except that it only considers an automatic verification. Recent deba tes on the mailing list have shown the need for this verification to be “more than merely automatic,” as the current pro cedure allows for multiple forms of deception. In addition, an equivalent proposal is being processed and will be published shortly. Equivalent proposals have been submitted in AfriNIC and ARIN. |