Send Abuse Reports to a configured Webhook instead of or in addition to email
Problem to solve
The GitLab.com Anti-abuse department is currently using tools and processes to implement a complete workflow around responding to them. This includes using the forwarded abuse report emails to create issues in a private GitLab project. This has resulted in a hard to maintain
Intended users
Further details
Sending abuse reports via email potentially exposes private instance information since the email communication is not guaranteed to be encrypted from end to end. This improves on that situation by requiring a direct, protected connection to the receiver.
Proposal
Allow a webhook to be configured instead of or in addition to the emailed notifications in the configuration section for /admin/application_settings/monitoring
"Abuse Reports".
Permissions and Security
This can be configured only by an admin for an entire instance. For an MVC, the client should only send data over a valid TLS session. Connections should also respect any instance wide settings regarding outgoing network connections.
Future iterations may include some further validation of the target server.
Documentation
Availability & Testing
What does success look like, and how can we measure that?
The hard to maintain pipeline currently used to create issues from emailed Abuse Reports will no longer be necessary.
What is the type of buyer?
This features should be available to all tiers since it is used by administrators to maintains the trustworthiness of their GitLab instance to its users.