Colleagues [Apologies if you receive duplicate versions of this email but my interaction with the RIPE NCC mailing lists is getting worse. Three attempts with gmail, yahoo and xs4all email accounts all failed to post this to the DB-WG so lets discuss it here...] 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@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
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. cheersdenisco-chair DB-WG From: "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk> To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@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
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@yahoo.co.uk" <ripedenis@yahoo.co.uk> To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@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@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
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... cheersdenisco-chair DB-WG From: Daniel Stolpe <stolpe@resilans.se> To: denis walker <ripedenis@yahoo.co.uk> Cc: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@yahoo.co.uk" <ripedenis@yahoo.co.uk> To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@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@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
On Thu, 30 Mar 2017 18:05:20 +0000 (UTC) denis walker <ripedenis@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@resilans.se> To: denis walker <ripedenis@yahoo.co.uk> Cc: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@yahoo.co.uk" <ripedenis@yahoo.co.uk> To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@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@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
Hi Andre I thought the IRT object (Incident Response Team) existed for large scale DDOS attack situations? One of the reasons for creating the "abuse-c:" attribute was because the IRT object was being hijacked for the 'less serious' complaints. cheers denis co-chair DB-WG From: ox <andre@ox.co.za> To: denis walker <ripedenis@yahoo.co.uk> Cc: Daniel Stolpe <stolpe@resilans.se>; "anti-abuse-wg@ripe.net" <anti-abuse-wg@ripe.net> Sent: Friday, 31 March 2017, 6:43 Subject: Re: [anti-abuse-wg] "abuse-c:" - a question....with no answers? On Thu, 30 Mar 2017 18:05:20 +0000 (UTC) denis walker <ripedenis@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@resilans.se> To: denis walker <ripedenis@yahoo.co.uk> Cc: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@yahoo.co.uk" <ripedenis@yahoo.co.uk> To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@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@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@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
participants (4)
-
Daniel Stolpe -
denis walker -
ox -
ripedenis＠yahoo.co.uk