Following up my own mail...
Also, the "trouble" field is a good thought - maybe we should add "trouble" to inetnum, as there is already a field name defined for the purpose essentially. Just an idea.
"trouble" is not really the answer as it is freeform. It needs to be a syntax checked email address. abuse-c to a person/role object seems sensible. -- Rev Adrian Kennard Andrews & Arnold Ltd / AAISP www.aaisp.net.uk
Hi Adrian, Im not sure if you have seen my previous mail, but I suggested to add a field called "abuse-address" in the maintainer object and make a rule saying Ripe NCC MUST check that the email address is correct by sending a mail to it and not create the maintainer object until the mail has been responded. MNT-BY is mandatory on inetnum objects so once all maintainer objects have this field added all inetnum objects will be refering to a correct abuse address without having each LIR to go through all inetnums. The problem with person object is that the email field is optional, so I don't see it as an option to refer to this object in abuse matters. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]On Behalf Of Rev Adrian Kennard Sent: 12. januar 2004 13:37 To: db-wg@ripe.net Subject: [db-wg] abuse-c
Following up my own mail...
Also, the "trouble" field is a good thought - maybe we should add "trouble" to inetnum, as there is already a field name defined for the purpose essentially. Just an idea.
"trouble" is not really the answer as it is freeform. It needs to be a syntax checked email address. abuse-c to a person/role object seems sensible.
-- Rev Adrian Kennard Andrews & Arnold Ltd / AAISP www.aaisp.net.uk
Dear all! On Mon 2004-01-12 (14:17), Christian Rasmussen wrote:
Hi Adrian,
Im not sure if you have seen my previous mail, but I suggested to add a field called "abuse-address" in the maintainer object and make a rule saying Ripe NCC MUST check that the email address is correct by sending a mail to it and not create the maintainer object until the mail has been responded. MNT-BY is mandatory on inetnum objects so once all maintainer objects have this field added all inetnum objects will be refering to a correct abuse address without having each LIR to go through all inetnums.
I'm sorry, but in my opinion, the only purpose of the maintainer in RIPE whois database is to maintain the data in the database. That means on the other hand that the maintainer doesn't deal with any technical or abuse issues. Be beware of the fact that other databases don't have a maintainer at all! As a result, I can't see any reason to put in an abuse mail address in the Maintainer object. If I had an abuse issue, I would tell it to the admin-c/tech-c or if it existed to the person/role mentioned in an inet[6]num object. In many cases I think this will work. So, if anyone doesn't want abuse issues having sent to admin-c or tech-c of the inet[6]num , he would automatically insert an abuse-c person/role (if possible).
The problem with person object is that the email field is optional, so I don't see it as an option to refer to this object in abuse matters.
It should be forbidden to put in a person/role without email address as a tech-c or abuse-c. Or is there anybody out there who would to talk to a technical person by snail mail :-) Best regards, Christoph Mohr
Med venlig hilsen/Best regards
Christian Rasmussen Hosting manager, jay.net a/s
Smedeland 32, 2600 Glostrup, Denmark
Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301
Produkter / Products: http://hosting.jay.net
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]On Behalf Of Rev Adrian Kennard Sent: 12. januar 2004 13:37 To: db-wg@ripe.net Subject: [db-wg] abuse-c
Following up my own mail...
Also, the "trouble" field is a good thought - maybe we should add "trouble" to inetnum, as there is already a field name defined for the purpose essentially. Just an idea.
"trouble" is not really the answer as it is freeform. It needs to be a syntax checked email address. abuse-c to a person/role object seems sensible.
-- Rev Adrian Kennard Andrews & Arnold Ltd / AAISP www.aaisp.net.uk
-- -- Christoph Mohr, Institute of Mathematics and Computer Science ------------ University of Education Ludwigsburg Phone: +49 7141 140-380 Reuteallee 46, D-71634 Ludwigsburg Fax: +49 7141 140-435 -- mailto: mohr@belwue.de ----------------------- http://www.belwue.de/ -----
On Mon, Jan 12, 2004 at 03:48:40PM +0100, Christoph Mohr wrote:
The problem with person object is that the email field is optional, so I don't see it as an option to refer to this object in abuse matters.
It should be forbidden to put in a person/role without email address as a tech-c or abuse-c. Or is there anybody out there who would to talk to a technical person by snail mail :-)
The last one "why is an email address not mandatory on person objects", has been raised before and from what I remember making this mandatory creates a race-condition in the initial setup when establishing a registry. (registry is needed for the email to work -> email is required working to create the registry). Grtx, MarcoH
Hi, * "Christian Rasmussen" <chr@jay.net> wrote:
Im not sure if you have seen my previous mail, but I suggested to add a field called "abuse-address" in the maintainer object and make a rule saying Ripe NCC MUST check that the email address is correct by sending a mail to it and not create the maintainer object until the mail has been responded.
I don't think that this is useful, because I'd maybe like to set different abuse contacts for different inet[6]num objects, but want to be able to protect all those objects with one and the same maintainer object. Besides, I don't think that we really need to validate the existence of the email address supplied. I'd also like to see a mandatory/multiple abuse-c field containing a rfc-valid email address. regards, sebastian -- whois: sabt-ripe - phone: +49 (0)160 90759764 email: sabt@sabt.net - pgp-pubkey: 0xD008DA9C
Hi Sebastian,
Im not sure if you have seen my previous mail, but I suggested to add a field called "abuse-address" in the maintainer object and make a rule saying Ripe NCC MUST check that the email address is correct by sending a mail to it and not create the maintainer object until the mail has been responded.
I don't think that this is useful, because I'd maybe like to set different abuse contacts for different inet[6]num objects, but want to be able to protect all those objects with one and the same maintainer
Okay, this was discussed yesterday and we talked about a combination of what Daniel Karrenberg suggested and the above, meaning you just add an optional abuse attribute to the inetnum objects, if its not added the abuse address will "default" to the abuse address of the maintainer object. Wouldn't this work for you?
object. Besides, I don't think that we really need to validate the existence of the email address supplied.
hm.. honestly I must agree, I very much doubt any LIR will try to forge an abuse address.. But I understand that is the reason for encryption features of the current irt object, so if somekind of check mechanism is needed for certain LIRs to use this concept I suggest the email address is checked as described above.
I'd also like to see a mandatory/multiple abuse-c field containing a rfc-valid email address.
Im not sure why it should be multiple? But I think most of us on this list can agree with you that a valid abuse email address associated with each inetnum in the database would be very welcome. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
Hi *,
Im not sure why it should be multiple? But I think most of us on this list can agree with you that a valid abuse email address associated with each inetnum in the database would be very welcome.
Just a stupid question: how do you assure the address is valid in the first place, and after that stays valid, i.e. there is a human behind it reading it? (without putting additional workload on the NCC manual validating all of these) lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On Tue, Jan 13, 2004 at 11:52:04AM +0100, Ulrich Kiermayr wrote:
Hi *,
Im not sure why it should be multiple? But I think most of us on this list can agree with you that a valid abuse email address associated with each inetnum in the database would be very welcome.
Just a stupid question: how do you assure the address is valid in the first place, and after that stays valid, i.e. there is a human behind it reading it? (without putting additional workload on the NCC manual validating all of these)
Let's just limit it to be syntactically correct accoording to whatever the rfc at that moment specify as 'syntactically correct'. There is no other way of ensuring that it's valid on a certain moment. There is still some form of 'trust' involved as to the point that the LIR inserting the address takes abuse serious. And I hope the majority still does, so the system would work and people don't have to use other things like mailing all addresses they can find related to an address upto and including hostmaster@ripe.net. MarcoH
MarcoH wrote:
On Tue, Jan 13, 2004 at 11:52:04AM +0100, Ulrich Kiermayr wrote:
Hi *,
Im not sure why it should be multiple? But I think most of us on this list can agree with you that a valid abuse email address associated with each inetnum in the database would be very welcome.
Just a stupid question: how do you assure the address is valid in the first place, and after that stays valid, i.e. there is a human behind it reading it? (without putting additional workload on the NCC manual validating all of these)
Let's just limit it to be syntactically correct accoording to whatever the rfc at that moment specify as 'syntactically correct'.
There is no other way of ensuring that it's valid on a certain moment. There is still some form of 'trust' involved as to the point that the LIR inserting the address takes abuse serious. And I hope the majority still does, so the system would work and people don't have to use other things like mailing all addresses they can find related to an address upto and including hostmaster@ripe.net.
Sorry to be picky, but I still do not get it: then what is the advantage of abuse-c: abuse@here.there.nl over remarks: abuse-c: abuse@here.there.nl as you stated trust is required and you can't ensure anything; so having it mandatory is basically worthless, because someone who has to fill in something but does not want to will put in trash_my_abuse@hotmail.com, which is also perfectly valid, but does not buy you anything either. And for having a usable, maintainable automated system, it is easier to take what is there (IRT is not really hard to figure out - it _is_ basically like a maintainer), and write the apprpriate tools for that; since you would have to write tools anyway. I hope that makes sense. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On Tue, Jan 13, 2004 at 12:27:58PM +0100, Ulrich Kiermayr wrote:
Let's just limit it to be syntactically correct accoording to whatever the rfc at that moment specify as 'syntactically correct'.
There is no other way of ensuring that it's valid on a certain moment. There is still some form of 'trust' involved as to the point that the LIR inserting the address takes abuse serious. And I hope the majority still does, so the system would work and people don't have to use other things like mailing all addresses they can find related to an address upto and including hostmaster@ripe.net.
Sorry to be picky, but I still do not get it: then what is the advantage of
abuse-c: abuse@here.there.nl
over
remarks: abuse-c: abuse@here.there.nl
You can't enforce the second form, it will become BCP and you will end up with the same situation as the irt objects.
as you stated trust is required and you can't ensure anything; so having it mandatory is basically worthless, because someone who has to fill in something but does not want to will put in trash_my_abuse@hotmail.com, which is also perfectly valid, but does not buy you anything either.
And for having a usable, maintainable automated system, it is easier to take what is there (IRT is not really hard to figure out - it _is_ basically like a maintainer), and write the apprpriate tools for that; since you would have to write tools anyway.
I hope that makes sense.
It makes sense, but I have the feeling that the irt carries to much information or is to difficult for the average database user to use. That's why I proposed the alternative of creating more awarness of the irt object, what it does and how to use it, especially from the perspective of the bulk of the database users who just want some basic information on where to complain about a certain ip address. I don't know how others handle this, but the company I work for has some seperation between 'security' and 'abuse'. The irt object will probably point to our security department who handle the more serious incidents or things which need a fast response. Our abuse dept only works during office hours but takes care of all spammers, virusses and other stuff as from experience most of the spam is done batchwise mostly the damage is already done and the only thing the abuse dept does is taking care it won't happen again by disconneting the user and make sure they fix their security holes. The irt object doesn't allow for this seperation, you can create multiple objects and use remarks to explain where to send the complaint. This is the mechanism we already use on the inetnum and it doesn't work very well. MarcoH
And for having a usable, maintainable automated system, it is easier to take what is there (IRT is not really hard to figure out - it _is_ basically like a maintainer), and write the apprpriate tools for that; since you would have to write tools anyway.
I hope that makes sense.
It makes sense, but I have the feeling that the irt carries to much information or is to difficult for the average database user to use.
I would very much like a solution to this problem so if more LIRs would be willing to accept modifying the current irt object I could support some kind of compromise. The current irt object template: irt: [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The following is a modified version: abuse [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] encryption: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The name: abuse is a much more common word, I don't really see the point in using a word that most normal user doesn't understand and maybe even some LIRs. I don't think physical address is strictly necessary since people only look for an email address, on the other hand its no bother to insert it.. (btw. shouldn't country be included as mandatory if address is included?) Signature and Encryption has to be optional, I only see a point with these attributes in case abuse is handled by a different department. Im sure other LIRs exists who doesn't need this. admin-c and tech-c, email is mandatory on role object = a mail address totally irrelevant to abuse/irt will show up if these attributes are included meaning people will send to these as well = back to square one. It doesn't help making them optional as I see it..? I don't see the reason for auth? If its absolutely necessary it can be optional. As it is now it should still be referenced from inetnum objects. The disadvantage is that all LIRs have to modify each and everyone of their inetnum objects, and this object will not have much value until all inetnums have been updated.. This is where the idea of having it in the maintainer object has its advantage.
That's why I proposed the alternative of creating more awarness of the irt object, what it does and how to use it, especially from the perspective of the bulk of the database users who just want some basic information on where to complain about a certain ip address.
I don't know how others handle this, but the company I work for has some seperation between 'security' and 'abuse'. The irt object will probably point to our security department who handle the more serious incidents or things which need a fast response. Our abuse dept only works during office hours but takes care of all spammers, virusses and other stuff as from experience most of the spam is done batchwise mostly the damage is already done and the only thing the abuse dept does is taking care it won't happen again by disconneting the user and make sure they fix their security holes.
The irt object doesn't allow for this seperation, you can create multiple objects and use remarks to explain where to send the complaint. This is the mechanism we already use on the inetnum and it doesn't work very well.
Im not sure its possible to solve this without getting into problems like people using the wrong address anyway. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Tue, Jan 13, 2004 at 01:47:32PM +0100, Christian Rasmussen wrote:
I would very much like a solution to this problem so if more LIRs would be willing to accept modifying the current irt object I could support some kind of compromise. The current irt object template:
The name: abuse is a much more common word, I don't really see the point in using a word that most normal user doesn't understand and maybe even some LIRs.
See my earlier messages on seperation of tasks and responsibilities in larger companies and the fact that the irt object carries a lot of information where the user is only looking for 1 single email address. Renaming it to abuse might help, but you still need to get people aware of the existence of the irt object (or whatever we decide to rename it to) and get the pulbic, both LIRs and complainers, to start using it. Part of this also needs to be done when we decide on adding an attribute to an existing object, but my point on seperation stays. Who forms our 'incident resposne team' depends on the type of incident. Large scale hacking/cracking and collecting evidence is handled by other people and with higher priority (24x7) as a normal "I got this unwanted email and I can't read headers so it's all your fault" type of complained which get handled by another department and only during office hours. So either we have to create multiple irt objects and use remarks to point people which one to use or we have to join the departments. For the last one, we can also decide to join abuse, security, network engineering, hostmasters and the people operating the LIR in one department and replace each and every ip-address in the ripe database to only contain abuse@isp. I think it's clear that is not very likely to happen and the database is not meant for this. Hence the seperation between admin-c, tech-c, mntner and irt. And in my opnion in this seperation we missed out on the part which handles the average abuse complaints coming from not very cluefull users. If they had any clue they would have found the correct address and not mailed the address in the changed: attribute. Being techies we designed a beautifull thing called the irt object, but we missed out on 90% of the users not even speak english and understand all the remarks and database documentation. The simple term 'abuse' is widely accepted and understood. I want something similar to the usenet X-Complaints-To: header. We might for simplicity even call it complaints-to: instead of abuse: MarcoH
There is no other way of ensuring that it's valid on a certain moment. There is still some form of 'trust' involved as to the point that the LIR inserting the address takes abuse serious. And I hope the majority still does, so the system would work and people don't have to use other things like mailing all addresses they can find related to an address upto and including hostmaster@ripe.net.
Sorry to be picky, but I still do not get it: then what is the advantage of
abuse-c: abuse@here.there.nl
over
remarks: abuse-c: abuse@here.there.nl
as you stated trust is required and you can't ensure anything; so having it mandatory is basically worthless, because someone who has to fill in something but does not want to will put in trash_my_abuse@hotmail.com, which is also perfectly valid, but does not buy you anything either.
And for having a usable, maintainable automated system, it is easier to take what is there (IRT is not really hard to figure out - it _is_ basically like a maintainer), and write the apprpriate tools for that; since you would have to write tools anyway.
Personally I don't see the need for trust, Im sure we can all agree that no one but the LIR can enter the abuse address information (one way or the other), so the question is if any LIRs could want to falsefy an abuse address on their own inetnum object?! This is the reason why some of you keep talking about the need for trust, correct? If some LIRs need some kind of trust in order to avoid this I would suggest (as done before) that the abuse mail address is checked when creating a maintainer object. By checked I mean that Ripe NCC sends a mail to the mail address and wait for a reply before creating the maintainer object, this can actually be done with software so I don't think it will be a big burden on Ripe NCC. If this is not enough, if some LIRs fear that the LIRs in question would try to do an update and this way insert an invalid email address Im sure it wouldn't be a problem repeating the check procedure. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Tue, Jan 13, 2004 at 12:51:28PM +0100, Christian Rasmussen wrote:
If some LIRs need some kind of trust in order to avoid this I would suggest (as done before) that the abuse mail address is checked when creating a maintainer object. By checked I mean that Ripe NCC sends a mail to the mail address and wait for a reply before creating the maintainer object, this can actually be done with software so I don't think it will be a big burden on Ripe NCC. If this is not enough, if some LIRs fear that the LIRs in question would try to do an update and this way insert an invalid email address Im sure it wouldn't be a problem repeating the check procedure.
This is useless other then some verification that on the time of creation somebody replied to one mail sent to that specific address. Unless you design an audit procedure to check the validity and response of the address at random intervals it doesn't add anything to check it on creation time except for extra time as the system waits for your reply. Let's keep it at running a syntax check... MarcoH
Hi Marco,
If some LIRs need some kind of trust in order to avoid this I would suggest (as done before) that the abuse mail address is checked when creating a maintainer object. By checked I mean that Ripe NCC sends a mail to the mail address and wait for a reply before creating the maintainer object, this can actually be done with software so I don't think it will be a big burden on Ripe NCC. If this is not enough, if some LIRs fear that the LIRs in question would try to do an update and this way insert an invalid email address Im sure it wouldn't be a problem repeating the check procedure.
This is useless other then some verification that on the time of creation somebody replied to one mail sent to that specific address. Unless you design an audit procedure to check the validity and response of the address at random intervals it doesn't add anything to check it on creation time except for extra time as the system waits for your reply.
Why do you say that its useless? As I understand some LIRs fear that invalid email addresses might be entered, if so, the above procedure will not approve willnotwork@domain while a syntax check will. As I said, the email address can be checked again if its changed - this way we can make sure that only valid email addresses received by the LIR are entered. What more do you want? But this will of course not say anything about general response time or if all other mails to the address is simply ignored.. But isn't that a completely different story?
Let's keep it at running a syntax check...
Why? Whats the disadvantage of the above procedure? It might require some ressources from Ripe NCC but I would say thats reasonable considering you will this way be sure email addresses entered are all valid. At least I would prefer this compared to keeping the current system because some might argue that the system discussed is not trustworthy. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Tue, Jan 13, 2004 at 03:38:43PM +0100, Christian Rasmussen wrote:
This is useless other then some verification that on the time of creation somebody replied to one mail sent to that specific address. Unless you design an audit procedure to check the validity and response of the address at random intervals it doesn't add anything to check it on creation time except for extra time as the system waits for your reply.
Why do you say that its useless? As I understand some LIRs fear that invalid email addresses might be entered, if so, the above procedure will not approve willnotwork@domain while a syntax check will.
As I said, the email address can be checked again if its changed - this way we can make sure that only valid email addresses received by the LIR are entered. What more do you want?
That the database user can 'trust' the LIR to actually respond to emails send to that address and not only when they change something and they have to respond to the test message sent by ripe. Furthermore I still support the idea of abuse: being an attribute on either inet(6)num or mntner, with inetnum taking precedence over mntner. That means that with the verification method you propose the creation and updates of inetnum object depends on the speed my collegeaus from the abuse department handle their mail. So one or two customers sourcing a spam run can prevent me from keeping the database up-to-date.
But this will of course not say anything about general response time or if all other mails to the address is simply ignored.. But isn't that a completely different story?
It is, so you propose to add extra overhead without gaining anything from a user perspective other than that at some point in time somebody responded to 1 email.
Let's keep it at running a syntax check...
Why? Whats the disadvantage of the above procedure? It might require some ressources from Ripe NCC but I would say thats reasonable considering you will this way be sure email addresses entered are all valid. At least I would prefer this compared to keeping the current system because some might argue that the system discussed is not trustworthy.
You add resources without benifit. Basic economics apply, adding cost which doesn't increase your revenue is not a smart thing to do. Grtx, MarcoH
Hi Marco, Okay, I think I now understand better what you mean. There are different levels of check of entered abuse address: 1. Nothing 2. Syntax check 3. Address validity check (as previously described) 4. Response time check I very much disagree with you that level 3 should be worthless, I think its about as good as it can realistic be. How do you propose level 4 should be accomplished without in some way costing ressources (considerably more than level 3)? If you want audit on LIRs then abuse is probably not the only thing which should be thoroughly checked. Also, what would you do in case some LIRs choose not to respond to abuse complaints? I also still support the proposed idea with abuse address in inetnum/maintainer, but if the argument against is the lack of trust I think a level 3 check would solve the problem. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
-----Original Message----- From: MarcoH [mailto:marcoh@marcoh.net] Sent: 13. januar 2004 15:53 To: Christian Rasmussen Cc: Ulrich Kiermayr; Sebastian Abt; db-wg@ripe.net Subject: Re: [db-wg] abuse-c
This is useless other then some verification that on the time of creation somebody replied to one mail sent to that specific address. Unless you design an audit procedure to check the validity and response of the address at random intervals it doesn't add anything to check it on creation time except for extra time as the system waits for your reply.
Why do you say that its useless? As I understand some LIRs fear
On Tue, Jan 13, 2004 at 03:38:43PM +0100, Christian Rasmussen wrote: that invalid
email addresses might be entered, if so, the above procedure will not approve willnotwork@domain while a syntax check will.
As I said, the email address can be checked again if its changed - this way we can make sure that only valid email addresses received by the LIR are entered. What more do you want?
That the database user can 'trust' the LIR to actually respond to emails send to that address and not only when they change something and they have to respond to the test message sent by ripe.
Furthermore I still support the idea of abuse: being an attribute on either inet(6)num or mntner, with inetnum taking precedence over mntner. That means that with the verification method you propose the creation and updates of inetnum object depends on the speed my collegeaus from the abuse department handle their mail. So one or two customers sourcing a spam run can prevent me from keeping the database up-to-date.
But this will of course not say anything about general response time or if all other mails to the address is simply ignored.. But isn't that a completely different story?
It is, so you propose to add extra overhead without gaining anything from a user perspective other than that at some point in time somebody responded to 1 email.
Let's keep it at running a syntax check...
Why? Whats the disadvantage of the above procedure? It might require some ressources from Ripe NCC but I would say thats reasonable considering you will this way be sure email addresses entered are all valid. At least I would prefer this compared to keeping the current system because some might argue that the system discussed is not trustworthy.
You add resources without benifit. Basic economics apply, adding cost which doesn't increase your revenue is not a smart thing to do.
Grtx,
MarcoH
On Tue, Jan 13, 2004 at 04:14:13PM +0100, Christian Rasmussen wrote:
Hi Marco,
Okay, I think I now understand better what you mean. There are different levels of check of entered abuse address:
1. Nothing 2. Syntax check 3. Address validity check (as previously described) 4. Response time check
level 4 would be to run random audits on the information present in the database. Response time will only influence the time it takes to create or update an object I never suggested on testing it, it's just a side effect on level 3.
I very much disagree with you that level 3 should be worthless, I think its about as good as it can realistic be.
How do you propose level 4 should be accomplished without in some way costing ressources (considerably more than level 3)?
If you want audit on LIRs then abuse is probably not the only thing which should be thoroughly checked. Also, what would you do in case some LIRs choose not to respond to abuse complaints?
I also still support the proposed idea with abuse address in inetnum/maintainer, but if the argument against is the lack of trust I think a level 3 check would solve the problem.
Level 3 only checks the situation at the time of insertion it is in no way a guarantee to the user that it's still working when he retrieves the information and as such doesn't add much to just do a syntax check on the attribute. Grtx, MarcoH
* Ulrich Kiermayr <ulrich.kiermayr@univie.ac.at> wrote:
Just a stupid question: how do you assure the address is valid in the first place, and after that stays valid, i.e. there is a human behind it reading it? (without putting additional workload on the NCC manual validating all of these)
That's exactly the point why I think that we don't need any other kind of validation than syntax validation. Every LIR should be interested in taking care about abuse complaints (doesn't matter which kind of abuse). If one doesn't, addressing this on public mailing lists or adjusting filters helps a lot. sebastian -- whois: sabt-ripe - phone: +49 (0)160 90759764 email: sabt@sabt.net - pgp-pubkey: 0xD008DA9C
In message <20040113172959.226da92f.sabt@sabt.net>, Sebastian Abt writes:
* Ulrich Kiermayr <ulrich.kiermayr@univie.ac.at> wrote:
Just a stupid question: how do you assure the address is valid in the first place, and after that stays valid, i.e. there is a human behind it reading it? (without putting additional workload on the NCC manual validating all of these)
That's exactly the point why I think that we don't need any other kind of validation than syntax validation. Every LIR should be interested in taking care about abuse complaints (doesn't matter which kind of abuse). If one doesn't, addressing this on public mailing lists or adjusting filters helps a lot.
It seems to me that a lot of the discussions we see on the ripe lists suffer from the same basic confusion between "tools" and "best practice". In this case the addition or non-addition of the "abuse-c" field is a tool issue. What people fill in the field if we add it, and how they react to what gets sent there, that is "best practice" issues. I seem to recall from the past that we can resolve and decide on tools issues, and that we get nothing but endless supplies of fingerpointing and pulpitpounding emails when we discuss "best practice" issues. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Hi Christian, * "Christian Rasmussen" <chr@jay.net> wrote:
Okay, this was discussed yesterday and we talked about a combination of what Daniel Karrenberg suggested and the above, meaning you just add an optional abuse attribute to the inetnum objects, if its not added the abuse address will "default" to the abuse address of the maintainer object. Wouldn't this work for you?
Yes, of course, that would be pretty okay.
Im not sure why it should be multiple? But I think most of us on this list can agree with you that a valid abuse email address associated with each inetnum in the database would be very welcome.
That's quite simple: I'd like to insert my customers abuse desk as well as my own abuse desk to at least keep track of any incidents. regards, sebastian -- whois: sabt-ripe - phone: +49 (0)160 90759764 email: sabt@sabt.net - pgp-pubkey: 0xD008DA9C
On Tue, Jan 13, 2004 at 05:11:18PM +0100, Sebastian Abt wrote:
Im not sure why it should be multiple? But I think most of us on this list can agree with you that a valid abuse email address associated with each inetnum in the database would be very welcome.
That's quite simple: I'd like to insert my customers abuse desk as well as my own abuse desk to at least keep track of any incidents.
So we end up with extending the inet(6)num template to include: abuse: [optional] [multiple] Extend mntner template with: abuse: [mandatory] [multiple] And possibly modify the database software to always list the abuse: field when not present on the inetnum resolve the mnt-by: and include the information in the inetnum response. The user will always find at least one abuse: line (or whatever we decide to call it) directly on the inet(6)num. The only thing we need then is to come up with a default on the mandatory field. I hereby suggest to copy them from the (mandatory) upd-to attributes. This will probably get people to update their mntner to include the correct information in short time. MarcoH
* MarcoH <marcoh@marcoh.net> wrote:
Extend mntner template with:
abuse: [mandatory] [multiple]
I think abuse: [mandatory] [single] would work for the mntner object, because I'll never add a customers' abuse desk as general fallback address and I don't see an other reason for multiple abuse contacts than being able to track complaints and see whether my customer's careful with resolving these complaints. sebastian -- whois: sabt-ripe - phone: +49 (0)160 90759764 email: sabt@sabt.net - pgp-pubkey: 0xD008DA9C
Hi,
On Tue, Jan 13, 2004 at 05:11:18PM +0100, Sebastian Abt wrote:
Im not sure why it should be multiple? But I think most of us on this list can agree with you that a valid abuse email address associated with each inetnum in the database would be very welcome.
That's quite simple: I'd like to insert my customers abuse desk as well as my own abuse desk to at least keep track of any incidents.
Actually I kind of have the same need!.. :) But my idea would be to insert our abuse address in the maintainer so it defaults to this one, and then insert customer (more specific) abuse address in the inetnum.. The only reason I can see for inserting multiple abuse addresses in the inetnum object would be if you, beside a customer abuse address, need to override the address in the maintainer... If some LIRs have this need then we of course need to make the abuse attribute in the inetnum multiple.
So we end up with extending the inet(6)num template to include:
abuse: [optional] [multiple]
Extend mntner template with:
abuse: [mandatory] [multiple]
hm.. again, why multiple in the maintainer?
And possibly modify the database software to always list the abuse: field when not present on the inetnum resolve the mnt-by: and include the information in the inetnum response.
The user will always find at least one abuse: line (or whatever we decide to call it) directly on the inet(6)num.
The only thing we need then is to come up with a default on the mandatory field. I hereby suggest to copy them from the (mandatory) upd-to attributes. This will probably get people to update their mntner to include the correct information in short time.
Yes, upd-to might be a good idea to copy, still it would be a good idea if Ripe NCC performs periodically checks and informs the LIRs who haven't updated their maintainer until a certain percentage has been reached. Aside from my comments above I fully support this. Do we now have something which a larger group could support?? Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Jan 14, Christian Rasmussen <chr@jay.net> wrote:
Actually I kind of have the same need!.. :) But my idea would be to insert our abuse address in the maintainer so it defaults to this one, and then insert customer (more specific) abuse address in the inetnum.. The only If the problem is lusers who cannot choose the right address to send complaints to, then this is way too hard for them and is not a solution. Looks like we need to discuss again the requirements...
Extend mntner template with:
abuse: [mandatory] [multiple] I think many people already explained why making this mandatory would be too hard and not really useful.
Aside from my comments above I fully support this. Do we now have something which a larger group could support?? I'm not sure. I think that so far nobody disagreed with the proposal to return IRT objects by default for inetnum and inet6num queries, which has the advantages of using what is already available and probably being easy to implement. OTOH, the RIPE DB people have not explained us yet if this is feasible.
-- ciao, | Marco | [4094 coeYUCAGphQow]
Hi Marco, Im a bit confused.. Yesterday you did yourself suggest that abuse in the maintainer should be mandatory:
Extend mntner template with:
abuse: [mandatory] [multiple]
And now you say this doesn't work?? Or am I missing something?? If an abuse address isn't made mandatory then realistically the majority of LIRs will not enter an abuse address, meaning users will not trust this information and keep sending complaints to all addresses = no good. You also suggested in that mail to copy upd-to into the abuse attribute, which I also think is a good idea. You argue why multiple abuse addresses is necessary in inetnum objects, Im not sure I understand what you mean, you're saying it will be way to hard for users to choose the correct address if its single = only 1 mail address..?? Anyway, if multiple addresses are required by some LIRs then we of course need to do it this way, I just don't see a reason for making anything multiple unless there is a clearly defined need. This abuse-suggestion should benefit all LIRs so I would hope to hear some comments from other LIRs since it will also affect all LIRs if we come to an agreement. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]On Behalf Of Marco d'Itri Sent: 14. januar 2004 12:55 To: db-wg@ripe.net Subject: Re: [db-wg] abuse-c
On Jan 14, Christian Rasmussen <chr@jay.net> wrote:
Actually I kind of have the same need!.. :) But my idea would be to insert our abuse address in the maintainer so it defaults to this one, and then insert customer (more specific) abuse address in the inetnum.. The only If the problem is lusers who cannot choose the right address to send complaints to, then this is way too hard for them and is not a solution. Looks like we need to discuss again the requirements...
Extend mntner template with:
abuse: [mandatory] [multiple] I think many people already explained why making this mandatory would be too hard and not really useful.
Aside from my comments above I fully support this. Do we now have something which a larger group could support?? I'm not sure. I think that so far nobody disagreed with the proposal to return IRT objects by default for inetnum and inet6num queries, which has the advantages of using what is already available and probably being easy to implement. OTOH, the RIPE DB people have not explained us yet if this is feasible.
-- ciao, | Marco | [4094 coeYUCAGphQow]
participants (8)
-
Christian Rasmussen -
Christoph Mohr -
Marco d'Itri -
MarcoH -
Poul-Henning Kamp -
Rev Adrian Kennard -
Sebastian Abt -
Ulrich Kiermayr