[anti-abuse-wg] Proposal: Publish effective users' abuse-c

Hi Alessandro


On Fri, 21 Jan 2022 at 13:03, Alessandro Vesely <vesely at tana.it> wrote:
>
> Hi Denis,
>
> I followed the discussion, and got a rough idea of how it works.  At the time,
> I succeeded convincing my ISP (Eutelia) to assign an abuse-mailbox to me.
> Afterwards the policy changed, but meanwhile my ISP went belly up and I
> couldn't convince the new one to set abuse-c for me.
>
> The idea is to add extra addresses to assignment objects, irrespective of the
> resource holder, based on the wish of its customer who is actually connected to
> the resource.  Would that be at all possible?

When you say " irrespective of the  resource holder, based on the wish
of its customer" do you mean without their consent or control? That is
not possible as they maintain the assignment object. I would also say
it is not desirable. That would allow an abuser to override the
resource holders abuse-c and ignore all abuse reports.

> And, if yes, would it be
> acceptable by the resource holder or are there contractual impediments?
> Finally, if feasibility is ok, would operators take advantage of it or is it
> only me?

If you are talking about adding extra abuse addresses to assignment
objects by agreement with the resource holder, as I explained, that is
possible now by simply adding an abuse-c to the assignment .

cheers
denis
co-chair DB-WG


>
>
> Best
> ale
>
>
> On Thu 20/Jan/2022 16:18:10 +0100 denis walker wrote:
> > Hi Alessandro
> >
> > Do you realise that abuse-c works hierarchically? The resource holder
> > is required to have an abuse-c in their ORGANISATION object as a
> > default. It was agreed by the community a few years ago to allow
> > additional abuse-c attributes in the resource objects. So if an end
> > user wants to receive abuse reports for their network the resource
> > holder can add an additional abuse-c attribute into the assignment
> > object (which is usually maintained by the resource holder). The abuse
> > ROLE object can be maintained by the end user so they can set their
> > own abuse email address. A query will only return the closest abuse
> > email address to any given IP address. So for any address in the end
> > user's range it will return their abuse email.
> >
> > cheers
> > denis
> > co-chair DB-WG
> >
> > On Thu, 20 Jan 2022 at 13:37, Alessandro Vesely <vesely at tana.it> wrote:
> >>
> >> Hi all,
> >>
> >> we all know abuse-c data is to be filled by the IP assignee, which I call ISP
> >> in the following.
> >>
> >> I understand that, since ISPs own IP space it is their job to ensure that it
> >> isn't abused.  If they give up the receiving of abuse complaints and give it to
> >> their customer instead, and they don't receive the complaints as a result, then
> >> they won't be aware if their customer is violating important policies.
> >>
> >> However, it is the ISPs' customers who are the effective users of those IPs.
> >> Any complaint, whether reporting spam or botnet activity, can probably be
> >> handled more effectively by the people who run the systems connected to a given
> >> IP than the actual owner.
> >>
> >> I propose that RIPE accepts abuse-c email addresses from verified effective
> >> users of a range of IP numbers, stores them in the database, and serves them in
> >> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  Various
> >> automated methods can be adopted to allow an effective user to be verified; for
> >> example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way
> >> can expire after a few months, forcing the effective user to renew them, so as
> >> to avoid stale entries.
> >>
> >> I'm unsure if the above requires proposing a new policy or what else.  For the
> >> time being, it would be interesting to gauge if this WG likes the idea and if
> >> there are effective users, apart from me, who would be interested in publishing
> >> their abuse-c.
> >>
> >>
> >> Best
> >> Ale
> >> --
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
> >