[db-wg] abuse-c: proposal

On Thu, Jan 29, 2004 at 05:20:55PM +0100, MarcoH wrote:
> On Thu, Jan 29, 2004 at 08:11:11AM -0800, Steve Atkins wrote:
> > > > Make sure that part of the docs is surrounded by the stuff about where to
> > > > find certain information...if they read the docs, they would also be able
> > > > to figure out that changed: and notify: are not meant as an abuse pointer.
> > > 
> > > They do not read the docs at all.  They parse any ascii that comes back
> > > for something that syntactically looks like and e-mail address.  One way
> > > to stop this might be to identify the tool authors and put as many of
> > > their e-mail addresses as one can find in free text in objects.  ;-)
> > 
> > Some of us read the docs :)
> 
> But do you also implement complaining tools...if that's the case more info
> on how it works would be welcome as is input on the usabillity of the
> database from a 'user' perspective.

Eh. To give you some context on my perspective, I think all currently
deployed automatic spam-complaint tools are deeply flawed. They're too
inaccurate to be widely useful, and cause more problems than benefits
for 7 out of 10 abuse desks. I don't think that's an intrinsic issue,
so much as an implementation issue, though.

(I do have automated spam analysis tools written, and use them internally,
 but don't consider them accurate enough to let loose on Joe SpamCop.)

But I also develop tools for abuse desks to use, so I see a lot of the
database problems both from being a (hopefully) informed user myself
and seeing the deluge of complaints from Joe SpamCop. I'm also
involved with the IRTF antispam research group subgroup on abuse
reporting standards - where a lot of these issues are relevant.

Many of the complaints based on RIR lookups are from people using web
interfaces (like mine) to the whois servers, rather than actual
automated tools. That population certainly doesn't read the docs. Many
(most?)  of the spam complaining users don't really understand the way
the records are put together, and the complexity of person or role
elements. A standard whois query provides them with too much
information, in a hard to understand form - leading to the "email
everything with an @ sign in it" problem.

(And that population is the same population writing automated complaint
 tools - so, you're right, most of those tool authors probably aren't
 even aware there are docs, let alone have read them.)

So, while with my DBA hat on I can see that it's clearly the right thing
to do to have an abuse-c object that points to a role object I don't
think that's optimal in avoiding misaimed abuse reports while still
allowing valid abuse reports to go to an appropriate role.

Providing a direct mailbox to the querying user would improve things
somewhat. i.e. abuse-box: abuse at example.com, or even better a few
different mailboxes abuse-box: spam-box: security-box: to encourage
some level of self-sorting by complainers.

How to provide those is an implementation detail - personally I'd
still have them in the database as abuse-c: pointing at a role
object, but generate a synthetic abuse-box: field from the e-mail
field of the role object pointed at by the abuse-c: field at query
time.

That would improve things somewhat for those on the receiving end
of the other email addresses in a record.

To really improve things, though, the right thing to do is to
discourage people complaining about spam or whatever from using
the RIR whois servers directly. They don't really want to, but
they've learned to do so because that's the best approach available
to someone with minimal tools available.

What would be ideal for them, and would remove many of the issues of
"how do we present data that's useful for the intended technical
audience, but not harmful via the not really intended non-technical
audience" would be to provide an alternate interface that would
hide all the other information.

That would be quite a lot of work for the RIRs to do, but it doesn't
have to be done by them. Given a bulk feed of RIPE data I'd be happy
to republish it via such a heavily stripped down interface. I'm on
first name terms with the maintainers of most of the heavily used web
gateways, automatic lookup and complaint tools, so I suspect I could
convince the majority of them to switch to using that stripped-down
data source.

Cheers,
  Steve