*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would like to share key feedback in our community for prop-125,based on a meeting we organised on 22nd Aug to discuss these proposals.Many supporting opinions were expressed on this proposal. - Agree, you should. - When mail address is posted in whois DB, a lot of SPAM is sent. We should take some measures.* Regards, Satoru Tusrumaki
2018-08-17 14:52 GMT+11:00 Sumon Ahmed Sabir <su...@fiberathome.net>: > Dear SIG members, > > The proposal "prop-125-v001: Validation of "abuse-mailbox" and other IRT > emails" has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 46 in > Noumea, New Caledonia on Thursday, 13 September 2018. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > Information about this proposal is available at: > > http://www.apnic.net/policy/proposals/prop-125 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt > > ---------------------------------------------------------------------- > > prop-125-v001: Validation of "abuse-mailbox" and other IRT emails > > ---------------------------------------------------------------------- > > Proposer: Jordi Palet Martínez - jordi.pa...@theipv6company.com > Aftab Siddiqui - aftab.siddi...@gmail.com > > > 1. Problem Statement > -------------------- > APNIC implemented mandatory IRT references on 8 November 2010. This means > it is mandatory to register an Incident Response Team (IRT) object for each > resource record in the APNIC Whois Database. The policy mandates IRT > references for each inetnum, inet6num and aut-num objects, however in many > cases, those contain out-of-date, inaccurate, non-existent or not actively > monitored abuse-mailbox information. > > 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 and ensure the existence of a > proper abuse-mailbox contact and the process for its utilization. > > 2. Objective of policy change > ----------------------------- > The Internet community is based on collaboration. In many cases, however, > this is not enough and we all need to be able to contact those LIRs which > may be experiencing a problem in their networks and may not be aware of the > situation. > > This proposal aims to solve this problem by means of a simple, periodic > verification of IRT object emails, 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. > > 3. Situation in other regions > ----------------------------- > A similar proposal is being discussed in LACNIC and being prepared for > AfriNIC and RIPE NCC. > > Currently, ARIN conducts an annual POC (point of contact) validation and > RIPE NCC validates the “abuse-mailbox:” attribute annually (ripe-705). > > 4. Proposed policy solution > --------------------------- > 1. About the "abuse-mailbox", “email”, “admin-c” and “tech-c” > > Emails sent to "abuse-mailbox", “email”, “admin-c” and “tech-c” 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 the abuse > reports, for example a case of spam, as it would include the spam message > itself or URLs or content usually classified as spam. > > The mailboxes 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 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 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 and in that first > report, sending 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 others, keeping > costs at a minimum for both parties involved. > > 2. Objectives of "abuse-mailbox", “email”, “admin-c” and “tech-c” > validation > > The procedure, which is to be developed by APNIC, must meet the following > objectives: > > 1) A simple process that guarantees its functionality and allows the > helpdesks that deal with abuse reports to verify that validation requests > actually come from APNIC 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 ensure that > understands the procedure and the policy, that they regularly monitor the > "abuse-mailbox", “email”, “admin-c” and “tech-c”, that measures are taken, > and that the abuse report receives a response. > > 4) Validation period no longer than fifteen (15) days. > > 5) If validation fails, escalate to the LIR and set a new validation > period not to exceed the fifteen (15) days. > > (By way of example, a detailed procedure is included in this policy > proposal under "Additional Information") > > > 3. Validation of "abuse-mailbox", “email”, “admin-c” and “tech-c” > > APNIC will validate compliance with the items above, both when the > "abuse-mailbox", “email”, “admin-c” and/or “tech-c” attributes are created > or updated, as well as periodically, not less than once every six months, > and whenever APNIC sees fit. > > At the discretion of APNIC, in general or in specific cases (for example, > for confirmation in cases of escalation under 4., APNIC may use domains > other than apnic.*, and even modify the subject and body of the message, in > order to perform said validations more effectively. > > Lack of compliance will imply a more exhaustive follow-up, in accordance > with the relevant APNIC policies, procedures and membership agreement and a > temporary lock of myapnic access, until resolved. > > 4. Escalation to APNIC > > To avoid fraudulent behavior (for example, an "abuse-mailbox" that only > replies to APNIC’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) and, therefore, to > guarantee the quality of the services in the region with the resources > allocated by APNIC, a mailbox will be available (for example, " > escalation-ab...@apnic.net"), to escalate such situations, thus allowing > for a re-validation (according to section 3. above) and even the > intermediation by APNIC and, where appropriate, the application of the > relevant policies/procedures, APNIC policies, procedures and membership > agreement. > > i) In case there is no response from all the email addresses associated > with the IRT object, then mark that IRT object invalid and block access to > myapnic and use other means to contact the member (e.g. via billing contact > or corporate contact) > > ii) if there is no response from some of the email address associated with > the IRT object, then mark those attributes invalid and contact the member > for the resolution. If the problem is not fixed after fifteen (15) days > then block access to myapnic and use other means to contact the member > (e.g. via billing contact or corporate contact). > > 5. Advantages / Disadvantages > ----------------------------- > > Advantages: > The purpose of creating IRT object in the APNIC whois database is to > provide a more accurate and efficient way for abuse reports to reach the > correct network contact. Fulfilling the objectives above indicated and > ensuring that a real contact can be approached in case of abuse cases and > effectively serve the purpose of creating IRT object. > > This will improve the quality of the information and help to achieve the > goal of handling network abuses. > > Disadvantages: > None foreseen. > > > 6. Impact on resource holders > ----------------------------- > APNIC members have to verify and update (if required) their IRT objects > periodically. > > > 7. References > ------------- > ADDITIONAL INFORMATION > > a. Since this proposal is implemented, APNIC will publish the IRT also as > abuse-c, in order to facilitate the search in whois, for the same > information, regardless if looking for abuse-c or IRT. This is done in > order to assimilate the IRT to the majority of the RIRs where it is abuse-c. > > b. It is recommend that all NIRs implement a similar validation process > within their own jurisdictions. > > > c. Example of the validation procedure. > > 1) APNIC initiates the validation automatically, sending TWO consecutive > emails to each of the mailboxes. > > 2) These emails will be sent containing plain text only. > > 3) The first email will contain the URL where the validation is to be > performed ("validation.apnic.net") 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 each of the mailboxes must go to the URL > and paste 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 mailboxes, > 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 only be valid for a maximum of fifteen days. > > 8) If the code is not entered within that time, the system will mark the > IRT as "temporarily invalid” and will send a reminder with another unique > code and alert APNIC staff, so they can initiate a personalized follow-up > with the LIR. > > 9) If no reply is received confirming that the situation has been > corrected, after an additional period of three business days, the IRT will > be permanently marked as "invalid". > > 10) Once the issue has been resolved, the validation process will be > repeated automatically (items 1 to 7 above). If satisfactory, the IRT will > be marked as "valid"; otherwise it will be considered in breach of the > policy. > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
