<div dir="ltr"><div dir="ltr">Strongly opposed as written.<div><br></div><div>This policy would require that all "abuse reports receive a response" from "a human processor who evaluates each message received", which constitutes an inappropriate interference in the business operations of ISPs, and presents a denial of service vector.  There are many entirely appropriate automated actions that well-run ISPs take in response to abuse reports that don't involve "a human processor who evaluates each message received", and don't necessarily require a response to the original reporter.  The first project I undertook at my first job was writing a mostly-automated abuse processing system that properly dealt with all incoming abuse@ email, but would not be compliant with this policy language as written because it took fully automated action when appropriate.</div><div><br></div><div>If you want to impose such onerous requirements on ISPs, the appropriate method to do so is via legislation (as was done for the DMCA), not by ARIN number resource administration policy.</div><div><br></div><div>-Scott</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 16, 2019 at 8:29 AM ARIN <<a href="mailto:info@arin.net">info@arin.net</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">The following has been revised and retitled:<br>
<br>
* Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts<br>
<br>
Formerly:<br>
<br>
* Draft Policy ARIN-2019-5: Validation of Abuse-mailbox<br>
<br>
Revised 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 POCs Referenced as Abuse Contacts<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>
availablility 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 may be full or not actively monitored. Some may even <br>
respond only to ARIN emails.<br>
<br>
In practice, this contact becomes ineffective for reporting abuse and <br>
generally gives rise to security issues and costs for the victims.<br>
<br>
Furthermore, POCs are verified only every year and provide a very <br>
relaxed response time (60 days).<br>
<br>
Finally, the proposal seeks to standardize the abuse-c/abuse-mailbox as <br>
a pointer to an actual abuse POC in order to facilitate development of <br>
tools that can work across regions.<br>
<br>
Proposed Policy Statement:<br>
<br>
Add to section 3.6 of the NRPM as follows:<br>
<br>
3.6.6 Policies specific to Abuse Contacts<br>
<br>
3.6.6.1 Abuse Contact Information<br>
<br>
The Abuse Contact will reference a POC object holding Abuse contact <br>
information. Each org must have an Abuse Contact. Optionally, resource <br>
records may point directly to an Abuse Contact as an override to the <br>
corresponding organizational Abuse Contact specific to that resource.<br>
<br>
3.6.6.2 Email Addresses in POCs used as Abuse Contacts<br>
<br>
Emails sent to this address must ultimately reach a human processor who <br>
evaluates each message received.<br>
<br>
Messages cannot be automatically filtered because legitimate abuse <br>
reports may include contents which would trigger such filters.<br>
<br>
Reports to this mailbox may undergo initial automatic processing for the <br>
following purposes:<br>
<br>
* An automated reply assigning a ticket number, applying classification <br>
procedures, etc.<br>
* An indication of the required information for an abuse report to be <br>
processed, such as pertinent logs, copy of the spam message with full <br>
headers, or any other relevant evidence of abuse.<br>
* The intent is to facilitate automated abuse reporting in consistent <br>
formats lowering cost for both victims and those processing legitimate <br>
abuse reports.<br>
<br>
3.6.6.3 Abuse Contact Validation Objectives Staff must develop a <br>
validation procedure which accomplishes all of the following objectives:<br>
<br>
1. A simple process which allows POCs to validate that the validation <br>
request is actually from ARIN.<br>
2. Avoids exclusively automated processing.<br>
3. Confirms that the person performing the validation understands the <br>
procedure and relevant policies. That the mailbox is regularly monitored <br>
and that abuse reports receive a response.<br>
4. Maximum validation period is 15 days.<br>
5. If validation fails, escalate to the LIR for an additional 15 days.<br>
<br>
The initial and escalation validation periods may be modified by ARIN <br>
staff, if deemed appropriate. In such a case, the community shall be <br>
notified at least 5 days prior to implementation of the change (at least <br>
via arin-announce and arin-ppml) including the rationale for the change.<br>
<br>
3.6.6.4 Validation of Abuse Contacts<br>
<br>
ARIN will validate that the email listed in each POC referenced as an <br>
abuse contact for one or more ORG or Resource records under any of the <br>
following circumstances:<br>
<br>
* When the POC record is created or first referenced as an Abuse POC.<br>
* When a referenced POC record is updated.<br>
* No less than every 6 months<br>
* At any other time ARIN staff deems necessary<br>
<br>
3.6.6.5 Escalation to ARIN<br>
<br>
To avoid fraudulent behavior (for example an email address that responds <br>
only to ARIN emails or emails with a specific subject or content), or <br>
failure to comply with other aspects of this policy, ARIN designates to <br>
receive reports and to escalate any such situations. This will allow for <br>
re-validation (per section 3.6.6.4) and even intervention by ARIN and, <br>
where appropriate the application of the relevant policies, procedures, <br>
or contractual requirements.<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></div>