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