Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland)

Tue Mar 19 15:30:58 UTC 2019

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 <rsk at 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
> 