[anti-abuse-wg] "abuse-c:" - a question....with no answers?

On Thu, 30 Mar 2017 18:05:20 +0000 (UTC)
denis walker <ripedenis at yahoo.co.uk> wrote:
> Hi Daniel
> Thanks for that suggestion. It has given me some ideas and I already
> have half a proposal in mind based on this....which I will submit
> when I fill in the other half...
>

The main issues are that different people have different abuse handling
methods as it depends on the type of abuse, scale of abuse and many
other factors.

right now we are trying to have only one record to handle everything
and this is causing resistance and failures...

For example: There is a different response for a 100TB DDOS than to 10
emails to a spamtrap (of which one is reported) and even in the same
category, a different response to a single spam complaint and a
complaint of 3 to 10000000 spams, etc.

So, I propose TWO complaint email records, one for emergency/mass/bulk
and one for standard complaints.

It is up to the recipient(s) to block/ignore non emergency complaints
to the emergency contact and/or to handle (or not handle) or not even
supply, email abuse records...

Andre

 
> cheersdenisco-chair DB-WG
> 
>       From: Daniel Stolpe <stolpe at resilans.se>
>  To: denis walker <ripedenis at yahoo.co.uk> 
> Cc: "anti-abuse-wg at ripe.net" <anti-abuse-wg at ripe.net>
>  Sent: Thursday, 30 March 2017, 16:10
>  Subject: Re: [anti-abuse-wg] "abuse-c:" - a question....with no
> answers? 
> 
> 
> Hi Denis,
> 
> Maybe som kind of "abuse-org" would do the trick. I.e. the default 
> abuse contact goes via the normal "org" attribute, but if there
> exists an "abuse-org" you can put different contact details there.
> 
> Just a plain email address might become a little bit too anonymous.
> 
> Cheers,
> Daniel
> 
> On Wed, 29 Mar 2017, denis walker wrote:
> 
> > Colleagues
> > 
> > A couple of weeks ago I asked the question below. No one has yet
> > responded. We need to resolve the issues around "abuse-c:", which
> > means we must make some software changes. In order to make the
> > right changes we need your feedback. If "abuse-c:" is nothing more
> > than an email address tagged on to a resource then the changes can
> > be very simple. The working group chairs can't make these
> > decisions.  We need your input and direction...
> > 
> > I understand that this issue has been talked about so many times
> > over several years...with no solution. This time we are determined
> > to take some action. Whilst nothing is ever final, lets make this
> > the last discussion on "abuse-c:" for a while.
> > 
> > cheers
> > denis
> > co-chair DB-WG
> > 
> > 
> > ______________________________________________________________________________________________________________________________________________________________________
> > From: "ripedenis at yahoo.co.uk" <ripedenis at yahoo.co.uk>
> > To: "anti-abuse-wg at ripe.net" <anti-abuse-wg at ripe.net>
> > Sent: Thursday, 16 March 2017, 18:14
> > Subject: "abuse-c:" - a question....
> > 
> > Colleagues
> > 
> > I would like to ask the community a question that looks at a wider
> > picture than the "abuse-c:" attribute itself. Depending on how
> > people react to this question, it may impact the chosen path to
> > solving the issue with documenting abuse contact details in the
> > RIPE Database.
> > 
> > The current implementation for "abuse-c:" documents the default
> > contact details for who handles abuse issues within an organisation
> > that holds resources. If the email address is invalid or there is
> > no response to a complaint sent to that address it is clear who the
> > organisation is and there are other contacts related to this
> > organisation.
> > 
> > Sometimes a resource holder delegates some responsibility for the
> > management of (one or more of) their resource(s) to another
> > person/organisation. This may be just the abuse handling. With the
> > current database semantics it is not always possible to create a
> > separate ORGANISATION object to document this responsibility. This
> > issue has been described as 'How to reference the email address for
> > the abuse reports for this resource?'.
> > 
> > The simple version of my question is 'Is it enough to only know the
> > email address and an un-validated postal address for the abuse
> > handler?'. An email address can be 'anyone at anybody.com'. This tells
> > you nothing about 'anyone' or 'anybody'. It is a one directional
> > channel to throw something down that may end in a black hole. If
> > nothing happens, who was supposed to have this responsibility? Not
> > everyone who uses this abuse contact information understands the
> > RIPE Database structure, the resource hierarchy or the contractual
> > responsibilities of the related parties. They may have searched
> > online for who to complain to, got this email address and got no
> > response. How do you take further action against an email address?
> > 
> > What I am working round to is explaining why the "abuse-c:" was
> > designed the way it is. Where responsibility for handling abuse was
> > delegated to another party (separate organisation or another
> > internal department) we wanted to maintain a closely coupled link
> > between the resource listing a contact and an organisation
> > responsible or accountable for abuse handling. As it turned out
> > this created the need for repetitive data in some cases and not
> > being able to record the right details in some other cases.
> > 
> > The simplest solution that has been discussed in the past is to
> > allow the "abuse-c:" attribute in resource objects. This does
> > create some resource and data management issues. But these can be
> > solved by providing resource managers with the right software
> > tools. Now we get to the in depth version of my question. Do we
> > need to maintain that close coupling in the database between who is
> > responsible or accountable for handling abuse for a resource and
> > their correct and validated (by the resource holder) contact
> > details?
> > 
> > If the answer to this question is a simple 'no' then we can easily
> > add "abuse-c:" attributes anywhere pointing to an email address and
> > provide the resource managers with tools to maintain the
> > data....job done.
> > 
> > If the answer is anything other than a simple 'no' and we believe
> > abuse information consumers without an in depth knowledge of the
> > database or industry need to easily understand 'who' claims to be
> > behind an email address then we may need a more complex solution.
> > 
> > I hope this makes sense and look forward to comments and questions.
> > 
> > cheers
> > denis
> > co-chair DB-WG
> 
> _________________________________________________________________________________
> Daniel Stolpe          Tel:  08 - 688 11 81
> stolpe at resilans.se Resilans AB            Fax:  08 - 55 00 21 63
>       http://www.resilans.se/ Box 45 094
>     556741-1193 104 30 Stockholm
> 
> 
>