Just to clarify, we are RFC 2142 section 4 compliant. I mention section 4 
specifically as that is directly within my realm of control, the remaining 
sections I will check.

Both methods, web form submission and abuse@ are integrated ultimately into the 
same workflow. Being transparent, as things currently stand, the abuse@ 
submission method requires an additional element of human verification before 
ingestion to the workflow as it is open to abuse itself. For example, an 
annoyed former user who has been removed from the platform for abusive 
activities trying to subscribe it (and other RFC 2142 addresses) to thousands 
of pornographic mailing lists, or attempting to slam it with tens of thousands 
of junk emails.

We do take platform abuse seriously but, like any other company, there is 
always room for improvement. We have a dedicated team who’s 24/7 job function 
is to continually improve our systems and processes surrounding abuse, from 
trying to stem it at top of funnel, to mitigating on-going issues with as low 
MTTR as possible, to responding to abuse@ (and web form) submissions. 

tl;dr - both submission methods are available

Sent from my iPhone

> On Mar 19, 2019, at 10:52 AM, Rich Kulawiec <r...@gsp.org> wrote:
> 
>> On Tue, Mar 19, 2019 at 09:23:34AM -0400, Jeff McAdams wrote:
>> We would prefer, but don't require, that you use the web form because that
>> is integrated into the workflow of the groups that respond to those
>> reports.  
> 
> Why isn't abuse@ integrated into the workflow?  It darn well should be,
> (a) given that RFC 2142 has been "on the books" for 22 years and
> (b) given that methods for handling incoming abuse (or bug, or outage,
> or other) reports via email to role accounts are numerous and reliable.
> 
> To be clear: if you want to offer a web form in addition to an abuse@
> address (or a security@ address, or a postmaster@ address) that's fine.
> But web forms are a markedly inferior means of communication and are
> clearly not a substitute for well-known/standardized role addresses that
> route to the appropriate people/processes.
> 
> ---rsk
> 

Reply via email to