Hi Lutz
Good try but this script does not do it. Firstly, if you start with the
allocation object it needs to be -rM in the first query. Then you are only
looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:"
attribute in the object. It may have both in which case the local attribute
overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage
this feature it is not just about producing a list of abuse email addresses. It
is knowing where these are referenced within a hierarchy and knowing which
parts of the hierarchy are covered by which addresses.
I agree that most resources will only have a single abuse contact referenced
from their single ORGANISATION object. However, we were pushed hard by the
community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume
therefore that this feature has been used. So we already have a mix of abuse
contacts referenced from both ORGANISATION and resource objects.
When this was asked for the emphasis was on 'ease of use' to add these
contacts. Probably no one gave much thought to how these contacts will be
cleaned up when no longer relevant. It's most likely that someone will ask
someone to remove it. Knowing human nature it is more likely some will just be
forgotten about. If the contact is still there it is still active, but maybe no
one is reading that email address any longer.
I am not an operator so I don't know how many end user customers in large
networks handle their own abuse reports. Or how many sub allocations handle
abuse with their own customers handling abuse. So I don't know how complex this
will get and maybe all operators already have good procedures in place to
manage all this. That is why I am asking the question...is such a visualisation
tool needed, useful or a waste of time? As an analyst, I can only see how
complex this 'could' become over time.
Unless we go back to the drawing board and redesign the abuse contact system
(again) this is not going to be simplified any time soon.
cheersdenis
co-chair DB-WG
On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg
<db-wg@ripe.net> wrote:
> > We need to take some action on these old NWIs. Either we move forward
> with them or we cancel them. It is difficult to draw a consensus on 2
> comments. Can you please give us a couple of minutes of your time and
> let us know if this NWI-1 is needed, useful or a waste of time.
>
> I share the view already expressed. If we need a tool, maybe the problem
> is somewhere else.
I support any proposal, that comes to the same result as the ripe whois
database tool.
It's not really hard to do correctly.
#! /bin/sh
getripe="whois -h whois.ripe.net --"
$getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do
$getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do
$getripe -r $av | fgrep abuse-mailbox
done
done | tail -1
In order to fix the issue on the database side, it's necessary to prevent any
occurrence of "abuse-mailbox" in all objects beside an newly created
"abuse-contact" type, which is only allowed to referenced in the "abuse-c".
See here for a corner case:
https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C
