Running a ticketing system could involve significant resources. However simply accepting, aggregating, and providing public information on contacts that are non-functional, ideally via an API so we can use it for ... :D
On Thu, Mar 28, 2019 at 7:38 AM Michael Peddemors <[email protected]> wrote: > Still would like to see that idea I put forth about ARIN actually having > a public ticketing system, for when the public reports inaccurate data. > > This way a public record can be seen to how long tickets remain > unresolved, and a bit of public shaming on this. > > I think this would do more than most policies. > > Just tried to email an large carrier (noPTR issues) so emailed the > contact on record.. > > OrgTechHandle: IPMAN-ARIN > OrgTechName: IP MANAGE > OrgTechPhone: +1-647-747-3294 > OrgTechEmail: [email protected] > OrgTechRef: https://rdap.arin.net/registry/entity/IPMAN-ARIN > > <[email protected]>: > Remote host 66.185.87.233 does not like recipient [email protected] > Remote host said: 550 5.1.1 <[email protected]>: Recipient address > rejected: User unknown in virtual mailbox table > > > > On 2019-03-26 12:52 p.m., ARIN wrote: > > On 21 March 2019, the ARIN Advisory Council (AC) accepted > > "ARIN-prop-264: Validation of Abuse-mailbox" as a Draft Policy. > > > > The Draft Policy text is below and can be found at: > > https://www.arin.net/participate/policy/drafts/2019_5/ > > > > You are encouraged to discuss all Draft Policies on PPML. The AC will > > evaluate the discussion in order to assess the conformance of this draft > > policy with ARIN's Principles of Internet number resource policy as > > stated in the Policy Development Process (PDP). Specifically, these > > principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The PDP can be found at: > > https://www.arin.net/participate/policy/pdp/ > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/participate/policy/drafts/ > > > > Regards, > > > > Sean Hopkins > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > Draft Policy ARIN-2019-5: Validation of Abuse-mailbox > > > > Problem Statement: > > > > The current policy, “3.6. Annual Validation of ARIN’s Public Whois Point > > of Contact Data” does not provide sufficient validation of the actual > > availability of the abuse mailbox. > > > > As a result, some resource-holders (LIRs and end-users) might not keep > > this contact information up to date, or might use a non-responsive > > mailbox, which could be full or not actively monitored, or even > > responding only to ARIN emails. > > > > In practice, this contact becomes ineffective to report abuse and > > generally gives rise to security issues and costs for the victims. > > > > Furthermore, POCs are verified only every year and provides a too much > > relaxed response time (60 days). > > > > Finally, the proposal is aiming to have a standard abuse-c/abuse-mailbox > > as a pointer to the actual abuse POC, in order to facilitate tools > > across regions. > > > > This proposal aims to solve those issues and ensure the existence of a > > proper abuse-c POC and the process for its utilisation. > > > > a. Arguments Supporting the Proposal > > > > The Internet community is based on collaboration. However, in many cases > > this is not enough and we need to be able to contact those > > resource-holders (LIRs or end-users) that may be experiencing a problem > > in their networks and are unaware of the situation. > > > > This proposal solves 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 that > > 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 resource-holder causing the abuse (or its customers, from whom they > > receive financial compensation for the service), instead of falling on > > the victim, as would be the case if they had to resort to a legal claim > > in an extreme case, thus avoiding costs (investigation and in the > > worst-case lawyers, solicitors, etc.) and saving time for both parties. > > > > Having an equivalent policy in different regions, has the advantage of > > improving overall response to abuse cases, reduces the cost for handling > > them, and facilitates the work for all the people involved in the > > operation of Internet. > > > > b. Arguments Opposing the Proposal > > > > ARIN members have to verify and update (if required) their abuse-c > > objects periodically. > > > > Policy Statement: > > > > Proposed > > > > 1.0 Abuse Contact Information > > > > The “abuse-c:” will reference a role object holding abuse contact > > information. The positioning of the “abuse-c:” attributes will make use > > of the hierarchical nature of the resource data to minimize the workload > > on resource holders. Internet number resources need to have an > > “abuse-c:” attribute. The “abuse-c:” will be mandatory for all aut-nums. > > Due the hierarchical nature of IP address objects, at least every direct > > allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited > > objects might have their own “abuse-c:” attribute or they will be > > covered by the higher-level objects. The role objects used for abuse > > contact information will be required to contain a single > > “abuse-mailbox:” attribute which is intended for receiving automatic and > > manual reports about abusive behavior originating in the resource > > holders’ networks. The “abuse-mailbox:” attribute must be available in > > an unrestricted way via whois, APIs and future techniques. ARIN will > > validate the “abuse-mailbox:” attribute at least every six months, as > > per the procedure stated in this policy. Where the attribute is deemed > > incorrect, it will follow up in compliance with relevant ARIN policies > > and procedures. As per current practice, other “e-mail:” attributes can > > be included for any other purposes. > > > > 2.0 About the “abuse-mailbox” > > > > Emails sent to “abuse-mailbox” must require manual intervention by the > > recipient at some point, and may not be filtered, because in certain > > cases this might prevent receiving abuse reports, for example in a spam > > case where the abuse report could include the spam message itself or > > URLs or content usually classified as spam. The “abuse-mailbox” may > > initially send an automatic reply, for example assigning a ticket > > number, applying classification procedures, requesting further > > information, etc. However, it should not require that the abuse reporter > > fills a form, as this will imply that each entity that needs to report > > abuse cases (a task that is typically automated), would be forced to > > develop a specific interface for each resource-holder in the world that > > mandates filling forms, 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 for > > by those whose clients cause the abuse (and from whom they obtain > > income). By way of information, it is worth noting that it is reasonable > > to expect that the abuse reporting procedure sends, with the initial > > abuse report, the logs, a copy of the spam message (attaching an example > > of the spam email or its full headers), or equivalent evidence > > (depending on the abuse type). Likewise, it is reasonable to expect that > > the initial auto-reply email could specify that the claim will not be > > processed unless such evidence has been submitted, thus allowing the > > sender an opportunity to repeat the submission and include relevant > > evidence. This allows automatic reporting, for example, via fail2ban, > > SpamCop or others, keeping costs at a minimum for both parties involved. > > > > 3.0 Objectives of “abuse-mailbox” validation > > > > The procedure, which will be developed by the ARIN, 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 the ARIN and not from > > third parties (which might involve security risks), avoiding, for > > example, a single “direct” URL for validation. 2. Avoid exclusively > > 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. Validation period of no longer than 15 > > days. 5. If validation fails, escalate to the LIR and set a new > > validation period not to exceed 15 days. The “initial” and “escalation” > > validation periods may be modified by the ARIN, if deemed appropriate, > > informing the community about the motivation. For example, it could be > > longer for the first validation, once this policy is implemented, and > > shortened afterwards once the percentage of failures decreases, so the > > quality of the contacts increases and consequently a decrease in the > > average abuse response times could be expected. (By way of example, a > > detailed procedure is included in this policy proposal under > > “Comments/Example of the validation procedure”) 4.0 Validation of > > “abuse-mailbox” > > > > ARIN will validate compliance with the items above, both when the > > “abuse-c:” and/or “abuse-mailbox:” attributes are created or updated, as > > well as periodically, not less than once every six months, and whenever > > ARIN sees fit. At the discretion of ARIN, in general or in specific > > cases (for example, for confirmation in cases of escalation under 5.), > > ARIN may use domains other than arin., and even modify the subject and > > body of the message, in order to perform said validations more > > effectively. Lack of compliance will initially lead to the blocking of > > that account’s access to the invalid resources at ARIN Online, except > > for the abuse-c/abuse-mailbox update and payments. The account blocking > > will be released upon re-validation of the abuse-c/ abuse-mailbox, > > triggered automatically by the update of the abuse-c/abuse-mailbox. > > During the blocking of that account to the invalid resources, each time > > is accessed, will show a warning message including this policy text, and > > to continue it will be necessary to confirm by means of a check-box, > > that the message has been read in full. ARIN will do a more exhaustive > > follow-up, in accordance with the relevant ARIN policies, procedures or > > contractual requirements. The frequency of the periodic validation could > > be modified if ARIN deems this appropriate and informs the community of > > its reasons. For example, a single validation could be done in the first > > year, to facilitate adherence to the policy, and then the number of > > annual validations could progressively increase, reaching even quarterly > > ones, with the aim of improving the quality of the contacts. > > > > 5.0 Escalation to ARIN > > > > To avoid fraudulent behavior (for example, an “abuse-mailbox” that only > > replies to ARIN 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), a mailbox will be > > available (for example, “[email protected]”), to escalate such > > situations. This would allow for a re-validation (according to section > > 4. above) and even intervention by ARIN and, where appropriate, the > > application of the relevant policies, procedures or contractual > > requirements. > > > > Comments: > > > > Timetable for implementation: Immediate > > > > Anything Else > > > > Situation in other regions: > > > > A similar proposal has been accepted in APNIC (being implemented) and is > > under discussion in the LACNIC and AFRINIC regions. It has also been > > submitted to RIPE (still not published). > > > > Example of the validation procedure. > > > > 1. ARIN initiates the validation automatically, sending TWO consecutive > > emails to the “abuse-mailbox”. > > > > 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.arin.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 “abuse-mailbox” 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 “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 only be valid for a maximum of 15 working > > days. > > > > 8. If the code is not entered within that time, the system will mark the > > “abuse-c” as “temporarily invalid” and will alert ARIN staff so that > > 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 > > “abuse-c” 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 > > “abuse-c” will be marked as “valid”; otherwise it will be considered in > > breach of the policy. > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ([email protected]). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact [email protected] if you experience any issues. > > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > -- Jo Rhett
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
