This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] 2019-04 New Policy Proposal (Validation of "abuse-mailbox")
- Previous message (by thread): [anti-abuse-wg] 2019-04 New Policy Proposal (Validation of "abuse-mailbox")
- Next message (by thread): [anti-abuse-wg] 2019-04 New Policy Proposal (Validation of "abuse-mailbox")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ángel González Berdasco
angel.gonzalez at incibe.es
Thu May 16 16:35:55 CEST 2019
Marco Schmidt writes: > Dear colleagues, > > A new RIPE Policy proposal, 2019-04, "Validation of "abuse-mailbox"", > is now available for discussion. > > This proposal aims to have the RIPE NCC validate "abuse-c:" > information more often, and introduces a new validation process that > requires manual input from resource holders. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-04 > (...) Looks good. A couple of notes. In addition to the first notice, it may be worth to add 'reminders' instead of escalating directly to the LIR, such as sending a reminder after one week (day 7), and another on the 14th day, prior to escalation. *This should not be necessary,* as the resource owner should have put the means so that emails received on the abuse-c are not lost, and someone actually reviews them, without having to insist on them. But I foresee that would improve the response process. Also, the resource holder should be able to manually request a new mailbox validation if the provided code is expired (eg. the main person in charge was on holiday and their backup did not handle it). RIPE should log the time taken by the different holders to validate their abuse-c, so that those statistics can be used in the future to better understand the effectivity of this process. Finally, I have been thinking how to improve the phrase «Commonly, if a ticket number has been generated, it should be kept (typically as part of the subject) through successive communications.» I came out with replacing it with this new paragraph: «It is quite common to have ticket numbers/identifiers associated to abuse reports in order to be able to differentiate them, which are typically included as part of the subject. Replies (either manual or automated) by the resource holder should maintain any identifiers used by the reporter, optionally adding their own one. And any reply by the abuse reporter should keep as well the identifier holding the ticket number on the resource holder system.» Best regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute https://www.incibe-cert.es/ PGP Keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ======================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ========================================================================
- Previous message (by thread): [anti-abuse-wg] 2019-04 New Policy Proposal (Validation of "abuse-mailbox")
- Next message (by thread): [anti-abuse-wg] 2019-04 New Policy Proposal (Validation of "abuse-mailbox")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]