Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
Hi! [...]
but business rules will require it to be [...]
I didn't find any "business rules" document at RIPE.
From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target.
Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable. One hell of a vision you got there, I'd say... ;) [though not explicitly stated, the following seems to be meant as justification of the proposal]
Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred.
When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object. Later in the thread I had to find out that it isn't. In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it... The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all. In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems. We're better off as it is now. The "Arguments supporting the proposal" are in my eyes simply unsustainable. Another cue regarding the possible aim I found was: "The outcome is, to have an abuse-c in place. That is all." Well, that's not true as discussed above, there are major problematic implications, and on the other side, simply to have another attribute doesn't seem like a valid justification to me. I mean, it's not "to have an abuse-mailbox", which would bear some sort of sense in itself in my eyes - while of course this has been done already. Actually I do not even see the motivation for an 'abuse industry' to lobby this at all!? But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this: - a resource has an administrative contact (complaints - whether abuse or not - are administrative issues) - a contact can have an explicit address for abuse reports. In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact. This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!? If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation... Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue. Well, at least time to update the "Arguments opposing" paragraph, I'd say... (dropping the proposal wouldn't be wrong either, I'd say) Regards, Chris
chrish@consol.net wrote:
Hi!
Hi,
[...]
but business rules will require it to be [...]
I didn't find any "business rules" document at RIPE.
From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target.
Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable. One hell of a vision you got there, I'd say... ;)
Usally people have different mailboxes or mail addresses for different purposes. The proposal even helps here a lot to seperate personal email addresses from abuse email addresses, simply because the abuse-c has to be defined now. So, everybody thats has to complain simply knows now who to contact and will nevermore bother somebodys personal email address like the email named in the admin-c (see an example below).
[though not explicitly stated, the following seems to be meant as justification of the proposal]
Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred.
When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object. Later in the thread I had to find out that it isn't. In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it... The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all.
The other places will fanish just in the moment the abuse-c is introduced, simply because because every resource owner has to re-think, how a complaint should reach him. If the resource owner does not like any confusion, he will have to remove abuse contacts from the remark section.
In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems. We're better off as it is now. The "Arguments supporting the proposal" are in my eyes simply unsustainable. Another cue regarding the possible aim I found was: "The outcome is, to have an abuse-c in place. That is all." Well, that's not true as discussed above, there are major problematic implications, and on the other side, simply to have another attribute doesn't seem like a valid justification to me. I mean, it's not "to have an abuse-mailbox", which would bear some sort of sense in itself in my eyes - while of course this has been done already. Actually I do not even see the motivation for an 'abuse industry' to lobby this at all!?
But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this: - a resource has an administrative contact (complaints - whether abuse or not - are administrative issues) - a contact can have an explicit address for abuse reports. In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact. This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!? If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation...
Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue.
Well, at least time to update the "Arguments opposing" paragraph, I'd say... (dropping the proposal wouldn't be wrong either, I'd say)
I understand that you will like to drop this proposal. Its the usual reaction from somebody who likes to hide his personal responsibility: A whois on consol.net reveales: domain: consol.net owner: n/a organization: ConSol* GmbH contact-hdl: CNET-520629 person: n/a organization: ConSol* GmbH So thats a german company without a CEO/Geschaeftsfuehrer ? Well you can do something like this with a .net domain, but at least the DENIC whois reveals an admin-c here: Name: Michael Elbel Organisation: ConSol* GmbH Adresse: Franziskanerstr. 38 PLZ: 81669 Ort: München Land: DE and your netblock wich has your mailserver shows inetnum: 194.246.122.0 - 194.246.123.255 netname: CONSOL-NET descr: ConSol Consulting & Solutions Software GmbH country: DE admin-c: ME7 tech-c: NOG1-RIPE status: ASSIGNED PI org: ORG-CCSS3-RIPE mnt-by: RIPE-NCC-END-MNT mnt-lower: RIPE-NCC-END-MNT mnt-by: CONSOL-MNT mnt-routes: CONSOL-MNT mnt-domains: CONSOL-MNT source: RIPE # Filtered organisation: ORG-CCSS3-RIPE org-name: ConSol Consulting & Solutions Software GmbH org-type: LIR address: ConSol Consulting & Solutions Software GmbH Franziskanerstr. 38 81669 Muenchen Germany phone: +498945841100 fax-no: +498945841111 e-mail: ripeadm@consol.de mnt-ref: CONSOL-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT admin-c: ME7 source: RIPE # Filtered role: Network Operating Group address: ConSol* GmbH address: Franziskanerstrasse 38 address: Muenchen, BY D-81669 phone: +49 89 45841-100 fax-no: +49 89 45841-111 e-mail: nog@consol.de admin-c: ME7 tech-c: ME7 nic-hdl: NOG1-RIPE mnt-by: DENIC-P source: RIPE # Filtered person: Michael Elbel address: ConSol* GmbH address: Franziskanerstrasse 38 address: D-81669 Muenchen address: Germany phone: +49 89 45841 256 fax-no: +49 89 45841 111 e-mail: me@freebsd.org nic-hdl: ME7 mnt-by: DENIC-P source: RIPE # Filtered hm, no abuse contact in the remarks, no abuse-mailbox, no nothing ... And a personal email address, thats obviously not related to your company (mabye simple because a lot of spam and wrong complains is arriving there). So ... you can be lucky, you will not have to remove or change any object or contact, because you already have none. You will simply insert the abuse-c and than you can even set the official email address of Michael Elbel in the ME7 contact. And looking on www.consol.de you should be able to insert abuse@consol.net with a working ticket system behind ... You should really support the proposal, it will help you a lot. Kind regards, Frank
Regards,
Chris
BTW: also very cool is to visit www.consol.net (the next step, if somebody likes to report abuse) ... PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Hi! On 12/07/2011 07:43 PM, Frank Gadegast wrote:
Usally people have different mailboxes or mail addresses for different purposes.
I.e. your idea is to require every admin-c to have different mailboxes.
The proposal even helps here a lot to seperate personal email addresses from abuse email addresses, simply because the abuse-c has to be defined now.
There already is an admin-c. To force admin-cs to use different/multiple mailboxes, another attribute is necessary. That would be abuse-mailbox. This already exists, so everybody who wants to use it, can use it. It's just that currently nobody is forced to use it, if you don't want/need to use it, you don't have to.
So, everybody thats has to complain simply knows now who to contact
...that would be the admin-c. And following the proposal: in some cases following weird, diffuse, and sparsely defined policies maybe also an abuse-c.
and will nevermore bother somebodys personal email address like the email named in the admin-c (see an example below).
The email address listed in my admin-c object is not my private personal email, but the email address chosen for the admin-c - for being contacted in case of administrative issues. This is true for both role and person objects. If you don't want to be emailed personally, use a role object. If you don't want people to use a specific email - don't list it in your contact objects! Even if you chose for whatever strange reason to enter into a role or person object an email you don't want people querying the db to know/use, what you would need following that rationale is an abuse-mailbox attribute for that admin-c object. Not another -c object. (Actually I guess a new 'secret-email' attribute would fit best for your needs)
The other places will fanish just in the moment the abuse-c is introduced, simply because because every resource owner has to re-think, how a complaint should reach him.
Sorry, no. According to the proposal, there will be additional objects and attributes. And people are forced to 'accept' being bulk-spammed. That's it. The rest is prophecy (and experience suggests the opposite - see the remarks on contradicting abuse-mailbox and other attributes in this very same thread). Btw, a short hint for resource owners on how to be contacted: - list your postal address in the way you'd wish to be contacted by postal service - list the phone number you'd wish to be contacted by by phone - list the fax number you'd wish to be contacted by by fax, or leave it out if you don't want to be contacted by fax - list the email address you'd wish to be contacted by, or leave it out if you don't want to be contacted by email - list the abuse-mailbox email address you'd wish to be contacted by in case of abuse complaints in case you wish to have a special mailbox for those, or leave it out if you don't
If the resource owner does not like any confusion, he will have to remove abuse contacts from the remark section.
Non-sequitur. I'd say: to minimize confusion, let's not add the proposed stuff. :)
Its the usual reaction from somebody who likes to hide his personal responsibility:
Well I think my explanation was quite comprehensive. On the other hand I think trying to go ad personam in a technical discussion should not be accepted. ConSol* GmbH is - as you probably already know from your extensive research, which btw also shows that your 'accusation' of 'hiding' is obviously unfounded - not my company. I'm working for ConSol*, and domain registration is not in my areas of responsibility or influence. Having said that - while wondering why, I mean it's not (well - it shouldn't be) your business - you might want to return to on-topic, non-ad-personam discussion. And what responsibility are you referring to? I mean, this sounds like I'm supposed to "take the responsibility to disagree with you"? Spooky...
hm, no abuse contact in the remarks, no abuse-mailbox, no nothing ...
Thanks for providing the opportunity to point that out. There is no abuse-c (well...), there is no abuse-mailbox, but there's no no nothing: there is an admin-c, and that admin-c has (among other contact data) an e-mail.
And a personal email address, thats obviously not related to your company (mabye simple because a lot of spam and wrong complains is arriving there).
Again, all this is pulled out of thin air (much like the 'substance' of the proposal, if you ask me). It's a person object, in that regard 'personal email address' is probably formally right. And also: not surprising. :) I don't see how that is 'obviously not related to the company'. And regarding the rest of your statement, I don't quite understand what you're trying to say there.
You should really support the proposal, it will help you a lot.
Well actually, as I already explained, at least for the broad majority this proposal doesn't help, but complicates things and causes partly severe problems. So I don't really see a future for it... And this also doesn't really seem to change, it actually gets worse: in your reply I didn't find a single argument explaining or clarifying on the issues I mentioned, or bringing forward any new or neglected aspects. And experience shows that being attacked personally when trying to discuss a technical issue is a red flag regarding the subject and/or the motivation of the attacking party... I still failed to see who might be 'helped' by the proposed stuff, and how... I mean, I'm convinced the authors at least had to think this will somehow help them, but I don't see how... Regards, Chris
chrish@consol.net wrote:
Hi!
Hi,
There already is an admin-c.
Well, administration is something completely different than abuse responsibilty, right ? One is called "administration", the other is "abuse" ... ... "administration", "abuse", you see, two different words. Two different responsibilities. I somehow got puzzled, because you really think, that somebody should try to reach your admin-c, when reporting spam or other abuse. The admin-c is the administration, the CEO, the owner, not the administrator of some resources. Could that all explain your big confusion ? Yes, and thats why your arguments are all wrong and useless and are only confusing.
And what responsibility are you referring to?
Surely your responsibility for the use of the resources giving your company by your RIR/LIR. Who should I contact, if one of your servers on your networks got hacked and misused for attacking our networks ? Please publish some email addresses at the right places, so I could contact you quick as possible, what also helps you to identify problems. I will defny not contact your admin-c, hes probably on a long business trip aqcuiring a third company, maybe "Consol Ltd.", making holidays or is ill, I need an email address of your anti abuse staff beeing read 24x7 and no postal address or phone only working daytime on business days.
ConSol* GmbH is - as you probably already know from your extensive research, which btw also shows that your 'accusation' of 'hiding' is obviously unfounded - not my company.
Hm, obviously wrong, these to companies are directly nested: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; Ques: 1, Ans: 1, Auth: 3, Addit: 2 ;; QUESTIONS: ;; consol.net, type = MX, class = IN ;; ANSWERS: consol.net. 63955 MX 10 mailrelay.consol.de. ;; AUTHORITY RECORDS: consol.net. 63955 NS dns3.consol.net. consol.net. 63955 NS dns2.consol.net. consol.net. 63955 NS dns1.consol.net. And you have an address under @consol.net But you are using the internal resources, mailservers and gateways of consol.de So: consol.de and consol.net are the same and you are an internal. Received: from sol1.bb.consol.de (sol1.bb.consol.de [10.250.0.71]) by gw1.consol.de (8.14.4/8.14.4) with ESMTP id pB7L3g6f040098 BTW: you have no signature attached, thats why it has to go over the list only. Im not sending somebody email, when hes not open enough to tell who he is.
To force admin-cs to use different/multiple mailboxes, another attribute is necessary. That would be abuse-mailbox. This already exists, so everybody who wants to use it, can use it. It's just that currently nobody is forced to use it, if you don't want/need to use it, you don't have to.
So, everybody thats has to complain simply knows now who to contact
...that would be the admin-c. And following the proposal: in some cases following weird, diffuse, and sparsely defined policies maybe also an abuse-c.
and will nevermore bother somebodys personal email address like the email named in the admin-c (see an example below).
The email address listed in my admin-c object is not my private personal email, but the email address chosen for the admin-c - for being contacted in case of administrative issues. This is true for both role and person objects. If you don't want to be emailed personally, use a role object. If you don't want people to use a specific email - don't list it in your contact objects!
Even if you chose for whatever strange reason to enter into a role or person object an email you don't want people querying the db to know/use, what you would need following that rationale is an abuse-mailbox attribute for that admin-c object. Not another -c object. (Actually I guess a new 'secret-email' attribute would fit best for your needs)
The other places will fanish just in the moment the abuse-c is introduced, simply because because every resource owner has to re-think, how a complaint should reach him.
Sorry, no. According to the proposal, there will be additional objects and attributes. And people are forced to 'accept' being bulk-spammed. That's it.
The rest is prophecy (and experience suggests the opposite - see the remarks on contradicting abuse-mailbox and other attributes in this very same thread).
Btw, a short hint for resource owners on how to be contacted: - list your postal address in the way you'd wish to be contacted by postal service - list the phone number you'd wish to be contacted by by phone - list the fax number you'd wish to be contacted by by fax, or leave it out if you don't want to be contacted by fax - list the email address you'd wish to be contacted by, or leave it out if you don't want to be contacted by email - list the abuse-mailbox email address you'd wish to be contacted by in case of abuse complaints in case you wish to have a special mailbox for those, or leave it out if you don't
If the resource owner does not like any confusion, he will have to remove abuse contacts from the remark section.
Non-sequitur. I'd say: to minimize confusion, let's not add the proposed stuff. :)
Its the usual reaction from somebody who likes to hide his personal responsibility:
Well I think my explanation was quite comprehensive.
On the other hand I think trying to go ad personam in a technical discussion should not be accepted.
ConSol* GmbH is - as you probably already know from your extensive research, which btw also shows that your 'accusation' of 'hiding' is obviously unfounded - not my company. I'm working for ConSol*, and domain registration is not in my areas of responsibility or influence. Having said that - while wondering why, I mean it's not (well - it shouldn't be) your business - you might want to return to on-topic, non-ad-personam discussion. And what responsibility are you referring to? I mean, this sounds like I'm supposed to "take the responsibility to disagree with you"? Spooky...
hm, no abuse contact in the remarks, no abuse-mailbox, no nothing ...
Thanks for providing the opportunity to point that out. There is no abuse-c (well...), there is no abuse-mailbox, but there's no no nothing: there is an admin-c, and that admin-c has (among other contact data) an e-mail.
And a personal email address, thats obviously not related to your company (mabye simple because a lot of spam and wrong complains is arriving there).
Again, all this is pulled out of thin air (much like the 'substance' of the proposal, if you ask me).
It's a person object, in that regard 'personal email address' is probably formally right. And also: not surprising. :) I don't see how that is 'obviously not related to the company'. And regarding the rest of your statement, I don't quite understand what you're trying to say there.
You should really support the proposal, it will help you a lot.
Well actually, as I already explained, at least for the broad majority this proposal doesn't help, but complicates things and causes partly severe problems. So I don't really see a future for it... And this also doesn't really seem to change, it actually gets worse: in your reply I didn't find a single argument explaining or clarifying on the issues I mentioned, or bringing forward any new or neglected aspects. And experience shows that being attacked personally when trying to discuss a technical issue is a red flag regarding the subject and/or the motivation of the attacking party...
I still failed to see who might be 'helped' by the proposed stuff, and how... I mean, I'm convinced the authors at least had to think this will somehow help them, but I don't see how...
Regards,
Chris
Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Hi,
From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target.
Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable. One hell of a vision you got there, I'd say... ;)
[though not explicitly stated, the following seems to be meant as justification of the proposal]
Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred.
If the current system was so obvious to everyone: - why do so many data maintainers put abuse contact details in "remarks:"? - why do so many users send complaints to email addresses found in "notify:" and "changed:" attributes? - why does anyone use "abuse-mailbox:", which has always been optional, when "admin-c:" has always been available? - The "admin-c:" has never been defined as an abuse contact. It is not reasonable to assume that everyone who linked an email address to that attribute wants to receive abuse complaints on that address, even if some do.
When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object. Later in the thread I had to find out that it isn't. In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it... The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all.
Just to clarify what the implementation is really doing, because it seems that some things have been mixed up a little bit. - Add 2 new attributes, "role-type:" and "abuse-c:" - Add NO new objects - Optionally remove the IRT object as it fits well as a role type - Optionally replace "mnt-irt:" attribute with an "irt-c:" - Remove "abuse-mailbox:" from MNTNER, ORGANISATION, PERSON objects - Keep "abuse-mailbox:" and "e-mail:" in ROLE object
In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems.
A new system often looks more complicated than something you are familiar with. Imho it makes things easier to understand and much easier to maintain.
But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this: - a resource has an administrative contact (complaints - whether abuse or not - are administrative issues) - a contact can have an explicit address for abuse reports.
What if the administrative contact is not the place to report abuse to. Just because other companies are different then yours? And admin-c, as I understood it is not the (System) Administration. What would we do in this situation? Where would we store phone number and other information about an abuse department. Because in other companies there are abuse departments wanting to publish these information.
In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact.
Which are usually all spam filtered, because these addresses are in many cases personal addresses. Beside that since these are personal addresses they are underlying query restrictions.
This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!? If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation...
If that would have been the intend I would have worded the Proposal exactly in this way ;-) But since I have not and the whole working group agreed on this wording and not another it should be clear that this was not the intention.
Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue.
Nobody said, that we are removing the e-mail attribute and I can not follow the reasons above, because I do not completely understand the reasons above, because they are referencing just wrong information. That confusion starts already with the fact that the abuse-mailbox attribute shall be mandatory. That is in general just wrong. The abuse-c is mandatory and the object that will be referenced by the abuse-c has to have an abuse-mailbox attribute. If you use your usual object and add an abuse-mailbox or if you create a complete new object for an abuse department and add an abuse-mailbox there is completely open. In other words, if you have 10 different objects and you have to publish an abuse-c there is only need to add an abuse-mailbox attribute to 1 object. Hope this makes things more clear. Thanks, Tobias -- abusix
On 12/08/11 11:04, Tobias Knecht wrote:
If the current system was so obvious to everyone: - why do so many data maintainers put abuse contact details in "remarks:"?
Until recently, the attribute trouble: existed. Then it was removed and moved all the data over to remarks-attribute. At the same time, the abuse-mailbox:-attribute was created. It is going to take at least another 10 years before all handles are updated to this standard.
- why do so many users send complaints to email addresses found in "notify:" and "changed:" attributes?
I always send to all emails I can find when contacting unknown companies. This is because the data accuracy is not always very good and I don't want to waste time resending my email. Secondly, it can be difficult to know if tech-c or admin-c should receive the mail. Adding abuse-c could make it even more difficult to decide. The works-all-the-time solution is to send to anyone.
- why does anyone use "abuse-mailbox:", which has always been optional, when "admin-c:" has always been available?
Because the email:-attribute is by default hidden. Abuse-mailbox: is the workaround.
- The "admin-c:" has never been defined as an abuse contact. It is not reasonable to assume that everyone who linked an email address to that attribute wants to receive abuse complaints on that address, even if some do.
That doesn't really matter to me. They are responsible for the resource and can redirect my email to the proper person if they are unable to answer it. Failure to respond is subject to existing ripe policies, although probably never practised.
What if the administrative contact is not the place to report abuse to. Just because other companies are different then yours?
You are correct about that. Admin-c is always the end-user/customer (Ripe policy). The abuse-contact is however often an ISP/LIR or a comination of one/both/the other depending on the what the issue is. An abusive user on a webforum is subject to admin-c while a hacker could be subject to the ISP abuse-c.
Hi,
On 12/08/11 11:04, Tobias Knecht wrote:
If the current system was so obvious to everyone: - why do so many data maintainers put abuse contact details in "remarks:"?
Until recently, the attribute trouble: existed. Then it was removed and moved all the data over to remarks-attribute. At the same time, the abuse-mailbox:-attribute was created. It is going to take at least another 10 years before all handles are updated to this standard.
I think you are partly right. I do not think that this will take 10 years. The clean-up is a major part of this proposal and I think there will be a lot of opportunities to really clean up things. It could be easily done to use the same objects that are used for an admin-c as an abuse-c as long as an abuse-mailbox attribute is given. If this is not given, maybe one of the higher level ranges has an abuse-c which is absolutely enough. At the end only direct allocated ranges would need an abuse-c set, because this would be enough from a policy point of view.
- why do so many users send complaints to email addresses found in "notify:" and "changed:" attributes?
I always send to all emails I can find when contacting unknown companies. This is because the data accuracy is not always very good and I don't want to waste time resending my email. Secondly, it can be difficult to know if tech-c or admin-c should receive the mail. Adding abuse-c could make it even more difficult to decide. The works-all-the-time solution is to send to anyone.
And that is exactly what this proposal should fix. This will not make it more difficult to decide. If you have an abuse report you have to use abuse-c in future. There is no questions if you should use admin-c or tech-c. If abuse-c is not working you can go up in the hierarchy and/or inform RIPE NCC if something is really going wrong and data is not accurate. This will start a process in whcih RIPE NCC will contact the maintainer and work through with him to get things solved. (Another plus for the data accuracy) The data accuracy part can be looked at by the Task Force if wished by the community as soon as we have consensus on this proposal.
- why does anyone use "abuse-mailbox:", which has always been optional, when "admin-c:" has always been available?
Because the email:-attribute is by default hidden. Abuse-mailbox: is the workaround.
Exactly. And this workaround should be pushed into a working solution and not staying a workaround.
- The "admin-c:" has never been defined as an abuse contact. It is not reasonable to assume that everyone who linked an email address to that attribute wants to receive abuse complaints on that address, even if some do.
That doesn't really matter to me. They are responsible for the resource and can redirect my email to the proper person if they are unable to answer it. Failure to respond is subject to existing ripe policies, although probably never practised.
I'm not on the same page with you here. Redirecting complaints kills the speed of complaints to react fast. And this will end up in bad abuse handling. Great abuse handling imho is fast in processing and in reaction. And we are talking here not about 10 or 15 complaints a day. We are talking about Abuse Departments and abuse mailboxes receiving up to 500.000 messages per day and asking for more.
What if the administrative contact is not the place to report abuse to. Just because other companies are different then yours?
You are correct about that. Admin-c is always the end-user/customer (Ripe policy). The abuse-contact is however often an ISP/LIR or a comination of one/both/the other depending on the what the issue is. An abusive user on a webforum is subject to admin-c while a hacker could be subject to the ISP abuse-c.
Abuse departments are there to solve abuse. No matter what kind of abuse. I do not see a difference in that. Even than while automatic reporting formats like ARF or X-ARF are used more and more it is easily possible to redirect complaints from a role-account to the right place. But is is not easy doable to redirect complaints from a personal email address to the right place. Thanks, Tobias -- abusix
participants (4)
-
chrish＠consol.net -
Frank Gadegast -
Jørgen Hovland -
Tobias Knecht