<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1"> <TITLE>RE: [anti-abuse-wg] Abuse Contact Information</TITLE> </HEAD> <BODY>  <TT>Web forms are possibly easier to secure and possibly more reliable way to ensure reports are delivered? Maybe there is a case to have a abuse-webform: type object in the IRT? (perhaps a question for db-wg!) Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood@imerja.com -----Original Message----- From: anti-abuse-wg-admin@ripe.net on behalf of Tobias Knecht Sent: Mon 5/3/2010 11:12 To: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] Abuse Contact Information Hello together, > I like to recommend the following extension to Tobias' proposal: > > I should be noted that access to personal objects via > whois is currently limited, what blocks automated abuse > report generation. > > It is likely that these limits also apply for IRT objects. RIPE Database Query Reference Manual [1] says in chapter "2.12 Access Control for Queries" the following: "The control mechanism is based on the amount of contact information (contained in person and role objects) that is returned because of queries made for an IP address." Is the IRT Object a person or role Object? Is it handled the same way? Are there any restrictions? The other opportunity would be to use the new and really great AbuseFinder API [2] as soon as it is ready to use in production. > I recommend to publish a list of all IRT-objects on RIPEs > ftpserver for mirroring, maybe restricted to RIPE > members only or to explicitly drop all limits for > IRT queries (if somebody is concerned about email harvesting > it should be clear that harvesting will happen anyway via > whois, API or webservice, whatever limits are used). Restricted Access to a file is not the solution. What about non RIPE members like ISPs from the APNIC or ARIN region? Unlimited access to IRT Objects could make sense, but I would like to restrict it a bit more and let's say stop restrictions while using the "-b" flag. That would make 100% sense. That way it would be possible to query the addresses for automatic abuse handling (abuse-mailbox attribute), but secure the e-mail attribute for personal contact. > It should also be noted in the proposal that IRT-objects > have to bereturned also via the whois "-b" option. Over all I think this is something that should be thought about, but nevertheless it is not the main intention of this proposal to change query policies. It's about making the IRT Object mandatory. It's the decision of the community, if this proposal, shall be extended. Thanks, Tobias [1] <A HREF="http://www.ripe.net/db/support/query-reference-manual.pdf">http://www.ripe.net/db/support/query-reference-manual.pdf</A> [2] <A HREF="http://labs.ripe.net/content/abuse-finder">http://labs.ripe.net/content/abuse-finder</A> </TT> Finalist - MicroScope ACEs Awards 2010 Winner - Check Point Endpoint Partner Award 2009 Winner - Institute of Directors NW Ackroyd Award for Corporate Social Responsibility 2009 Finalist - CRN Channel Awards 2009 Finalist - Manchester Evening News Business Awards 2009 Finalist - National Business Awards 2009 Finalist - Computer Weekly Best Places to Work in IT Awards 2009 Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 P Do you need to print this email? Please consider the environment. This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated. </BODY> </HTML>