Keyboard Shortcuts
Thread View
j
: Next unread messagek
: Previous unread messagej a
: Jump to all threadsj l
: Jump to MailingList overview
Re: [sig-policy] prop-079: Abuse contact information (abuse-c)

On 29/01/10 23:04, Mark Foster wrote:
- Mail directed to an inappropriate POC. --- Obviously organisations need to get on-the-ball and create relevant role-objects or somesuch, must admit my limited interaction with the APNIC systems in this space means i don't have a full understanding of this; can the abuse-c point to a set of contact details that don't, in the end, drop to a nic-handle (i.e. an individual) ? So a role object can include a 'group' contact detail?
A role object looks like: role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] As you can see, both admin-c and tech-c are required. So while someone looking to obtain abuse-c contact details could be presented with a role object, there's nothing stopping them looking up the admin-c and tech-c attributes of that role object, which may well end up being individual person objects, and using those contact details as well (or instead). Indeed, I suspect that many people looking to obtain abuse-c contact details will likely continue to do this...
One of my pet peeves is whois data that contains invalid details. Just yesterday I found yet-another-ISP with details listed by APNIC specifically for 'abuse' purposes, where the mailbox concerned didn't actually exist. I was forced to revert to a scattergun on some 'likely guesses'.
...and not necessarily because the email address in the abuse-c role object doesn't work. I have seen abuse complaints sent to any address associated (directly or indirectly) with an inetnum object, including the admin-cs and tech-cs of the role object that is in turn the admin-c and tech-c for the inetnum. Assuming this policy is implemented, there would now be an obvious place to send abuse reports. However, there would be nothing stopping (perhaps automated?) abuse reports continuing to be sent to to admin-c/tech-c. I have nothing against the goal of this policy, but I'm not sure that the addition of an abuse-c to inetnums, inet6nums, and aut-nums will result in abuse mail no longer being sent to admin-c/tech-cs of those objects. However, I'm more than happy to be proven wrong on that :) -Mike