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] 2017-02 New Policy Proposal (Regular abuse-c Validation)
- Previous message (by thread): [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
- Next message (by thread): [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
ox
andre at ox.co.za
Fri Oct 6 09:32:08 CEST 2017
On Fri, 6 Oct 2017 09:19:02 +0200 Gert Doering <gert at space.net> wrote: > On Fri, Oct 06, 2017 at 08:54:14AM +0200, ox wrote: > > +++++ > > requiring abuse email (RR data) to be valid and functional is a very > > basic tenet (as it relates to morality and ethics as well as RR > > "goals") +++++ > > True. This is the goal, and I share that. > > But I'm sceptic on whether the particular proposal on the table will > do much to actually achieve this goal where change is needed - while > at the same time imposing extra work on those that already do the > right thing. > the core result or achievement would be: - a requirement for "real' data. the extra work is already done, if you have a functional abuse record, for example: abuse at hetzner.de - responding once or twice a year to an RR verification is the same effort as a .com domain registrant expends in confirming accuracy of registrant information and is hardly much 'extra work' regarding you saying 'where change is needed' - the actual change needed is that resource holders clean up their abuse. but, this is not the place of RIPE or a 'robust registry' - the place of an RR is to ensure valid, accurate and functional data. this includes abuse data, or any other data. I think I am missing what you are seeing? what do you think is inadequate in this specific proposal? Sometimes something that seems obvious to you, is not so obvious to someone else. you must remember Gert that you are very experienced and have a depth and POV that even any other experienced person may not see? > > > We can force people to have abuse mailboxes that trigger a > > > response if a mail from the RIPE NCC is received. > > > > > this is perfectly fine, imnsho, as it indicates receipt of > > communications, even if it is autoresponded. > > > > it just cannot autorespond: that this is a non monitored mailbox - > > as by definition, in this proposal, it has to be functional. > > > > functional implies that it can receive and respond to communications > > and is not a "black hole" or dev/null > > So, what have we achieved if there is someone who will personally > reply to verification mails from the RIPE NCC, and throw away > everything else? > > Yes, Mails will no longer bounce. Good. > But will it magically make those networks not interested in handling > abuse mails more interested in them? No. > So, where's the gain in the larger picture "fight against abuse"? > the gain in the big picture is that the recipient has received the communications. and any action or inaction enlightens the intent of the resource holder. any resource holder is completely free to do anything they wish or choose, but can no longer claim ignorance of their choices. plus, also see your own 'robust rr' para :) > [..] > > > Thus, ambivalence on the policy. > > > > is this a good thing? please reconsider your ambivalence? all it > > takes is for a few good people....(Edmond Burke ...) > > I see no positive effect. So I find it hard to support it. > positive effect is the actual requirement of real data by rr > The negative effects are limited. So I find it hard to oppose it. > indeed. > Ambivalence. > again: Edmond Burke > Gert Doering > -- NetMaster
- Previous message (by thread): [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
- Next message (by thread): [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]