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/[email protected]/
[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 ]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Fri May 17 01:45:19 CEST 2019
Hi Nick, As it has been observed several times, the actual validation system is extremely weak and very easy to avoid, so 99% useless. If I put in my abuse-c your email (just an example). The validation will pass, and you will never notice that I've used your email to fake the system. So, clearly is the wrong way. If two validations are done per year, I don't think this is significant overhead for any resource holder vs the benefits of the time saving for the same resource holders that need to use the abuse mailbox of a counterparty that today is escaping from a real validation and creating troubles with abuse emails to someone else. Anyone failing in repetitive ocassions to comply with policies is subjected to further NCC scrutiny, including account closure. This is a different policy already in place. If we don't like that, we should change that policy, but then we don't need policies anymore. Policies are the rules for the community to be respected by all, and not having an administrative enforcement by the NCC is the wilde west. Regards, Jordi El 16/5/19 23:38, "anti-abuse-wg en nombre de Nick Hilliard" <anti-abuse-wg-bounces at ripe.net en nombre de nick at foobar.org> escribió: Gert Doering wrote on 16/05/2019 21:47: > No positive effect, but lots of negative side-effects. Abuse mailboxes are already checked. What matters for abuse management is whether reports are acted on. This policy doesn't address that. If the RIPE NCC is instructed to send 6-monthly reminders to all abuse contacts with the implicit threat that if they aren't acted on in the way specified in this policy, that the organisation in question can look forward to having their addressing resources vapourised, this will aggravate the RIPE NCC membership and corrode community trust in the organisation. The one thing it won't do is make abuse management better. Internet abuse management is not something that you're going to fix by beating LIRs with sticks, and if they don't react, that you threaten to beat them harder. Separate to this, it's inappropriate to micromanage the NCC in RIPE policy. It would be good if the RIPE working groups stopped trying to tell the RIPE NCC people how to do their jobs. Nick ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
- 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 ]