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@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