Search RPD Archives
[AfriNIC-rpd] abuse contact information in whois database (AFPUB-2010-GEN-002)
Tobias Knecht
tk at abusix.com
Thu Jun 17 02:05:20 UTC 2010
>> This is not a problem of this proposal. This is a problem of the over
>> all situation at RIRs. We are having the problem of not having dedicated
>> abuse mailboxes, we are having the problem of data accuracy, we are
>> having the problem of complicated ways of parsing and finding abuse
>> contacts.
>>
> No, this is a problem of human nature, education, and experience.
>
> Human nature is that rather than follow the proper prescribed process
> and sending automatic abuse reports to automated-abuse-c and sending
> personal reports to personal-abuse-c, what usually happens instead is
> that both forms of abuse reports go to:
>
> admin-c
> tech-c
> every-other-c
> abuse-c
> parent-admin-c
> parent-tech-c
> parent-abuse-c
> parent-every-other-c
> parents-parent-admin-c
> etc.
I think you forgot the most distinctive nature of human beings: Laziness.
Okay look at it that way. If AfriNIC would offer a service, where I
could put in a ip address and get back the abuse contact e-mail address,
why should I start doing painful and really ugly whois queries to send
this stuff to more than the mentioned receiver?
A service that is build to solve their problems, telling them, that is
the only way to report abusive behavior will educate them.
> The education problem comes in the form of the majority of the people
> that exhibit the above behavior do so out of ignorance because they
> have not been taught and do not bother to educate themselves on
> the proper way to go about reporting abuse.
If there are stupid people outside sending the reports to 15 people,
block them. Easy. Same problem today, nothing new, so not really an
issue of an abuse contact information proposal.
> The experience problem comes from the fact that less than stellar
> behavior from some providers in response to proper abuse reporting
> has created anecdotal evidence and experience-based perception
> that it is more effective to shotgun everyone with your abuse report.
I fully agree, but this is a current problem as well. So my proposal is
not changing this. It is making it better, because you can educate
people and/or offer services that count on their laziness.
>> These are all self made problems.
>>
> To some extent, perhaps. However, to a much larger extent, these
> are problems collectively made by the systemic application of
> human nature to imperfect systems built by humans.
Right. A perfect system is easy to use and does what it was intended
for. At the moment no RIR is having such a system in regard of abuse
contact information. That is not bad, that is the reason we are here for.
>> This is not the last proposal you will see from us, because we want to
>> change something.
>>
> I have no doubt of that.
That sounds kind of reproachful. ;-)
>> The problem you described would not exist, if RIRs would have mandatory
>> abuse contacts in their whois, offering these in an easy to use DNS
>> based service, where everybody could ask for the right contact
>> information and shutting restricting queries more and more, so only real
>> messages will be sent to the personal accounts of the abuse desks.
>>
> On this we will probably need to agree to disagree completely and
> vigorously.
> I don't see any way in which mandatory abuse contacts in whois will change
> the human nature problem, the educational problem, or even the experience-
> based problem I described.
Laziness and some filter rules does.
And even if not. There are hundreds of people out there waiting for such
a solution to use it in an appropriate way. Don't destroy their hope
because we can not get rid of the stupid ones.
> I do see several ways in which having an available field for an abuse
> contact
> can in part help the situation. I don't see significant benefit to making it
> mandatory, and, I do see a few potential downsides.
Okay. How about that?
We are not making it mandatory, BUT in our next proposal about an easy
to use query service we decide, that if there is no dedicated abuse
address given we use the tech-c address instead.
That way we would have a chance to report stuff to a person which might
be responsible for the issues and probably get their attention and
"push" them to create one, if they do not want to receive the reports on
their personal accounts.
Sounds more like a possible plan?
>> That is exactly the way we want to go down. But we should start
>> somewhere. And the problem that generates most pain at RIR members are
>> the not existing abuse contact objects at the moment.
>>
> I guess that depends on who you consider to be the RIR member. I think
> what you are describing is the thing that causes the most pain at the
> abuse reporter side. I would posit that most RIR members are actually
> abuse report recipients rather than abuse report generators.
And why is that the reason? Because it is too complicated. German
Government is mentioning the Abuse Contact Database by abusix as the way
to go and use for reporting. It's beta and it is not nearly perfect at
the moment, but it is better than anything else. The queries against
this list are increasing every day and even other big anti-spam projects
are using this data for reporting issues today.
>> The problem you described is absolutely real, but it is already today
>> and not a problem of this proposal. So let talk about a dedicated abuse
>> contact object and talk later about the other problem.
>>
> You brought up the recommendation of separate abuse contacts for
> automated vs. personal abuse reports. I responded to that subject.
Yes that is exactly what I and many others would like to have, but the
problem you described is not linked directly with this approach. This
problem already exists and is nor showing up as soon as our proposal
will be implemented.
>> This would work. Absolutely.
>> If this is the solution AfriNIC members can live with, fine. I would
>> suggest adding the abuse mailbox field and the RIPE equivalent "whois
>> -b" option for short data output and unrestricted query access.
>>
> I'm not sure what you mean by adding the abuse mailbox field. Each
> contact object has a required "Email" field. For example,
> OD19-ARIN expands to:
RIPE for example is using a special abuse-mailbox attribute, which is
mentioned to be the mailbox for automatic complaints, while the e-mail
field is for personal contact between abuse departments.
whois -B -h whois.ripe.net AFI5-RIPE
person: Axel Fischer
address: 1&1 Internet AG
address: Brauerstr. 48
address: D-76135 Karlsruhe
phone: +49 721 91374 0
e-mail: axel.fischer at oneandone.net
nic-hdl: AFI5-RIPE
notify: ripe-role at oneandone.net
abuse-mailbox: abuse at oneandone.net
mnt-by: AS8560-MNT
changed: axel.fischer at oneandone.net 20070813
changed: ripe-role at oneandone.net 20090514
source: RIPE
>> Restrict abuse-c to one object. Instead we are running in the same
>> problem than RIPE a few years ago.
>>
> Again, I'm not sure what you mean by this. Do you mean a record should
> have exactly one abuse-c or do you mean that abuse-c should only appear
> in number resource records and not org records, or what?
Each inet(6)num and as-num can only have one abuse-c. Which should be a
role-account, which should have the abuse-mailbox attribute and should
not have any further admin-c or tech-c or org stuff in there.
Changed example:
inetnum: 212.227.126.0 - 212.227.126.127
netname: SCHLUND-NET
descr: 1&1 Internet AG
country: DE
admin-c: IPAD-RIPE
tech-c: IPOP-RIPE
abuse-c: XXXX-RIPE <----
status: ASSIGNED PA
notify: ripe-role at oneandone.net
mnt-by: AS8560-MNT
changed: ncc at schlund.net 20040611
changed: ripe-role at oneandone.net 20090528
source: RIPE
role: IP Administration
[...]
role: IP Operations
[...]
role: Abuse Department
address: 1&1 Internet AG
e-mail: personal_abuse at oneandone.net
nic-hdl: XXXX-RIPE
abuse-mailbox: automatic_abuse at oneandone.net
mnt-by: AS8560-MNT
[...]
That would be a good step. The only problem here is, that the
abuse-mailbox attribute can be part of every object (role,org,person,
...) which gives the opportunity that it appears more than once and in
the worst case with different addresses.
Is that understandable? I'm not sure, It's 4 o'clock in the morning ;-)
>> The problem is, that at the moment there is no easy way to query
>> different whois servers and get the right answer, so everybody is doing
>> it a little bit different and that is the problem.
>>
> OK, but, this isn't the problem of the data structure. It is a problem
> of the
> available UI to retrieve the data. You are proposing a change to the
> structure of the data to address a problem with the UI. I agree that
> there is a need for resolving your UI problem, but, I don't agree that
> such a change to the underlying data structure is needed, nor do I see
> doing so as a particularly reliable way to achieve the UI change that you
> seek.
At AfriNIC it's an UI thing, that may be right. At RIPE it is a
structural problem, to much choices for the same thing. That is exactly
what I want to avoid here.
That was the reason for the IRT and the mandatory abuse-mailbox in the
IRT. With usual objects we are getting into the problem of having
different abuse-mailbox attributes in different objects.
>> There is the need to have a standardized way of searching and finding
>> the right information.
>>
> Agreed, however, that is a UI question...
Not only. This is a service questions as well.
>> That is another point that is pointing to the IRT Object. ;-)
>>
> And this is a data structure change, not necessarily a UI change.
Right.
>>>> But I think we can go down another road with issue. If we can not find
>>>> consensus on the IRT Object and are not able to stop the query
>>>> restrictions, I would propose to start a service like this:
>>>> http://labs.ripe.net/content/updated-heuristics-abuse-finder-service
>>>>
>>> That seems fairly reasonable and I suspect would be relatively trivial
>>> to implement.
>>
>> As mentioned above. Mandatory abuse contact : DNS based abuse contact DB
>> : setting up a local DNS cache : all good.
>>
> Yeah, not so convinced on that. I think that optional abuse contacts added
> to whois with provisions for relaxed whois query rate limits where needed
> is a viable alternative. I still don't see the case for making abuse contact
> mandatory, and, I really don't think that DNS is the right place to
> store the
> abuse contact information.
Not storing. Store everything in the whois database. That is perfect and
offer a way to query it via whois. No question about that. The DNS based
query system is just the easy to use "frontend".
Additional create a file once a day, which looks like this:
<cidr-range>:<a-record>:<txt-record>
212.227.0.0/16:127.0.0.1:abuse at oneandone.net
[...]
http://www.corpit.ru/mjt/rbldnsd.html
And offer this as an rbldnsd on maybe 2 dedicated servers at every RIR.
Reporter could use it like this:
$ host -t any 5.126.227.212.abuse-contacts.abusix.org
5.126.227.212.abuse-contacts.abusix.org has address 127.0.0.2
5.126.227.212.abuse-contacts.abusix.org descriptive text
"abuse at oneandone.net"
Easy, isn't it?
RBLDNSD is scalable, reliable, robust and used bullet proof for years by
nearly every blacklist provider.
Merging different zones, without putting them into one file would help
to solve the issue with a few RIRs having their own file.
>> That would make things easy and stops thousands of different ways to
>> do it.
>>
> Now, you are dreaming. It _MIGHT_ provide one consistent way you can
> depend on, but, others will continue to use other methods.
That way is that easy, that most of the people will use it. It is easy
for RIRs to implement. It is easy to deploy and publish and it is easy
to query.
>>>>>> So in my opinion there is a need of unrestricted query access.
>>>>>>
>>>>> We can, perhaps, agree to disagree on this. To me, it sounds like a
>>>>> problem
>>>>> of application optimization which I would argue should not be used
>>>>> to place
>>>>> additional undue burden on the RIR whois services.
>>>>
>>>> Okay lets agree on that. ;-)
>>>>
>>> Fair enough. Increasing the query rate limits or placing finer
>>> granularity
>>> on them, btw, is not necessarily a bad idea in my opinion. Allowing you
>>> to sign up an address for a higher query rate service with a signed
>>> contract containing an AUP specifying you won't be harvesting the
>>> data for unapproved purposes would also be a reasonable alternative.
>>
>> DNS Based list for everybody?
>>
> Certainly would not be my first choice.
Even not after I clarified it a bit?
Thanks,
Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20100617/c5455d43/attachment.sig>
More information about the RPD
mailing list