[anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)

Denis Walker wrote:
> Dear Colleagues,

Dear Dennis,

> There have been many assumption that this issue only concerns members
> who have an LIR Portal account. This is not the case for end user
> assignments. Any solution has to cover all resource Holders who may not
> have access to announcements, tools or features of the LIR Portal. There
> have also been a few references to making judgements based on the
> resource Holder using a ticketing system. Again many end users with a
> single PI prefix may be unlikely to use ticketing systems, but may be
> very active to resolve any complaints about their address space.

RIPE NCC could simply mail them to include an IRT object.

> Even if the information was clear they are usually angry and still think
> sending more emails is good.

Just asking why other mail addresses are still visible to the public ?
Most domain registry give the owner to opportunity to hide their email
addresses, like DENIC does by default.

Contact email addresses are only needed for routing issues or
abuse problems (my opinion, but their might me other reasons
Im not aware of). Simple hide the email of the owner to lower
email harvesting.
Hiding some personal data would be correct according to some
local laws anyway.

> The RIPE NCC only knows the IP addresses where queries to the RIPE
> Database come from and what they queried for. We have no information
> about what type of network it is (fixed, dynamic or whatever) so there
> is no point trying to guess any numbers. We do know we average 80
> queries per second and the IP addresses making the queries are global,
> not only RIPE region addresses. Other than that we can say nothing about
> who is making these queries or why.

Simply compare the IPs you see to dynamic IP list like the PBL from
spamhaus.org

> There is an assumption that making a policy will force resource Holders
> to change data in a short period of time (2 or 3 years). There have been
> many policy, business rule, security and syntax changes over the last 10
> years. Some of the earliest are still not complete. We dropped reference

This could be enforced, when RIPE NCC does not allow object changes
before the LIR fixes wrong or missing syntax of all other objects.

> The RIPE NCC can not delete any information currently stored in
> "remarks:" attributes. This is for the same reason the Abuse Finder tool

But it could present an easy way to fix them via the portal.

> cannot return any information from "remarks:" and we cannot do any bulk
> updates to transfer abuse contacts from remarks into IRT objects. We
> cannot write software to 'understand' remarks. We don't even know what

Why not ?
Anybody who has to parse remarks for abuse contacts has to do it
already ...

> language the remark may be in. Then we can't distinguish between:
> remarks: use this address for spam reports helpdesk at lir.net
> remarks: don't send abuse reports to helpdesk at lir.net use admin at lir.net
> remarks: any complaints sent to helpdesk at lir.net will be ignored

Think about the following:
- the LIR logs in and the portal presents him all object without an IRT
   link and tells him about the needed changes
- when updating the object, the LIR is presented with a list of his
   current IRT objects and he can select one or more
- the portal also presents him an editable field showing the remarks
   when they include an @ sign or/and present an checkbox to simple
   delete them all together

The LIR can then simply copy-paste the text he likes or can select
to delete remakrs all together, select the IRT
object he likes and click "Update", what brings him to the next
object he needs to fix.

Updates could be completed in a couple of hours, even if you
have hundreds of INETNUM object, if the interface is comfortable
enough.

I bet that big LIRs do not use the portal anyway, and update
the RIPE DB with their own database interfaces, it should be
not to complicated to updated thoses interfaces and program
an general and automatic update procedure for them.

> At some point the RIPE NCC can auto generate IRT objects and add the
> email address from existing "abuse-mailbox:" attributes in other
> objects. Then make the appropriate references to this IRT object and
> delete the old "abuse-mailbox:" attributes. No data will be lost doing
> this and the new IRT object will cover the same address space covered by
> the old "abuse-mailbox:" attribute. Then syntax changes can be applied
> to only allow "abuse-mailbox:" attribute in IRT object.

Even easier ...

> It has been suggested the RIPE NCC can regularly check/verify abuse
> contact email addresses. It is very easy to set a filter on incoming
> emails to allow any mail @ripe.net to pass and block all others. So the
> fact that a resource Holder receives our email is no guarantee they will
> receive yours.

Its not interesting, if the abuse contact really receives or even reads
an email, more interesting is, that he supplies everybody with an
abuse address he "wants" to have email too and that it exists.
First: abuse reports will not go to contacts, that have nothing to
        with abuse handling anymore
Second: the owner cannot say, that he did not know about the problems
         he caused, because he received the mail via his own mail
         servers. Its not the problem of the sender, if he decides to
         delete or not to read them.

> For those not familiar with the database structure, note that address
> space is hierarchical. There are just over 3 million INETNUM objects for
> PA assignments. These all relate to the allocations made to about 7000
> members. Each member may have several allocations. From the point of
> view of administrative work load, adding IRT references to the few
> thousand members allocation objects achieves the same result as adding a
> reference to each of the 3 million objects, but is much easier to
> manage. The default query for any address already searches up the

If there is no IRT object for a specific INETNUM, simply present
the next higher IRT object.
This is what people are doing anyway, if there is no email address
at all for the specific INETNUM (f.e. spamcop does this).

> If abuse emails are located in one place the RIPE NCC Abuse Finder tool
> can do direct database lookups at SQL level, bypassing the normal query
> interface. This is much faster and provides real time responses. With a
> published API you can write your own scripts to use this tool.
> Downloadable lists are yesterdays data, but we can look at providing
> such lists if required.

Im still voting for the list, but SQL is nice too ...


Kind regards, Frank
>
> Regards
> Denis Walker
> Business Analyst
> RIPE NCC Database Group
>
>
>

--
PHADE Software - PowerWeb                       http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast             mailto:frank at powerweb.de
Schinkelstrasse 17                                fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany             fax: +49 33200 52921
======================================================================
Public PGP Key available for frank at powerweb.de