From ramireddyravi at yahoo.com Tue Nov 1 17:38:20 2011 From: ramireddyravi at yahoo.com (Ravi.R) Date: Tue, 1 Nov 2011 09:38:20 -0700 (PDT) Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 2, Issue 3 In-Reply-To: References: Message-ID: <1320165500.67086.YahooMailNeo@web39407.mail.mud.yahoo.com> Dear RIPE List Serv members, ? Good day. My name is Ravi, I've been a dormant ListServ member for the last few months.?would any of the members here help me know how to report a Proxy server or VPN being used to send Spam-Email from anonymous IPs. ? Thank you for your time. ? Regards, Ravi ________________________________ From: "anti-abuse-wg-request at ripe.net" To: anti-abuse-wg at ripe.net Sent: Monday, October 31, 2011 7:00 AM Subject: anti-abuse-wg Digest, Vol 2, Issue 3 Send anti-abuse-wg mailing list submissions to ??? anti-abuse-wg at ripe.net To subscribe or unsubscribe via the World Wide Web, visit ??? https://www.ripe.net/mailman/listinfo/anti-abuse-wg or, via email, send a message with subject or body 'help' to ??? anti-abuse-wg-request at ripe.net You can reach the person managing the list at ??? anti-abuse-wg-owner at ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of anti-abuse-wg digest..." Today's Topics: ? 1. RIPE Abuse (Chris) ? 2. Re: RIPE Abuse (Michele Neylon :: Blacknight) ? 3. Re: RIPE Abuse (Chris) ? 4. Re: RIPE Abuse (Michele Neylon :: Blacknight) ? 5. Re: RIPE Abuse (Florian Weimer) ? 6. Re: RIPE Abuse (Brian Nisbet) ---------------------------------------------------------------------- Message: 1 Date: Sun, 30 Oct 2011 14:18:53 -0400 From: Chris Subject: [anti-abuse-wg] RIPE Abuse To: anti-abuse-wg at ripe.net Message-ID: ??? Content-Type: text/plain; charset=ISO-8859-1 Vesna sent me a request to join this group and with your meeting coming up, I would like to put some last minute issues in: XSServer, a German virtual private server / dedicated server hosting provider, is starting to be the new king when it comes to ignored abuse complaints. A lot of their IP ranges are being used for spam, including email and the new comment spam on websites / forums (mainly Wordpress). The simple solution taken by webmasters and system administrators are to create a list of offending IPs to have for comparison purposes, check a potential IP against that and use that IP to block the spam from going through. That doesn't really work in the long term. Examples of offending IPs are: 109.230.216.225 109.230.220.34 109.230.217.166 109.230.220.95 I could find more but I just searched 109.230 in my email client and found these. I have noticed also that a lot of RIPE IPs also have invalid contact information or no abuse / admin information whatsoever on them which I believe is against your rules / guidelines. Thank you and thank you for Vesna for recommending this mailing list for me. I just imagine a day we rely on blacklists and rely more on providers fixing the problems themselves, rather than having any incompetent government intervene to cause more problems to "fix the problem" -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton ------------------------------ Message: 2 Date: Sun, 30 Oct 2011 18:34:52 +0000 From: "Michele Neylon :: Blacknight" Subject: Re: [anti-abuse-wg] RIPE Abuse To: Chris Cc: "" Message-ID: <8C06FA59-B1C6-420A-8E5C-11F59066538D at blacknight.ie> Content-Type: text/plain; charset="us-ascii" On 30 Oct 2011, at 18:18, Chris wrote: > > > I have noticed also that a lot of RIPE IPs also have invalid contact > information or no abuse / admin information whatsoever on them which I > believe is against your rules / guidelines. I'm not an expert on RIPE policy / rules, but the invalid contact info would probably be a breach and you can report it to RIPE. The lack of an abuse contact wouldn't be a breach of any rules that I'm aware of Regards Michele Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59? 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland? Company No.: 370845 ------------------------------ Message: 3 Date: Sun, 30 Oct 2011 14:39:30 -0400 From: Chris Subject: Re: [anti-abuse-wg] RIPE Abuse To: anti-abuse-wg at ripe.net Message-ID: ??? Content-Type: text/plain; charset=ISO-8859-1 Whats the proper way to report to RIPE for invalid contact info? ------------------------------ Message: 4 Date: Sun, 30 Oct 2011 18:52:00 +0000 From: "Michele Neylon :: Blacknight" Subject: Re: [anti-abuse-wg] RIPE Abuse To: Chris Cc: "anti-abuse-wg at ripe.net" Message-ID: Content-Type: text/plain; charset="us-ascii" I'd try the contact page on the ripe site Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 30 Oct 2011, at 18:40, "Chris" wrote: > Whats the proper way to report to RIPE for invalid contact info? > ------------------------------ Message: 5 Date: Mon, 31 Oct 2011 08:28:41 +0000 From: Florian Weimer Subject: Re: [anti-abuse-wg] RIPE Abuse To: Chris Cc: anti-abuse-wg at ripe.net Message-ID: <824nypmuo6.fsf at mid.bfk.de> Content-Type: text/plain; charset=iso-8859-1 * Chris: > XSServer, a German virtual private server / dedicated server hosting > provider, is starting to be the new king when it comes to ignored > abuse complaints. Have you brought this to the attention of the folks at optimate-server.de? (I'm not saying that it would help, I'm just trying to get a more complete picture.) -- Florian Weimer? ? ? ? ? ? ? ? BFK edv-consulting GmbH? ? ? http://www.bfk.de/ Kriegsstra?e 100? ? ? ? ? ? ? tel: +49-721-96201-1 D-76133 Karlsruhe? ? ? ? ? ? fax: +49-721-96201-99 ------------------------------ Message: 6 Date: Mon, 31 Oct 2011 09:17:51 +0000 From: Brian Nisbet Subject: Re: [anti-abuse-wg] RIPE Abuse To: anti-abuse-wg at ripe.net Message-ID: <4EAE67BF.7030205 at heanet.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Chris, Chris wrote, On 30/10/2011 18:18: > > I have noticed also that a lot of RIPE IPs also have invalid contact > information or no abuse / admin information whatsoever on them which I > believe is against your rules / guidelines. > > Thank you and thank you for Vesna for recommending this mailing list > for me. I just imagine a day we rely on blacklists and rely more on > providers fixing the problems themselves, rather than having any > incompetent government intervene to cause more problems to "fix the > problem" You're not the only person to have noticed and raised this. There is currently a Task Force examining abuse contact information (due to report on current progress on Tuesday afternoon) and the NCC will be reporting on their new abuse contact measures during the session as well. Hopefully you'll be able to join us (either physically or via the Internet) on Tuesday and hopefully some, if not all, of your questions will be answered. Thanks, Brian. End of anti-abuse-wg Digest, Vol 2, Issue 3 ******************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From thor.kottelin at turvasana.com Tue Nov 1 18:21:02 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Tue, 1 Nov 2011 19:21:02 +0200 Subject: [anti-abuse-wg] How to report a proxy server or VPN being used to send spam (was: anti-abuse-wg Digest, Vol 2, Issue 3) In-Reply-To: <1320165500.67086.YahooMailNeo@web39407.mail.mud.yahoo.com> References: <1320165500.67086.YahooMailNeo@web39407.mail.mud.yahoo.com> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Ravi.R > Sent: Tuesday, November 01, 2011 6:38 PM > To: anti-abuse-wg at ripe.net > would any of the members here help me know how > to report a Proxy server or VPN being used to send Spam-Email from > anonymous IPs. Hello Ravi, A generic first-line approach would be to use Whois contact information to alert whomever is responsible for the network from which spam is being sent. If you have received actual spam messages, include them, complete with headers; if you are fending off the spam on the SMTP level, send log entries instead. I hope I have understood your question correctly. If not, or if you need more specific advice, please provide additional details. -- Thor Kottelin http://www.anta.net/ From root at blocklist.de Tue Nov 1 19:36:29 2011 From: root at blocklist.de (www.blocklist.de) Date: Tue, 01 Nov 2011 19:36:29 +0100 Subject: [anti-abuse-wg] How to report a proxy server or VPN being used to send spam In-Reply-To: References: <1320165500.67086.YahooMailNeo@web39407.mail.mud.yahoo.com> Message-ID: <4EB03C2D.2030004@blocklist.de> Hi, he reveived a lot of Abuse-Complaints from us: https://www.blocklist.de/en/search.html?as=197043 https://www.blocklist.de/en/view.html?ip=109.230.213.128 whois -> e-mail: abuse[at]xsserver.eu for xsserver.eu we have send over 8.000 Reports. And we send only all 24h after the last attack/Report a new report. In the network of AS197043 (optimate-server.de) there are also exetel.de, who is also ignorant (over 2.000 Reports and he is new). I think and say the complete network is bad and bulletproof for spam. best regards Martin Schiftan Abuse-Team http://www.blocklist.de/en/ Am 01.11.2011 18:21, schrieb Thor Kottelin: >> -----Original Message----- >> From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- >> bounces at ripe.net] On Behalf Of Ravi.R >> Sent: Tuesday, November 01, 2011 6:38 PM >> To: anti-abuse-wg at ripe.net > >> would any of the members here help me know how >> to report a Proxy server or VPN being used to send Spam-Email from >> anonymous IPs. > > Hello Ravi, > > A generic first-line approach would be to use Whois contact information to > alert whomever is responsible for the network from which spam is being sent. > If you have received actual spam messages, include them, complete with > headers; if you are fending off the spam on the SMTP level, send log entries > instead. > > I hope I have understood your question correctly. If not, or if you need > more specific advice, please provide additional details. > From lou at lougogan.com Fri Nov 4 19:37:48 2011 From: lou at lougogan.com (Lou Gogan) Date: Fri, 4 Nov 2011 18:37:48 +0000 Subject: [anti-abuse-wg] broken contacts Message-ID: <201111041837.48349.lou@lougogan.com> Hi I hope I am not out of place here, but this is my experience today and the problem I find I have because of the broken contacts information via the whois. This morning I received a fraudulent spam claiming to be from the Bank of Ireland with an attached form to be filled in. I was going to delete it as usual but decided that these types of email fraud need to be reported in order to protect others. I checked out the form and found the form contact link: MBNA Online $ host masserialojazzo.it masserialojazzo.it has address 46.252.206.1 ;; connection timed out; no servers could be reached masserialojazzo.it mail is handled by 10 mailstore1.europe.secureserver.net. masserialojazzo.it mail is handled by 0 smtp.europe.secureserver.net. And then I whoised $ whois 46.252.206.1 inetnum: ? ? ? ?46.252.200.0 - 46.252.207.255 netname: ? ? ? ?GDNL-46-252-200-0-TO-207-255 descr: ? ? ? ? ?Customer country: ? ? ? ?NL admin-c: ? ? ? ?WR1096-RIPE tech-c: ? ? ? ? WR1096-RIPE status: ? ? ? ? ASSIGNED PA mnt-by: ? ? ? ? MNT-GDG-NL source: ? ? ? ? RIPE # Filtered person: ? ? ? ? Will Regg address: ? ? ? ?H.J.E. Wenckebachweg 127 ? ? ? ? ? ? ? ? 1096 AM Amsterdam phone: ? ? ? ? ?+14805058877 nic-hdl: ? ? ? ?WR1096-RIPE source: ? ? ? ? RIPE # Filtered As you may notice, there is no suitable email contact at all. (Writing a letter and posting it off didn't seem a useful option!) This was a email fraud. I, as a reasonable individual trying to do my civic duty and possible prevent someone with less 'cop on' from being scammed, was utterly wasting my time trying to do anything. There was no abuse contact. If RIPE and ICANN and others want to do anything at all regarding spam, and scams and net abuse etc one of the first actions should be to ensure there are correct contacts for every ISP so at least scams and illegal activity can be reported. I would also suggest that a default abuse address be insisted upon eg abuse at wherever.doh as I have found many a frustrating experience emailing a named administrator was has left the company and whose email is dead. Perhaps someone was scammed by this same email today. A quick report and possibly a quick shutdown of that link may have achieved something positive. I also have a web site which is attacked on a regular basis and I try and make a point of reporting them all. In some cases with very positive results eg a compromised server found etc. I consider that trying to close these people down is the only way to prevent things getting totally out of hand. The problem is that approximately 1 in 4 abuse email addresses are incorrect and the email is returned undelivered. These are my frustrating experiences. As I said, I hope I am not out of place here, pointing this out. Regards Lou Gogan Saula, Achill, Co Mayo, Ireland. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LINUX - bringing joy and creativity to computing. Registered Linux user number 478188 www.lougogan.com From michele at blacknight.ie Fri Nov 4 20:04:17 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Fri, 4 Nov 2011 19:04:17 +0000 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <201111041837.48349.lou@lougogan.com> References: <201111041837.48349.lou@lougogan.com> Message-ID: On 4 Nov 2011, at 19:37, Lou Gogan wrote: > Hi > > I hope I am not out of place here, but this is my experience today and the > problem I find I have because of the broken contacts information via the whois. > > This morning I received a fraudulent spam claiming to be from the Bank of > Ireland with an attached form to be filled in. I was going to delete it as > usual but decided that these types of email fraud need to be reported in order > to protect others. In the case of a phish you should report it to the bank. > > I checked out the form and found the form contact link: > MBNA Online > > $ host masserialojazzo.it > masserialojazzo.it has address 46.252.206.1 > ;; connection timed out; no servers could be reached > masserialojazzo.it mail is handled by 10 mailstore1.europe.secureserver.net. > masserialojazzo.it mail is handled by 0 smtp.europe.secureserver.net. > > And then I whoised > > $ whois 46.252.206.1 > inetnum: 46.252.200.0 - 46.252.207.255 > netname: GDNL-46-252-200-0-TO-207-255 > descr: Customer > country: NL > admin-c: WR1096-RIPE > tech-c: WR1096-RIPE > status: ASSIGNED PA > mnt-by: MNT-GDG-NL > source: RIPE # Filtered > > person: Will Regg > address: H.J.E. Wenckebachweg 127 > 1096 AM Amsterdam > phone: +14805058877 > nic-hdl: WR1096-RIPE > source: RIPE # Filtered > > As you may notice, there is no suitable email contact at all. (Writing a letter > and posting it off didn't seem a useful option!) > > This was a email fraud. I, as a reasonable individual trying to do my civic duty > and possible prevent someone with less 'cop on' from being scammed, was utterly > wasting my time trying to do anything. There was no abuse contact. Did the email actually come from that IP or from another one? > > If RIPE and ICANN and others want to do anything at all regarding spam, and > scams and net abuse etc one of the first actions should be to ensure there are > correct contacts for every ISP so at least scams and illegal activity can be > reported. There has been lengthy discussion on this subject on this mailing list and elsewhere > > I would also suggest that a default abuse address be insisted upon eg > abuse at wherever.doh as I have found many a frustrating experience emailing a > named administrator was has left the company and whose email is dead. > > Perhaps someone was scammed by this same email today. A quick report and > possibly a quick shutdown of that link may have achieved something positive. > > I also have a web site which is attacked on a regular basis and I try and make a > point of reporting them all. In some cases with very positive results eg a > compromised server found etc. I consider that trying to close these people down > is the only way to prevent things getting totally out of hand. The problem is > that approximately 1 in 4 abuse email addresses are incorrect and the email is > returned undelivered. > > These are my frustrating experiences. > > As I said, I hope I am not out of place here, pointing this out. > > Regards > > Lou Gogan > > Saula, Achill, Co Mayo, Ireland. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > LINUX - bringing joy and creativity to computing. > Registered Linux user number 478188 > > www.lougogan.com > Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From tk at abusix.com Fri Nov 4 20:29:14 2011 From: tk at abusix.com (Tobias Knecht) Date: Fri, 04 Nov 2011 20:29:14 +0100 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <201111041837.48349.lou@lougogan.com> References: <201111041837.48349.lou@lougogan.com> Message-ID: <4EB43D0A.9020500@abusix.com> Hi Lou, there is already a Task Force in place trying to solve the fact of missing abuse contact information. http://www.ripe.net/ripe/groups/tf/abuse-contact We will publish a policy proposal soon. Feel free to support the proposal here on the list as soon as we will post it. Thanks, Tobias Am 04.11.11 19:37, schrieb Lou Gogan: > Hi > > I hope I am not out of place here, but this is my experience today and the > problem I find I have because of the broken contacts information via the whois. > > This morning I received a fraudulent spam claiming to be from the Bank of > Ireland with an attached form to be filled in. I was going to delete it as > usual but decided that these types of email fraud need to be reported in order > to protect others. > > I checked out the form and found the form contact link: > MBNA Online > > $ host masserialojazzo.it > masserialojazzo.it has address 46.252.206.1 > ;; connection timed out; no servers could be reached > masserialojazzo.it mail is handled by 10 mailstore1.europe.secureserver.net. > masserialojazzo.it mail is handled by 0 smtp.europe.secureserver.net. > > And then I whoised > > $ whois 46.252.206.1 > inetnum: 46.252.200.0 - 46.252.207.255 > netname: GDNL-46-252-200-0-TO-207-255 > descr: Customer > country: NL > admin-c: WR1096-RIPE > tech-c: WR1096-RIPE > status: ASSIGNED PA > mnt-by: MNT-GDG-NL > source: RIPE # Filtered > > person: Will Regg > address: H.J.E. Wenckebachweg 127 > 1096 AM Amsterdam > phone: +14805058877 > nic-hdl: WR1096-RIPE > source: RIPE # Filtered > > As you may notice, there is no suitable email contact at all. (Writing a letter > and posting it off didn't seem a useful option!) > > This was a email fraud. I, as a reasonable individual trying to do my civic duty > and possible prevent someone with less 'cop on' from being scammed, was utterly > wasting my time trying to do anything. There was no abuse contact. > > If RIPE and ICANN and others want to do anything at all regarding spam, and > scams and net abuse etc one of the first actions should be to ensure there are > correct contacts for every ISP so at least scams and illegal activity can be > reported. > > I would also suggest that a default abuse address be insisted upon eg > abuse at wherever.doh as I have found many a frustrating experience emailing a > named administrator was has left the company and whose email is dead. > > Perhaps someone was scammed by this same email today. A quick report and > possibly a quick shutdown of that link may have achieved something positive. > > I also have a web site which is attacked on a regular basis and I try and make a > point of reporting them all. In some cases with very positive results eg a > compromised server found etc. I consider that trying to close these people down > is the only way to prevent things getting totally out of hand. The problem is > that approximately 1 in 4 abuse email addresses are incorrect and the email is > returned undelivered. > > These are my frustrating experiences. > > As I said, I hope I am not out of place here, pointing this out. > > Regards > > Lou Gogan > > Saula, Achill, Co Mayo, Ireland. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > LINUX - bringing joy and creativity to computing. > Registered Linux user number 478188 > > www.lougogan.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From lou at lougogan.com Fri Nov 4 22:02:45 2011 From: lou at lougogan.com (Lou Gogan) Date: Fri, 4 Nov 2011 21:02:45 +0000 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <4EB43D0A.9020500@abusix.com> References: <201111041837.48349.lou@lougogan.com> <4EB43D0A.9020500@abusix.com> Message-ID: <201111042102.45448.lou@lougogan.com> On Friday 04 November 2011 19:29:14 Tobias Knecht wrote: > Hi Lou, > > there is already a Task Force in place trying to solve the fact of > missing abuse contact information. > > http://www.ripe.net/ripe/groups/tf/abuse-contact > > We will publish a policy proposal soon. Feel free to support the > proposal here on the list as soon as we will post it. > > Thanks, > > Tobias > > Hi Tobias I'll watch out for it. Danke Lou > > > > Regards > > > > Lou Gogan > > > > Saula, Achill, Co Mayo, Ireland. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > LINUX - bringing joy and creativity to computing. > > Registered Linux user number 478188 > > > > www.lougogan.com > > From lou at lougogan.com Fri Nov 4 22:07:57 2011 From: lou at lougogan.com (Lou Gogan) Date: Fri, 4 Nov 2011 21:07:57 +0000 Subject: [anti-abuse-wg] broken contacts In-Reply-To: References: <201111041837.48349.lou@lougogan.com> Message-ID: <201111042107.57549.lou@lougogan.com> Hi Michele On Friday 04 November 2011 19:04:17 you wrote: > > On 4 Nov 2011, at 19:37, Lou Gogan wrote: > > > Hi > > I hope I am not out of place here, but this is my experience today and the > > problem I find I have because of the broken contacts information via the whois. > > > > This morning I received a fraudulent spam claiming to be from the Bank of > > Ireland with an attached form to be filled in. I was going to delete it as > > usual but decided that these types of email fraud need to be reported in order > > to protect others. > > In the case of a phish you should report it to the bank. Didn't think of that. Doh! Though I still think a direct contact with the IP would close down that fraudulent link immediately. > > > > I checked out the form and found the form contact link: > > MBNA Online > > > > $ host masserialojazzo.it > > masserialojazzo.it has address 46.252.206.1 > > > > And then I whoised > > > > $ whois 46.252.206.1 ~~~ snip ~~~ > > As you may notice, there is no suitable email contact at all. (Writing a > > letter and posting it off didn't seem a useful option!) > > > > This was a email fraud. I, as a reasonable individual trying to do my civic duty > > and possible prevent someone with less 'cop on' from being scammed, was utterly > > wasting my time trying to do anything. There was no abuse contact. > > Did the email actually come from that IP or from another one? According to spamcop: virginmedia.com - I sent virginmedia.com an email report > > If RIPE and ICANN and others want to do anything at all regarding spam, and > > scams and net abuse etc one of the first actions should be to ensure there are > > correct contacts for every ISP so at least scams and illegal activity can be > > reported. > > There has been lengthy discussion on this subject on this mailing list and elsewhere > > > I would also suggest that a default abuse address be insisted upon eg > > abuse at wherever.doh as I have found many a frustrating experience emailing a > > named administrator was has left the company and whose email is dead. > > > > Perhaps someone was scammed by this same email today. A quick report and > > possibly a quick shutdown of that link may have achieved something positive. > > ~~~ snip ~~~ Regards Lou Gogan Saula, Achill, Co Mayo, Ireland. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LINUX - bringing joy and creativity to computing. Registered Linux user number 478188 www.lougogan.com > Mr Michele Neylon ~~~snip ~~~ > http://www.blacknight.com/ > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > From leo.vegoda at icann.org Fri Nov 4 23:28:10 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 4 Nov 2011 15:28:10 -0700 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <201111042107.57549.lou@lougogan.com> References: <201111041837.48349.lou@lougogan.com> <201111042107.57549.lou@lougogan.com> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> Hi, > Though I still think a direct contact with the IP would close down that > fraudulent link immediately. There's no reason you can't do both. If you report it to the bank they have an interest in stopping the criminals while the network operators just has an interest in them moving on. Regards, Leo Vegoda From mm at elabnet.de Sat Nov 5 04:11:52 2011 From: mm at elabnet.de (Michael Markstaller) Date: Sat, 5 Nov 2011 04:11:52 +0100 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> References: <201111041837.48349.lou@lougogan.com> <201111042107.57549.lou@lougogan.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> Message-ID: <1320462712.19837.25.camel@v1520-mm> Am Freitag, den 04.11.2011, 15:28 -0700 schrieb Leo Vegoda: > Hi, > > > Though I still think a direct contact with the IP would close down that > > fraudulent link immediately. > > There's no reason you can't do both. If you report it to the bank they have an interest in stopping the criminals while the network operators just has an interest in them moving on. Might be true but if such things would happen in my scope of resposibility, I'd have no reason to *not* take this offline immediately. If I know (and there is the problem!) If you report such a thing at abuse at MYDOMAIN, promised, someone will wake me up at 4 o'clock and we'll turn it off.... Thats how things should be, isn't it ? ;) I guess there are far enough responsible people out there, to solve such issues right away - but only if they have the tools to verify! and the "rights" to react.. Currently we havent..(as the thread-starter noticed) This is IMHO not a matter of privacy (in terms of ISP - which we all are?) but more bureaucracy burdens, legal stuff.. So I also wait what comes up there, I'll support it. Long discussions, ok, but at some point in time there also has to be a decision: do we want anonymous IP's in the RIPE region or not ? Should it be possible to have an anonymous Scam/Spam-IP? I'd say no. (sure that banks also badly failed to have secure methologies, but thats not my scope, I have to take care about secure networks & IP ;)) Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From lou at lougogan.com Sat Nov 5 10:14:43 2011 From: lou at lougogan.com (Lou Gogan) Date: Sat, 5 Nov 2011 09:14:43 +0000 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> References: <201111041837.48349.lou@lougogan.com> <201111042107.57549.lou@lougogan.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> Message-ID: <201111050914.44068.lou@lougogan.com> On Friday 04 November 2011 22:28:10 Leo Vegoda wrote: > Hi, > > > Though I still think a direct contact with the IP would close down that > > fraudulent link immediately. > > There's no reason you can't do both. If you report it to the bank they have an interest in stopping the criminals while the network operators just has an interest in them moving on. > > Regards, > > Leo Vegoda > Hi Leo You are missing the point entirely. Firstly, it is not the job of the Bank of Ireland to persue fraudsters all around the world merely because they are pretending to be the BOI. This is an attempt to steal money from people. It is a crime. The only main contact with the criminals is the ISP. They will know the acual contact details of the criminls, hopefully, and can act on that, or at the very least shut that link down pronto. Secondly, there are many scams out there trying to con people into giving details of their credit cards etc with no direct connection to any bank - thus the abuse contact details still should be easy to obtain so a report can be sent from anyone aware of a fraud attempt, even a Lou Blogs. Thought experiment: If you saw a bank robbery and the thieves were using a HONDA as the getaway car, would you contact HONDA or would you contact the police? To a certain degree you are saying I should contact Honda, whereas I would consider contacting the police, or someone who can contact the police - in this case the ISP. Sl?n Lou Achill, Ireland - where the sun shines from morning till night . . . . . . . . . . above the rain clouds 8=( From michele at blacknight.ie Sat Nov 5 12:39:52 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Sat, 5 Nov 2011 11:39:52 +0000 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <201111050914.44068.lou@lougogan.com> References: <201111041837.48349.lou@lougogan.com> <201111042107.57549.lou@lougogan.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> <201111050914.44068.lou@lougogan.com> Message-ID: <4578B2F4-F0DE-418C-8AB4-B5DDDD31CACD@blacknight.ie> On 5 Nov 2011, at 09:14, Lou Gogan wrote: > Firstly, it is not the job of the Bank of Ireland to persue fraudsters all > around the world merely because they are pretending to be the BOI. Actually it is .. > > This is an attempt to steal money from people. It is a crime. The only main > contact with the criminals is the ISP. That's based on an assumption that the ISP / hosting provider actually has contact with the phisher. In most cases they wouldn't, as the bulk of phishing attacks go via compromised hosting accounts and / or accounts that lead to chargebacks > They will know the acual contact details > of the criminls, Doubtful - see above > hopefully, and can act on that, or at the very least shut that > link down pronto. > > Secondly, there are many scams out there trying to con people into giving > details of their credit cards etc with no direct connection to any bank - thus > the abuse contact details still should be easy to obtain so a report can be > sent from anyone aware of a fraud attempt, even a Lou Blogs. > > Thought experiment: > If you saw a bank robbery and the thieves were using a HONDA as the getaway car, > would you contact HONDA or would you contact the police? To a certain degree > you are saying I should contact Honda, whereas I would consider contacting the > police, or someone who can contact the police - in this case the ISP. I'm really finding it hard to follow that analogy. Regards Michele Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From leo.vegoda at icann.org Sat Nov 5 13:31:24 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sat, 5 Nov 2011 05:31:24 -0700 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <201111050914.44068.lou@lougogan.com> References: <201111041837.48349.lou@lougogan.com> <201111042107.57549.lou@lougogan.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> <201111050914.44068.lou@lougogan.com> Message-ID: On Nov 5, 2011, at 2:14 am, Lou Gogan wrote: [?] > You are missing the point entirely. > > Firstly, it is not the job of the Bank of Ireland to persue fraudsters all > around the world merely because they are pretending to be the BOI. I don't know how you came up with that one. At the very least, a responsible bank should work with the relevant law enforcement agencies. > This is an attempt to steal money from people. It is a crime. The only main > contact with the criminals is the ISP. They will know the acual contact details > of the criminls, hopefully, and can act on that, or at the very least shut that > link down pronto. You're assuming the baddies bought accounts instead of just hacking someone else's server. > Secondly, there are many scams out there trying to con people into giving > details of their credit cards etc with no direct connection to any bank - thus > the abuse contact details still should be easy to obtain so a report can be > sent from anyone aware of a fraud attempt, even a Lou Blogs. Abuse contact details are only useful when there is a there is a properly resourced set of people behind them. Without that they are at best worthless and and at worst dangerously misleading. I'm all in favour of ISPs doing the right thing abut ISPs are only part of the story and they each only see a small slice of the picture. The kind of abuse described in this thread needs to be addressed by the brand owner as well as the ISP because the brand owner will want to minimise its association with fraudsters. Regards, Leo From ripe-wg-antiabuse at kyubu.de Mon Nov 7 08:58:09 2011 From: ripe-wg-antiabuse at kyubu.de (ripe-wg-antiabuse at kyubu.de) Date: Mon, 7 Nov 2011 08:58:09 +0100 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <201111041837.48349.lou@lougogan.com> References: <201111041837.48349.lou@lougogan.com> Message-ID: <20111107075809.GA32247@core.kyubu.de> On Fri, Nov 04, 2011 at 06:37:48PM +0000, Lou Gogan wrote: Hey Lou, > $ whois 46.252.206.1 > inetnum: ? ? ? ?46.252.200.0 - 46.252.207.255 > As you may notice, there is no suitable email contact at all. (Writing a letter Besides all mentioned solutions, you could go upstream with your complaints. At least, they should have a valid contact. Cheers, Adrian From shane at time-travellers.org Mon Nov 7 13:52:12 2011 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 07 Nov 2011 13:52:12 +0100 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <201111050914.44068.lou@lougogan.com> References: <201111041837.48349.lou@lougogan.com> <201111042107.57549.lou@lougogan.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> <201111050914.44068.lou@lougogan.com> Message-ID: <1320670332.5722.9.camel@shane-desktop> Lou, On Sat, 2011-11-05 at 09:14 +0000, Lou Gogan wrote: > > Firstly, it is not the job of the Bank of Ireland to persue fraudsters all > around the world merely because they are pretending to be the BOI. I mostly agree with you, but would like to point out that banks call this sort of thing "identity theft". They make it the problem of the people being impersonated, even though that person has nothing to do with what is going on. ;) -- Shane From ops.lists at gmail.com Mon Nov 7 14:32:02 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 7 Nov 2011 19:02:02 +0530 Subject: [anti-abuse-wg] broken contacts In-Reply-To: <1320670332.5722.9.camel@shane-desktop> References: <201111041837.48349.lou@lougogan.com> <201111042107.57549.lou@lougogan.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F82D47C4@EXVPMBX100-1.exc.icann.org> <201111050914.44068.lou@lougogan.com> <1320670332.5722.9.camel@shane-desktop> Message-ID: Shane - 1. It depends, you will find enough banks actively engaged in pursuing phish sites [if you are in the right forums for that, and the right forum for that is not anywhere IP allocation, routing and dns are about the only content you'll find] 2. The "we are not the X police" meme needs to be taken out and shot. On Mon, Nov 7, 2011 at 6:22 PM, Shane Kerr wrote: > > On Sat, 2011-11-05 at 09:14 +0000, Lou Gogan wrote: >> >> Firstly, it is not the job of the Bank of Ireland to persue fraudsters all >> around the world merely because they are pretending to be the BOI. > > I mostly agree with you, but would like to point out that banks call > this sort of thing "identity theft". They make it the problem of the > people being impersonated, even though that person has nothing to do > with what is going on. ;) -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Thu Nov 10 02:43:18 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 10 Nov 2011 07:13:18 +0530 Subject: [anti-abuse-wg] IPv6 ripeness - smaller orgs more v6 ready Message-ID: http://www.circleid.com/posts/20111108_ipv6_ripeness_more_smaller_younger_organizations_deploying_ipv6/ Now it remains to be seen how many of these newer organizations are actually shell company LIRs and such :) -- Suresh Ramasubramanian (ops.lists at gmail.com) From emadaio at ripe.net Wed Nov 23 14:46:42 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 23 Nov 2011 14:46:42 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) Message-ID: Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-06 We encourage you to review this proposal and send your comments to before 21 December 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From leo.vegoda at icann.org Wed Nov 23 15:48:00 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 23 Nov 2011 06:48:00 -0800 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <201111231347.pANDlH64028370@pechora5.dc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> Hi, The proposed policy text includes: "The role objects used for abuse contact information will be required to contain a single "abuse-mailbox:" attribute which is intended for receiving automatic and manual reports about abusive behavior originating the resource holders' networks." Do the proposers intend the requirement for the "abuse-mailbox:" attribute to be enforced in any way and if so, how? Thanks, Leo From rbriaut at wanadoo.fr Wed Nov 23 16:19:32 2011 From: rbriaut at wanadoo.fr (Briaut perso) Date: Wed, 23 Nov 2011 16:19:32 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) In-Reply-To: References: Message-ID: Hello ! I speak french only Ren? BRIAUT 115 Cours Fauriel 42100 SAINT ETIENNE ( 04.77.46.96.07 et 06.07.61.29.49 rbriaut at wanadoo.fr -----Message d'origine----- De?: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] De la part de Emilio Madaio Envoy??: mercredi 23 novembre 2011 14:47 ??: policy-announce at ripe.net Cc?: anti-abuse-wg at ripe.net Objet?: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-06 We encourage you to review this proposal and send your comments to before 21 December 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From eserinadresi at gmail.com Wed Nov 23 16:54:35 2011 From: eserinadresi at gmail.com (=?ISO-8859-1?Q?eser_r=FCzgar?=) Date: Wed, 23 Nov 2011 17:54:35 +0200 Subject: [anti-abuse-wg] "www.canay.tv" is doing privacy violation Message-ID: Hey All, We are Eren AMBARK?T?K's lawyers. We tracked "www.canay.com" domain name for a long time. because, that domain name was published some photo which related our client's photo. At the end of the story, The Turkey Telecommunications Office was gave a notification "www.canay.com" because of our claim about privacy violation of Eren AMBARK?T?K's fotographs. Now, we can access the same photos with "www.canay.tv". Your company is service provider of www.canay.tv and we kindly claming you that remove that domin name.if not, we have to sue www.canay.tv and their service provider. You can see the links which include abuse usages as follow: 1. http://www.canay.tv/category/ebru-salli-frikik-video-ebruli-tv8/ 2. http://www.canay.tv/2011/03/22/ebru-salli-ve-eren-ambarkutukle-pilates-ebruli/ 3. http://www.canay.tv/2011/05/24/eren-ambarkutuk-gogus-pilates-ebruli/ 4. http://www.canay.tv/2011/04/22/eren-ambarkutuk-tangasi-ve-ayrintilari-ebruli/ 5. http://www.canay.tv/2011/05/09/eren-ambarkutuk-pilates-guzeli-ebruli/ 6. http://www.canay.tv/2011/03/31/eren-ambarkutukten-pilates-teknikleri-ebruli/ 7. http://www.canay.tv/2011/07/28/eren-ambarkutuk-bacaklar-ve-pilates-ebruli/ 8. http://www.canay.tv/2011/04/26/eren-ambarkutuk-nefes-al-nefes-ver-ebruli/ 9. http://www.canay.tv/2011/06/21/eren-ambarkutuk-seffaf-tayt-cameltoe-ebruli/ Eser R?ZGAR Attornet at Law at ?stanbul Bar Association Trade Mark Expert at Turkish Patent Institute -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: the_netherlands_12nov2007_en.pdf Type: application/pdf Size: 26193 bytes Desc: not available URL: From michele at blacknight.ie Wed Nov 23 17:09:42 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 23 Nov 2011 16:09:42 +0000 Subject: [anti-abuse-wg] "www.canay.tv" is doing privacy violation In-Reply-To: References: Message-ID: Mr Ruzgar RIPE is http://www.ripe.net This is not the place to send your complaint. Try ABUSE at plusserver.de Regards Michele On 23 Nov 2011, at 15:54, eser r?zgar wrote: > Hey All, > > We are Eren AMBARK?T?K's lawyers. We tracked "www.canay.com" domain name for a long time. because, that domain name was published some photo which related our client's photo. At the end of the story, The Turkey Telecommunications Office was gave a notification "www.canay.com" because of our claim about privacy violation of Eren AMBARK?T?K's fotographs. Now, we can access the same photos with "www.canay.tv". Your company is service provider of www.canay.tv and we kindly claming you that remove that domin name.if not, we have to sue www.canay.tv and their service provider. You can see the links which include abuse usages as follow: > > > > ? http://www.canay.tv/category/ebru-salli-frikik-video-ebruli-tv8/ > ? http://www.canay.tv/2011/03/22/ebru-salli-ve-eren-ambarkutukle-pilates-ebruli/ > ? http://www.canay.tv/2011/05/24/eren-ambarkutuk-gogus-pilates-ebruli/ > ? http://www.canay.tv/2011/04/22/eren-ambarkutuk-tangasi-ve-ayrintilari-ebruli/ > ? http://www.canay.tv/2011/05/09/eren-ambarkutuk-pilates-guzeli-ebruli/ > ? http://www.canay.tv/2011/03/31/eren-ambarkutukten-pilates-teknikleri-ebruli/ > ? http://www.canay.tv/2011/07/28/eren-ambarkutuk-bacaklar-ve-pilates-ebruli/ > ? http://www.canay.tv/2011/04/26/eren-ambarkutuk-nefes-al-nefes-ver-ebruli/ > ? http://www.canay.tv/2011/06/21/eren-ambarkutuk-seffaf-tayt-cameltoe-ebruli/ > > > Eser R?ZGAR > Attornet at Law at ?stanbul Bar Association > Trade Mark Expert at Turkish Patent Institute > > > > > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From fweimer at bfk.de Wed Nov 23 17:17:07 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 23 Nov 2011 16:17:07 +0000 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <82sjlfx7y1.fsf@totally-fudged-out-message-id> (Emilio Madaio's message of "Wed, 23 Nov 2011 14:46:42 +0100") References: <82sjlfx7y1.fsf@totally-fudged-out-message-id> Message-ID: <82zkfmx18c.fsf@mid.bfk.de> > http://www.ripe.net/ripe/policies/proposals/2011-06 Is this the outcome of the task force? What is the exact benefit over just changing the WHOIS server to synthesize abuse-mailbox: fields on inetnum: objects? That the new fields are not optional anymore? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From thor.kottelin at turvasana.com Wed Nov 23 17:20:32 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Wed, 23 Nov 2011 18:20:32 +0200 Subject: [anti-abuse-wg] "www.canay.tv" is doing privacy violation In-Reply-To: References: Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of eser r?zgar > Sent: Wednesday, November 23, 2011 5:55 PM > To: anti-abuse-wg at ripe.net > We are Eren AMBARK?T?K's lawyers. We tracked "www.canay.com" domain > name for a long time. because, that domain name was published some > photo which related our client's photo. At the end of the story, > The Turkey Telecommunications Office was gave a notification > "www.canay.com" because of our claim about privacy violation of > Eren AMBARK?T?K's fotographs. Now, we can access the same photos > with "www.canay.tv". Your company is service provider of > www.canay.tv and we kindly claming you that remove that domin > name. Hello Eser, RIPE is a regional Internet registry. It does not provide hosting services to the public. The domain name www.canay.tv points to the IP address 85.25.184.25, which is assigned to BSB-Service GmbH in Germany. For details on that network, please see https://apps.db.ripe.net/search/query.html?searchtext=85.25.184.25. -- Thor Kottelin http://www.anta.net/ From james.davis at ja.net Wed Nov 23 17:25:59 2011 From: james.davis at ja.net (James Davis) Date: Wed, 23 Nov 2011 16:25:59 +0000 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> Message-ID: <4ECD1E97.90004@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I haven't been closely following the development of this policy so it's almost certain that I've missed something. At the start of the proposal it mentions "it is not clear in which of these role objects it should be preferred.", but it's not clear to me at by the end of the document why I should prefer an abuse-c attribute to an irt object. Also: "there will be some automated clean up of users data to reorganize abuse contact references where possible." Is that expanded on anywhere? James - -- James Davis 0300 999 2340 (+44 1235 822340) Senior CSIRT Member Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7NHpYACgkQjsS2Y6D6yLyMeAD5AYzwqaIg3Oyefmik24B/K2P7 /aQy1GtpJeuqrCEQVF8BAOFl4c/f0qum4G4qp0OtgF8Ntv70owZxIwGuwlL5nBce =Xul4 -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From brian.nisbet at heanet.ie Wed Nov 23 17:43:26 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 23 Nov 2011 16:43:26 +0000 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) In-Reply-To: References: Message-ID: <4ECD22AE.5090905@heanet.ie> Ren?, The RIPE Policy Development Process uses English as its primary language. As such policy proposals and discussion can only be guaranteed to take place in that language. Regards, Brian Co-Chair, Anti-Abuse WG "Briaut perso" wrote the following on 23/11/2011 15:19: > Hello ! > > I speak french only > > Ren? BRIAUT > > 115 Cours Fauriel > > 42100 SAINT ETIENNE > > ( 04.77.46.96.07 et 06.07.61.29.49 > > rbriaut at wanadoo.fr > -----Message d'origine----- > De : anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] > De la part de Emilio Madaio > Envoy? : mercredi 23 novembre 2011 14:47 > ? : policy-announce at ripe.net > Cc : anti-abuse-wg at ripe.net > Objet : [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement > in the RIPE NCC Database) > > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-06 > > We encourage you to review this proposal and send your comments to > before 21 December 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > > From ops.lists at gmail.com Wed Nov 23 18:19:59 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 23 Nov 2011 22:49:59 +0530 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> Message-ID: it is an interesting question, followed by the 'what is ripe to do in cases where is requirement isnt complied with, or where it is fraudulent' question --srs (iPad) On 23-Nov-2011, at 20:18, Leo Vegoda wrote: > Hi, > > The proposed policy text includes: > > "The role objects used for abuse contact information will be required to contain a single "abuse-mailbox:" attribute which is intended for receiving automatic and manual reports about abusive behavior originating the resource holders' networks." > > Do the proposers intend the requirement for the "abuse-mailbox:" attribute to be enforced in any way and if so, how? > > Thanks, > > Leo > From aftab.siddiqui at gmail.com Thu Nov 24 07:58:47 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Thu, 24 Nov 2011 11:58:47 +0500 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4eccf969.25ebd80a.521a.ffffff90SMTPIN_ADDED@mx.google.com> References: <4eccf969.25ebd80a.521a.ffffff90SMTPIN_ADDED@mx.google.com> Message-ID: It states "The syntax will make this an optional attribute". We are dealing with inconsistent records even making it mandatory in the APNIC region. How would it help? or I didn't understand properly, can anyone elaborate? Regards, Aftab A. Siddiqui On Wed, Nov 23, 2011 at 6:46 PM, Emilio Madaio wrote: > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-06 > > We encourage you to review this proposal and send your comments to > before 21 December 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.massen at restena.lu Thu Nov 24 09:55:02 2011 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 24 Nov 2011 09:55:02 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111123134719.EDB3516738D@smtpgate1.restena.lu> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> Message-ID: <4ECE0666.8010502@restena.lu> Hello, This policy proposal seems a bit incomplete to, as it fails to address the problem statement from the summary. >From the summary: "...it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object.". What is supposed to happen to IRT objects, or data from them? For existing records: at the very least it should be explicit which tags should no longer be used or would be deprecated / removed in order to give clear guidance. Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots? Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From P.Vissers at opta.nl Thu Nov 24 09:58:05 2011 From: P.Vissers at opta.nl (Vissers, Pepijn) Date: Thu, 24 Nov 2011 08:58:05 +0000 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <4eccf969.25ebd80a.521a.ffffff90SMTPIN_ADDED@mx.google.com> Message-ID: Yes, I noticed that one too. It's followed by '...but business rules will require it to be included in (...) RIPE, PI and AS assignments'. A few starting remarks to fire up the discussion: - The PA ranges are not included in this range; I heavily suspect however that in the PA allocations the problem with incorrect/unreachable abuse details is by far the largest (think shady LIRs subdelegating IP space. A very common business model). This policy should make an effort to try to touch the PA IP space too. - A reference to, or a summary of the document containing the 'business rules' would help clarify the exact requirements. - As mentioned before, what in case of non-compliance? The policy should state, or reference to, that too. Pepijn Van: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] Namens Aftab Siddiqui Verzonden: donderdag 24 november 2011 7:59 Aan: anti-abuse-wg at ripe.net Onderwerp: Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) It states "The syntax will make this an optional attribute". We are dealing with inconsistent records even making it mandatory in the APNIC region. How would it help? or I didn't understand properly, can anyone elaborate? Regards, Aftab A. Siddiqui On Wed, Nov 23, 2011 at 6:46 PM, Emilio Madaio > wrote: Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-06 We encourage you to review this proposal and send your comments to > before 21 December 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC +++++++++++++++++++++++++++++++++++++++++++++ Disclaimer Dit e-mailbericht kan vertrouwelijke informatie bevatten of informatie die is beschermd door een beroepsgeheim. Indien dit bericht niet voor u is bestemd, wijzen wij u erop dat elke vorm van verspreiding, vermenigvuldiging of ander gebruik ervan niet is toegestaan. Indien dit bericht blijkbaar bij vergissing bij u terecht is gekomen, verzoeken wij u ons daarvan direct op de hoogte te stellen via tel.nr 070 315 3500 of e-mail mailto:mail at opta.nl en het bericht te vernietigen. Dit e-mailbericht is uitsluitend gecontroleerd op virussen. OPTA aanvaardt geen enkele aansprakelijkheid voor de feitelijke inhoud en juistheid van dit bericht en er kunnen geen rechten aan worden ontleend. This e-mail message may contain confidential information or information protected by professional privilege. If it is not intended for you, you should be aware that any distribution, copying or other form of use of this message is not permitted. If it has apparently reached you by mistake, we urge you to notify us by phone +31 70 315 3500 or e-mail mailto:mail at opta.nl and destroy the message immediately. This e-mail message has only been checked for viruses. The accuracy, relevance, timeliness or completeness of the information provided cannot be guaranteed. OPTA expressly disclaims any responsibility in relation to the information in this e-mail message. No rights can be derived from this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-anti-spam-wg at powerweb.de Thu Nov 24 10:46:38 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 24 Nov 2011 10:46:38 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) - addtional needs In-Reply-To: References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> Message-ID: <4ECE127E.9060309@powerweb.de> Hi, Suresh Ramasubramanian wrote: > it is an interesting question, followed by the 'what is ripe to do in cases where is requirement isnt complied with, or where it is fraudulent' question At least an abuse-c is much nicer to parse for the normal people than an IRT object, because it will appear in the normal whois output for any IP asked for. And its surely useable automatically. And a required abuse object is really needed anyway ... The proposal should also answer the following question: - are abuse remarks, the abuse-mailbox field or IRT-abuse field depricated or could they be used beside the non mandatory abuce-c - will there be any kind of automatic migration of existing abuse contact to the abuse-c ? - will it be possible for an LIR to select something like: (x) use the following default abuse-c for all inetnum objects: ______ if there is non explicitly specified ? - how or who will test, if an abuce-c is correct ? - will the whois state, who to contact (or wich URL to visit), if an abuse-c isnt reachable or correct ? - what is happening, if the abuce-c isnt correct ? This all leads to the old question if the RIPE NCC is willing to punish LIRs, that do not answer abuse reports. Kind regards, Frank > --srs (iPad) > > On 23-Nov-2011, at 20:18, Leo Vegoda wrote: > >> Hi, >> >> The proposed policy text includes: >> >> "The role objects used for abuse contact information will be required to contain a single "abuse-mailbox:" attribute which is intended for receiving automatic and manual reports about abusive behavior originating the resource holders' networks." >> >> Do the proposers intend the requirement for the "abuse-mailbox:" attribute to be enforced in any way and if so, how? >> >> Thanks, >> >> Leo >> > > > > -- Mit freundlichen Gruessen, -- 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 From tk at abusix.com Thu Nov 24 12:41:14 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 12:41:14 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> Message-ID: <4ECE2D5A.5030400@abusix.com> Hello all, thanks for the already ongoing discussion about the new abuse contact policy proposal. I will try to clarify some things. We had some really technical discussions about this with database people from RIPE NCC and came up with this idea. So let's have a look at it. If we use a person object as an example, this person object can be referenced for example by an admin-c or tech-c attribute at the moment. In future it can be referenced by the abuse-c as well, BUT to create this reference the person objects needs to have an abuse-mailbox attribute. If there is no abuse-mailbox attribute it can not be referenced by the abuse-c. This will be done by the business logic. Same when you query for an ip range - admin-c, tech-c and abuse-c can be the same person, but output will show an abuse-mailbox attribute in the abuse-c part. So at the end it is only a matter, if the attributes requested by the business rules are existing for the intended use of the object. I will answer the other questions on the mailing list directly. Just wanted to give a real quick overview about the technical idea of the Task Force and RIPE NCC. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Thu Nov 24 12:51:24 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 12:51:24 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECD1E97.90004@ja.net> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> Message-ID: <4ECE2FBC.6010806@abusix.com> Hi all, > At the start of the proposal it mentions "it is not clear in which of > these role objects it should be preferred.", but it's not clear to me > at by the end of the document why I should prefer an abuse-c attribute > to an irt object. The IRT Object was degraded in the last few years. For example the creation process was made pretty simple to allow more people to use it as a abuse-c. The idea would be to go back to the original intent of an IRT Object. So if you are running a cert I would suggest using the IRT, if you are running an abuse department I would suggest using the abuse-c and if you are running both, like many huge ISPs already do, I would suggest to use both. > Also: "there will be some automated clean up of users data to > reorganize abuse contact references where possible." Is that expanded > on anywhere? The clean up will be pretty tricky. We can not clean up remark fields with abuse contact data. But we could for example ask members if the remark fields are still required, if the remark field contains something with "abuse" as soon as they make changes. We would like to clean up as much as possible in an automatic way, but if that is not possible it has to bee looked at in a specific way. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ripe-wg-antiabuse at kyubu.de Thu Nov 24 14:08:39 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 24 Nov 2011 14:08:39 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE2FBC.6010806@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> Message-ID: <20111124130839.GA32454@core.kyubu.de> On Thu, Nov 24, 2011 at 12:51:24PM +0100, Tobias Knecht wrote: Hi, > > at by the end of the document why I should prefer an abuse-c attribute > > to an irt object. > > The IRT Object was degraded in the last few years. For example the > creation process was made pretty simple to allow more people to use it > as a abuse-c. The idea would be to go back to the original intent of an > IRT Object. So if you are running a cert I would suggest using the IRT, > if you are running an abuse department I would suggest using the abuse-c > and if you are running both, like many huge ISPs already do, I would > suggest to use both. This approach would be quite contrary to goals of the proposal (such as: ".. it helps all kinds of institutions to find the correct abuse contact information more easily"). Most users cannot distinguish between a CERT or an abuse department. Also, I cannot see why implementing another object holding the same data as an IRT would make things better. Cheers, Adrian From ripe-wg-antiabuse at kyubu.de Thu Nov 24 14:17:06 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 24 Nov 2011 14:17:06 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) - addtional needs In-Reply-To: <4ECE127E.9060309@powerweb.de> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE127E.9060309@powerweb.de> Message-ID: <20111124131706.GB32454@core.kyubu.de> On Thu, Nov 24, 2011 at 10:46:38AM +0100, Frank Gadegast wrote: hi, > At least an abuse-c is much nicer to parse for the normal people than > an IRT object, because it will appear in the normal whois output for > any IP asked for. This is also true for the IRT object. Parsing is as easy as parsing any other object. > - how or who will test, if an abuce-c is correct ? > - will the whois state, who to contact (or wich URL to visit), > if an abuse-c isnt reachable or correct ? > - what is happening, if the abuce-c isnt correct ? Thanks for bringing up these questions. Trusted Introducer solved all of these some time ago. Cheers, Adrian From jorgen at hovland.cx Thu Nov 24 16:15:37 2011 From: jorgen at hovland.cx (=?ISO-8859-15?Q?J=F8rgen_Hovland?=) Date: Thu, 24 Nov 2011 16:15:37 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) In-Reply-To: <4ECE2D5A.5030400@abusix.com> References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> <4ECE2D5A.5030400@abusix.com> Message-ID: <4ECE5F99.2050009@hovland.cx> Hello, On 11/24/11 12:41, Tobias Knecht wrote: > Hello all, > > thanks for the already ongoing discussion about the new abuse contact > policy proposal. I will try to clarify some things. > > We had some really technical discussions about this with database people > from RIPE NCC and came up with this idea. > > So let's have a look at it. > > If we use a person object as an example, this person object can be > referenced for example by an admin-c or tech-c attribute at the moment. > > In future it can be referenced by the abuse-c as well, BUT to create > this reference the person objects needs to have an abuse-mailbox > attribute. If there is no abuse-mailbox attribute it can not be > referenced by the abuse-c. This will be done by the business logic. > Why is an abuse-mailbox attribute needed at all? The whole object is an abuse-c. Everything in it is to be used as abuse contact. This also includes, but is not limited to, telephone numbers, postal address, fax etc. There is already an email attribute. If I remember correctly, this attribute is not mandatory - which is fine by me for now. Cheers, From tk at abusix.com Thu Nov 24 14:30:49 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 14:30:49 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111124130839.GA32454@core.kyubu.de> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> Message-ID: <4ECE4709.1030403@abusix.com> Hi again, > This approach would be quite contrary to goals of the proposal (such > as: ".. it helps all kinds of institutions to find the correct abuse > contact information more easily"). Most users cannot distinguish > between a CERT or an abuse department. > > Also, I cannot see why implementing another object holding the same > data as an IRT would make things better. You are quite right. At the moment, but few years ago, the IRT object was not intended for abuse departments handling outbound abuse. IRT was originally intended for certs exchange information about security issues. And that is exactly what the IRT should be again, with all the security measures, that were mandatory at the very beginning and got canceled over time. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Thu Nov 24 14:44:51 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 14:44:51 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) In-Reply-To: <4ECE5F99.2050009@hovland.cx> References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> <4ECE2D5A.5030400@abusix.com> <4ECE5F99.2050009@hovland.cx> Message-ID: <4ECE4A53.4070206@abusix.com> Hi, > Why is an abuse-mailbox attribute needed at all? > The whole object is an abuse-c. Everything in it is to be used as abuse > contact. > This also includes, but is not limited to, telephone numbers, postal > address, fax etc. > There is already an email attribute. If I remember correctly, this > attribute is not mandatory - which is fine by me for now. The idea is to use the abuse-mailbox attribute for automated complaints and the email attribute for human conversations. The main difference would take part in the query process, while the email attribute will be handled as personal data the abuse-mailbox attribute could be queried unrestricted. This makes it very easy for abuse reporters to automate these mechanisms. The mailbox for human conversations could be secured with a spamfilter. That gives spammer a smaller chance to deliver their junk and it makes it pretty hard for "VIPs" to send their spam complaints to the wrong address to gain more attention. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Thu Nov 24 14:53:14 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 14:53:14 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> Message-ID: <4ECE4C4A.5090106@abusix.com> Hi, > Do the proposers intend the requirement for the "abuse-mailbox:" > attribute to be enforced in any way and if so, how? Not having an abuse-mailbox attribute in any object will lead to not being able to reference an object by the abuse-c. Because business rules will request this. So the questions is just what will happen if somebody does not have an abuse-c. Since the "abuse-c:" is obligatory, the usual RIPE NCC rules would apply (not compliance would constitute policy infringement and would lead to the deregistration of the relevant resources, as described in the closure and deregistration document under the section c.Incorrect registration of the allocation/assignment in the RIPE Database: https://www.ripe.net/ripe/docs/ripe-517#b11c and https://www.ripe.net/ripe/docs/ripe-517#b2 But please keep in mind, that this process has nothing to do with the proposal itself. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ripe-wg-antiabuse at kyubu.de Thu Nov 24 14:54:40 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 24 Nov 2011 14:54:40 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE4709.1030403@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> Message-ID: <20111124135440.GC32454@core.kyubu.de> On Thu, Nov 24, 2011 at 02:30:49PM +0100, Tobias Knecht wrote: hi, > You are quite right. At the moment, but few years ago, the IRT object > was not intended for abuse departments handling outbound abuse. IRT was > originally intended for certs exchange information about security > issues. Yet, a _single_ point of contact (mail, fax, phone, you name it) should is provided. The way abuse-related information is processed internally (outbound abuse communication vs. information sharing between teams) in institutions cannot (and won't) be solved in whois. > And that is exactly what the IRT should be again, with all the > security measures, that were mandatory at the very beginning and got > canceled over time. I am surprised, you have any examples for IRT objects were these measures were dropped? Cheers, Adrian From tk at abusix.com Thu Nov 24 15:06:53 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 15:06:53 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111124135440.GC32454@core.kyubu.de> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> Message-ID: <4ECE4F7D.8070105@abusix.com> Hi, > Yet, a _single_ point of contact (mail, fax, phone, you name it) > should is provided. The way abuse-related information is processed > internally (outbound abuse communication vs. information sharing > between teams) in institutions cannot (and won't) be solved in > whois. We do not want to solve it within whois, but we want to give the different teams the opportunity to publish their information. Many huge ISPs have a cert and an abuse department, which are sometimes located in different cities and do completely different work. A cert does want to contact the other cert and not the abuse department. A spamrun should be reported to the abuse department. In my personal opinion every ISP should have an abuse department to solve outbound abuse issues. And that is the abuse-c part and that why this is mandatory. If an ISP can afford or need a cert, he can publish this in whois as well. >> And that is exactly what the IRT should be again, with all the >> security measures, that were mandatory at the very beginning and >> got canceled over time. > > I am surprised, you have any examples for IRT objects were these > measures were dropped? If you look at this really old document http://www.ripe.net/data-tools/db/irt/ripe-irt-object-technical-how-to/#113 you will find under point 1.1.4 that signature, encryption and auth are mandatory fields, which they are not any more today. At least one of them is not mandatory anymore today. Couldn't find documentation at the moment. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Thu Nov 24 15:13:56 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 15:13:56 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <4eccf969.25ebd80a.521a.ffffff90SMTPIN_ADDED@mx.google.com> Message-ID: <4ECE5124.6090002@abusix.com> Hi, > It states "The syntax will make this an optional attribute". We are > dealing with inconsistent records even making it mandatory in the APNIC > region. How would it help? or I didn't understand properly, can anyone > elaborate? The syntax will make this an optional attribute means that you do not need it, but it will be required for the abuse-c You have a personal obejct which you use for tech-c and admin-c. Today you add an optional abuse-mailbox attribute to your object and it will show up twice while querying. In future it would be like this. If you want to use the same personal object for the abuse-c, the abuse-mailbox attribute will be optional for the personal object, but you would need it to link it with an abuse-c. So, yes it is optional for the object itself, but if you want to use the object for abuse-c you have to have it. Thanks, Tobias -- abusix > Regards, > > Aftab A. Siddiqui > > > On Wed, Nov 23, 2011 at 6:46 PM, Emilio Madaio > wrote: > > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-06 > > We encourage you to review this proposal and send your comments to > > before 21 > December 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ripe-wg-antiabuse at kyubu.de Thu Nov 24 15:23:10 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 24 Nov 2011 15:23:10 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE4F7D.8070105@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> Message-ID: <20111124142310.GD32454@core.kyubu.de> On Thu, Nov 24, 2011 at 03:06:53PM +0100, Tobias Knecht wrote: hi, > If you look at this really old document > http://www.ripe.net/data-tools/db/irt/ripe-irt-object-technical-how-to/#113 > you will find under point 1.1.4 that signature, encryption and auth are > mandatory fields, Yes, I was aware of this document. > which they are not any more today. At least one of > them is not mandatory anymore today. Couldn't find documentation at the > moment. IIRC, TI is the the one and only body to maintain IRT-objects. And, all of the above contraints are still mandatory. (At least they were until 11/2010). Cheers, Adrian From james.davis at ja.net Thu Nov 24 15:27:43 2011 From: james.davis at ja.net (James Davis) Date: Thu, 24 Nov 2011 14:27:43 +0000 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE4F7D.8070105@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> Message-ID: <4ECE545F.7030700@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/11/2011 14:06, Tobias Knecht wrote: > Many huge ISPs have a cert and an abuse department, which are > sometimes located in different cities and do completely different > work. A cert does want to contact the other cert and not the abuse > department. A spamrun should be reported to the abuse department. You have an ideas about the difference in work that certs and abuse departments do, but I'm sure that we all have slightly different definitions. These differences are likely to be extremely subtle to someone outside of the CSIRT and abuse communities. I'm not convinced that the differences in these roles are is in fact obvious, or that the choice between either or both of these roles is clear to a new member of the RIPE community or someone reporting a network event. I think I understand what you are trying to achieve by having these two options available, but we need to be sure that this choice makes it easier for people involved at all stages to do the right thing. James - -- James Davis 0300 999 2340 (+44 1235 822340) Senior CSIRT Member Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7OVF8ACgkQjsS2Y6D6yLy35QEAzRbYrfwTydTAhPF/WTDpya0c 6MA5L/JXBi+LIDU6cIIA/AvRNB2igak4Rkvc3+yODRDGQArOgVP2tBSZpvaWrAhu =wxtX -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Woeber at CC.UniVie.ac.at Thu Nov 24 15:14:01 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Nov 2011 14:14:01 +0000 Subject: [anti-abuse-wg] "www.canay.tv" is doing privacy violation In-Reply-To: References: Message-ID: <4ECE5129.9080500@CC.UniVie.ac.at> ..."lawyers" using a gmail identity? Do I smell a hoax or troll? Wilfried. eser r?zgar wrote: > Hey All, > > We are Eren AMBARK?T?K's lawyers. We tracked "www.canay.com > " domain name for a long time. because, that > domain name was published some photo which related our client's photo. > At the end of the story, The Turkey Telecommunications Office was gave a > notification "www.canay.com " because of our claim > about privacy violation of Eren AMBARK?T?K's fotographs. Now, we can > access the same photos with "www.canay.tv ". Your > company is service provider of www.canay.tv and we > kindly claming you that remove that domin name.if not, we have to sue > www.canay.tv and their service provider. You can > see the links which include abuse usages as follow: > > > > 1. http://www.canay.tv/category/ebru-salli-frikik-video-ebruli-tv8/ > 2. http://www.canay.tv/2011/03/22/ebru-salli-ve-eren-ambarkutukle-pilates-ebruli/ > 3. http://www.canay.tv/2011/05/24/eren-ambarkutuk-gogus-pilates-ebruli/ > 4. http://www.canay.tv/2011/04/22/eren-ambarkutuk-tangasi-ve-ayrintilari-ebruli/ > 5. http://www.canay.tv/2011/05/09/eren-ambarkutuk-pilates-guzeli-ebruli/ > 6. http://www.canay.tv/2011/03/31/eren-ambarkutukten-pilates-teknikleri-ebruli/ > 7. http://www.canay.tv/2011/07/28/eren-ambarkutuk-bacaklar-ve-pilates-ebruli/ > 8. http://www.canay.tv/2011/04/26/eren-ambarkutuk-nefes-al-nefes-ver-ebruli/ > 9. http://www.canay.tv/2011/06/21/eren-ambarkutuk-seffaf-tayt-cameltoe-ebruli/ > > > > > Eser R?ZGAR > Attornet at Law at ?stanbul Bar Association > Trade Mark Expert at Turkish Patent Institute > > > > From ripe-wg-antiabuse at kyubu.de Thu Nov 24 15:31:19 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 24 Nov 2011 15:31:19 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact In-Reply-To: <201111241417.pAOEHGZJ027878@powerweb.de> References: <20111124131706.GB32454@core.kyubu.de> <201111241417.pAOEHGZJ027878@powerweb.de> Message-ID: <20111124143119.GE32454@core.kyubu.de> On Thu, Nov 24, 2011 at 03:17:16PM +0100, Dipl-Inform. Frank Gadegast wrote: hi, > What is "Trusted Introducer" ? > Do you mean trusted-introducer.org ? Yes. > How can this "punish" bad LIRs ? RIPE is not involved in that. Sorry, this wasn't meant to "punish" bad LIRs, but to find (and maintain) the relevant contact informaton in terms of abuse handling. Cheers, Adrian From james.davis at ja.net Thu Nov 24 15:31:43 2011 From: james.davis at ja.net (James Davis) Date: Thu, 24 Nov 2011 14:31:43 +0000 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111124142310.GD32454@core.kyubu.de> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> <20111124142310.GD32454@core.kyubu.de> Message-ID: <4ECE554F.8050902@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/11/2011 14:23, Adrian wrote: > TI is the the one and only body to maintain IRT-objects. And, all > of the above contraints are still mandatory. (At least they were > until 11/2010). IIRC and if I'm reading the document correctly anyone can create an IRT object but I've rarely if at all seen one used outside of the TI community, and most TI members let TI create their IRT objects. I wasn't really active in the TI community at the time this started so I may be completely wrong :) James - -- James Davis 0300 999 2340 (+44 1235 822340) Senior CSIRT Member Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7OVU8ACgkQjsS2Y6D6yLxusAD/YykWudbZCyqVPqzrntVn3V6H u0dVvHzXztFNIg4wnZoA/jh4ysXk2rrz8sIoGK61lgfcURu94BHvAlyq3y/0PgFl =GhoS -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From tk at abusix.com Thu Nov 24 15:47:35 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 15:47:35 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE545F.7030700@ja.net> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> <4ECE545F.7030700@ja.net> Message-ID: <4ECE5907.3030305@abusix.com> Hi, >> Many huge ISPs have a cert and an abuse department, which are >> sometimes located in different cities and do completely different >> work. A cert does want to contact the other cert and not the abuse >> department. A spamrun should be reported to the abuse department. > > You have an ideas about the difference in work that certs and abuse > departments do, but I'm sure that we all have slightly different > definitions. These differences are likely to be extremely subtle to > someone outside of the CSIRT and abuse communities. > > I'm not convinced that the differences in these roles are is in fact > obvious, or that the choice between either or both of these roles is > clear to a new member of the RIPE community or someone reporting a > network event. I think I understand what you are trying to achieve by > having these two options available, but we need to be sure that this > choice makes it easier for people involved at all stages to do the > right thing. And that is exactly what we are trying to do. ;-) First of all the abuse-c (Abuse Contact) gives a better idea that it is a Contact about Abuse, than mnt-IRT will ever do. New members or people outside the abuse community should be able to understand it more easily. Creating an abuse-c is much more easy than creating an IRT object. Using the abuse-finder tool giving back the abuse-mailbox attribute of the abuse-c will help RIPE NCC to reduce Queries in the DB and makes things for people much more easy to query for. It makes the hole person, role, organization object mechanism much more easy, than it is at the moment. The whole cleanup will lead to easier understandable information and makes things easier. And at the end, if all the IRT Object holders show up and say we do not need the irt object anymore as soon as we have an abuse-c in place, there would not be a reason to keep the irt any longer. This is not part of this proposal, but the abuse-c will make things more understandable, than the IRT. Don't get me wrong, I do not want to get rid of the IRT, just mentioning the possibilities. Why we are not using the IRT and make it mandatory? There have been several reasons for this. We also discussed about this option for a while. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Thu Nov 24 15:51:39 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 15:51:39 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <4eccf969.25ebd80a.521a.ffffff90SMTPIN_ADDED@mx.google.com> Message-ID: <4ECE59FB.8090300@abusix.com> > - The PA ranges are not included in this range; I heavily suspect > however that in the PA allocations the problem with > incorrect/unreachable abuse details is by far the largest (think shady > LIRs subdelegating IP space. A very common business model). This policy > should make an effort to try to touch the PA IP space too. Right. That is on intention. The request was to have at least on contact for every ip address. We do not want to force every single range to publish the data. The hierarchy will always take the most recent contact information. > - A reference to, or a summary of the document containing the > ?business rules? would help clarify the exact requirements. I tried to explain it in another thread today. At the end the business rule will be responsible to check if an abuse-maibox attribute is set and if yes, the object can be used as abuse-c and if not, it can not be used for an abuse-c. The whole business rule idea, gives us the opportunity to stay within this model for whatever will show up in future. > - As mentioned before, what in case of non-compliance? The policy > should state, or reference to, that too. The RIPE NCC process will start and RIPE tries to solve the issue with the member. If there is no cooperation, this can go down until the deregistration. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From james.davis at ja.net Thu Nov 24 15:59:28 2011 From: james.davis at ja.net (James Davis) Date: Thu, 24 Nov 2011 14:59:28 +0000 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE5907.3030305@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> <4ECE545F.7030700@ja.net> <4ECE5907.3030305@abusix.com> Message-ID: <4ECE5BD0.8000008@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/11/2011 14:47, Tobias Knecht wrote: > First of all the abuse-c (Abuse Contact) gives a better idea that > it is a Contact about Abuse, than mnt-IRT will ever do. New members > or people outside the abuse community should be able to understand > it more easily. Agreed. In fact it's something I can get quite vocal about at times - terms like IRT, CERT, CSIRT are only useful within our communities and do not make it easier for people to find the help they need from us. > Creating an abuse-c is much more easy than creating an IRT object I can agree with that too. > And at the end, if all the IRT Object holders show up and say we do > not need the irt object anymore as soon as we have an abuse-c in > place, there would not be a reason to keep the irt any longer. If this proposal was adopted then I can't see the IRT object being widely adopted outside of the TI community. I'm not saying that this is a good or a bad thing but readers of the proposal should be made aware of this. I think it needs to be mentioned in the proposal as an argument against it. That would at least acknowledge how you think this proposal will lessen the confusion of how to publish contact information and not simply add another choice into the confusion. James - -- James Davis 0300 999 2340 (+44 1235 822340) Senior CSIRT Member Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7OW9AACgkQjsS2Y6D6yLzgCwD/fhHbVwchw388lGJndZttVlpC YQo6uQEB1N1vDzqF9A8A/ixXOifH5Cw7abYyy1ndIuCj07xiW3OIU5C+QBoJZgdp =yuop -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From tk at abusix.com Thu Nov 24 16:06:17 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 16:06:17 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE5BD0.8000008@ja.net> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> <4ECE545F.7030700@ja.net> <4ECE5907.3030305@abusix.com> <4ECE5BD0.8000008@ja.net> Message-ID: <4ECE5D69.6080902@abusix.com> Hi, >> And at the end, if all the IRT Object holders show up and say we do >> not need the irt object anymore as soon as we have an abuse-c in >> place, there would not be a reason to keep the irt any longer. > > If this proposal was adopted then I can't see the IRT object being > widely adopted outside of the TI community. I'm not saying that this > is a good or a bad thing but readers of the proposal should be made > aware of this. I think it needs to be mentioned in the proposal as an > argument against it. It was over all not widely adopted until now. I do not know how much IRT Objects we ave at the moment and how much percent of the IP space they cover. But you are right, I think this could be added as an argument against it. I have made a notice and I will add it with the next version. Thanks for mentioning it. > That would at least acknowledge how you think this proposal will > lessen the confusion of how to publish contact information and not > simply add another choice into the confusion. True. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ripe-wg-antiabuse at kyubu.de Thu Nov 24 16:28:22 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 24 Nov 2011 16:28:22 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE5D69.6080902@abusix.com> References: <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> <4ECE545F.7030700@ja.net> <4ECE5907.3030305@abusix.com> <4ECE5BD0.8000008@ja.net> <4ECE5D69.6080902@abusix.com> Message-ID: <20111124152822.GF32454@core.kyubu.de> On Thu, Nov 24, 2011 at 04:06:17PM +0100, Tobias Knecht wrote: Hi, > It was over all not widely adopted until now. I do not know how much IRT In Germany, every institution being hooked up by DFN is provided an IRT-object. This may be applicable for other european NRENs as well. Cheers, Adrian From tk at abusix.com Thu Nov 24 17:49:44 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 24 Nov 2011 17:49:44 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111124152822.GF32454@core.kyubu.de> References: <4ECD1E97.90004@ja.net> <4ECE2FBC.6010806@abusix.com> <20111124130839.GA32454@core.kyubu.de> <4ECE4709.1030403@abusix.com> <20111124135440.GC32454@core.kyubu.de> <4ECE4F7D.8070105@abusix.com> <4ECE545F.7030700@ja.net> <4ECE5907.3030305@abusix.com> <4ECE5BD0.8000008@ja.net> <4ECE5D69.6080902@abusix.com> <20111124152822.GF32454@core.kyubu.de> Message-ID: <4ECE75A8.9050907@abusix.com> >> It was over all not widely adopted until now. I do not know how >> much IRT > > In Germany, every institution being hooked up by DFN is provided an > IRT-object. This may be applicable for other european NRENs as well. Yes maybe, but how big is the piece of the whole RIPE IP Space? I have something in mind about 210 IRT objects overall. But can't find the stats on RIPE Labs at the moment. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From kzorba at otenet.gr Fri Nov 25 10:13:38 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Fri, 25 Nov 2011 11:13:38 +0200 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE2D5A.5030400@abusix.com> (Tobias Knecht's message of "Thu, 24 Nov 2011 12:41:14 +0100") References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> <4ECE2D5A.5030400@abusix.com> Message-ID: <87ty5simyl.fsf@enigma.otenet.gr> Tobias Knecht writes: Hello Tobias, nice to see a progress in this area, coming in the form of a proposal. Other people in this thread have more or less covered my questions. However, it is my general feeling that while the essence of the idea was explained in the thread it is not reflected well in the proposal wording. To me only by reading the proposal it is not clear that - the proposed approach is to replace all other alternatives and become THE reference point for abuse contacts - what exactly the transition period will be and what might be required by the relevant users and the RIPE NCC (this might also be added as an argument opposing the proposal) - what exactly happens in case someone does not comply after the transition period I also think that it is a good idea the rational of the Task Force to come up with this solution be presented in the policy text. Thanks for all your work and of course I think that the proposal moves toward the right direction. I only feel that the proposal wording needs some extra work. Just my 2 cents :) Regards, Kostas > Hello all, > > thanks for the already ongoing discussion about the new abuse contact > policy proposal. I will try to clarify some things. > > We had some really technical discussions about this with database people > from RIPE NCC and came up with this idea. > > So let's have a look at it. > > If we use a person object as an example, this person object can be > referenced for example by an admin-c or tech-c attribute at the moment. > > In future it can be referenced by the abuse-c as well, BUT to create > this reference the person objects needs to have an abuse-mailbox > attribute. If there is no abuse-mailbox attribute it can not be > referenced by the abuse-c. This will be done by the business logic. > > Same when you query for an ip range - admin-c, tech-c and abuse-c can be > the same person, but output will show an abuse-mailbox attribute in the > abuse-c part. > > So at the end it is only a matter, if the attributes requested by the > business rules are existing for the intended use of the object. > > > I will answer the other questions on the mailing list directly. Just > wanted to give a real quick overview about the technical idea of the > Task Force and RIPE NCC. > > Thanks, > > Tobias -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\ From tk at abusix.com Fri Nov 25 11:31:00 2011 From: tk at abusix.com (Tobias Knecht) Date: Fri, 25 Nov 2011 11:31:00 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <87ty5simyl.fsf@enigma.otenet.gr> References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> <4ECE2D5A.5030400@abusix.com> <87ty5simyl.fsf@enigma.otenet.gr> Message-ID: <4ECF6E64.6090009@abusix.com> Hi Kostas, > - the proposed approach is to replace all other alternatives and become > THE reference point for abuse contacts That is true, I will add this to the proposal in the next version. > - what exactly the transition period will be and what might be required > by the relevant users and the RIPE NCC (this might also be added as an > argument opposing the proposal) This is an operational issue and can not be a 100% defined at this point. The idea is, to transfer as much information as possible to the system automatically. So from this point we could for example use a admin-c or tech-c object that has already an abuse-mailbox as abuse-c as well. That is one possibility. There probably will be a notification of all members. There will be a cleanup process. But at the moment it is much to early to define these things. And in addition to that, the process of implementing and transition should not be part of the policy, because once the policy is in place and all transitions have been made, nobody will care about it anymore. > - what exactly happens in case someone does not comply after the > transition period Same what happens if somebody does not comply with any other policy. RIPE NCC will take care with the already defined processes that are in place right at the moment. > I also think that it is a good idea the rational of the Task Force > to come up with this solution be presented in the policy text. > Thanks for all your work and of course I think that the proposal moves > toward the right direction. I only feel that the proposal wording > needs some extra work. In pieces I think you are right, but we should not put together things that are not belonging together. The policy is about adding an abuse-c in a specific way. The implementation will be added by RIPE NCC and what happens when is also coming from already existing RIPE NCC processes. But I will add the mentioned part to the proposal. Thanks for your feedback, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From aftab.siddiqui at gmail.com Fri Nov 25 11:53:47 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Fri, 25 Nov 2011 15:53:47 +0500 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECF6E64.6090009@abusix.com> References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> <4ECE2D5A.5030400@abusix.com> <87ty5simyl.fsf@enigma.otenet.gr> <4ECF6E64.6090009@abusix.com> Message-ID: Hi Tobias, > This is an operational issue and can not be a 100% defined at this > point. The idea is, to transfer as much information as possible to the > system automatically. So from this point we could for example use a > admin-c or tech-c object that has already an abuse-mailbox as abuse-c as > well. That is one possibility. There probably will be a notification of > all members. There will be a cleanup process. But at the moment it is > much to early to define these things. And in addition to that, the > process of implementing and transition should not be part of the policy, > because once the policy is in place and all transitions have been made, > nobody will care about it anymore. > Yes, I agree its an operational issue, but there must be some deliberation from the RIPE NCC team regarding the implementation. > Same what happens if somebody does not comply with any other policy. > RIPE NCC will take care with the already defined processes that are in > place right at the moment. > > > And it doesn't involve the correctness of information provided and incorrect info will be dealt with in the same manner? right? again its an operational thing. Regards, Aftab A. Siddiqui -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Fri Nov 25 12:24:54 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 25 Nov 2011 16:54:54 +0530 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> <4ECE2D5A.5030400@abusix.com> <87ty5simyl.fsf@enigma.otenet.gr> <4ECF6E64.6090009@abusix.com> Message-ID: +1 .. i fully agree that this aspect needs to be thought out first --srs (iPad) On 25-Nov-2011, at 16:23, Aftab Siddiqui wrote: > > Hi Tobias, > > This is an operational issue and can not be a 100% defined at this > point. The idea is, to transfer as much information as possible to the > system automatically. So from this point we could for example use a > admin-c or tech-c object that has already an abuse-mailbox as abuse-c as > well. That is one possibility. There probably will be a notification of > all members. There will be a cleanup process. But at the moment it is > much to early to define these things. And in addition to that, the > process of implementing and transition should not be part of the policy, > because once the policy is in place and all transitions have been made, > nobody will care about it anymore. > > Yes, I agree its an operational issue, but there must be some deliberation from the RIPE NCC team regarding the implementation. > > Same what happens if somebody does not comply with any other policy. > RIPE NCC will take care with the already defined processes that are in > place right at the moment. > > > > > And it doesn't involve the correctness of information provided and incorrect info will be dealt with in the same manner? right? again its an operational thing. > > Regards, > > Aftab A. Siddiqui -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Mon Nov 28 20:00:26 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 28 Nov 2011 11:00:26 -0800 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE4C4A.5090106@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> Hi Tobias, [...] > So the questions is just what will happen if somebody does not have an > abuse-c. Since the "abuse-c:" is obligatory, the usual RIPE NCC rules > would apply (not compliance would constitute policy infringement and > would lead to the deregistration of the relevant resources, as described > in the closure and deregistration document under the section c.Incorrect > registration of the allocation/assignment in the RIPE Database: > https://www.ripe.net/ripe/docs/ripe-517#b11c and > https://www.ripe.net/ripe/docs/ripe-517#b2 > > But please keep in mind, that this process has nothing to do with the > proposal itself. Can you please clarify if the only requirement is that an abuse-c be published? For instance, if an LIR published an abuse-c with 100% bogus contact data, would that meet the requirements and so avoid the address space being reclaimed? Thanks, Leo From tk at abusix.com Mon Nov 28 22:08:21 2011 From: tk at abusix.com (Tobias Knecht) Date: Mon, 28 Nov 2011 22:08:21 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> Message-ID: <4ED3F845.6080708@abusix.com> Hi, > Can you please clarify if the only requirement is that an abuse-c be > published? For instance, if an LIR published an abuse-c with 100% > bogus contact data, would that meet the requirements and so avoid the > address space being reclaimed? The reqiurement that is defined in the proposal is that an abuse-c has to be published. The abuse-c will reference a person, role or organization object. The abuse-c is not an object itself. This means, the bogus data will be handled in the same way bogus data is handled by RIPE NCC. Hope this clarifies your question. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From leo.vegoda at icann.org Mon Nov 28 22:24:33 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 28 Nov 2011 13:24:33 -0800 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED3F845.6080708@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> Hi Tobias, You wrote: > > Can you please clarify if the only requirement is that an abuse-c be > > published? For instance, if an LIR published an abuse-c with 100% > > bogus contact data, would that meet the requirements and so avoid the > > address space being reclaimed? > > The reqiurement that is defined in the proposal is that an abuse-c has > to be published. The abuse-c will reference a person, role or > organization object. The abuse-c is not an object itself. > > This means, the bogus data will be handled in the same way bogus data is > handled by RIPE NCC. > > Hope this clarifies your question. No, it doesn't really answer my question. I am no longer familiar with the way the RIPE NCC handles bogus data published in the database but as you are proposing that failure to comply with the policy should lead to deregistration, it seems only reasonable that the proposers should explicitly state what they intend to happen in various circumstances. I want to know whether this is proposal is going to result in large amounts of unmaintained data of questionable quality being registered, or whether some kind of maintenance process is envisaged and if so what that should be. Leo From tk at abusix.com Mon Nov 28 22:41:35 2011 From: tk at abusix.com (Tobias Knecht) Date: Mon, 28 Nov 2011 22:41:35 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> Message-ID: <4ED4000F.2030800@abusix.com> Hi, > No, it doesn't really answer my question. I am no longer familiar > with the way the RIPE NCC handles bogus data published in the > database but as you are proposing that failure to comply with the > policy should lead to deregistration, it seems only reasonable that > the proposers should explicitly state what they intend to happen in > various circumstances. > > I want to know whether this is proposal is going to result in large > amounts of unmaintained data of questionable quality being > registered, or whether some kind of maintenance process is envisaged > and if so what that should be. I'm and the Task Force are not proposing anything about bogus data. The proposal is proposing to introduce an abuse-c with some special features. What happens with bogus data is not and can not be part of this proposal. I fully understand that this is an issue that has to be covered, but not within this proposal. RIPE NCC has processes in place that cover these issues and as far as I know, is steadily working on improving these to increase data quality. If there is a need for changes in these processes, this should be covered by another proposal. In my personal opinion the proposal has a chance to increase data quality. Since there is not a new object and the existing objects can be used but have to be "upgraded" with the abuse-mailbox attribute. There is a need for maintainers to go over at least the objects they want to use for abuse-c and review the data given. But that is a personal opinion. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From leo.vegoda at icann.org Mon Nov 28 23:08:40 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 28 Nov 2011 14:08:40 -0800 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED4000F.2030800@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> Tobias, You wrote: > > No, it doesn't really answer my question. I am no longer familiar > > with the way the RIPE NCC handles bogus data published in the > > database but as you are proposing that failure to comply with the > > policy should lead to deregistration, it seems only reasonable that > > the proposers should explicitly state what they intend to happen in > > various circumstances. > > > > I want to know whether this is proposal is going to result in large > > amounts of unmaintained data of questionable quality being > > registered, or whether some kind of maintenance process is envisaged > > and if so what that should be. > > I'm and the Task Force are not proposing anything about bogus data. The > proposal is proposing to introduce an abuse-c with some special > features. What happens with bogus data is not and can not be part of > this proposal. I fully understand that this is an issue that has to be > covered, but not within this proposal. You previously wrote, that "If there is no cooperation, this can go down until the deregistration." I don't see how a threat of deregistration fits alongside a statement that dealing with bogus data is outside the scope of your proposal. > RIPE NCC has processes in place that cover these issues and as far as I > know, is steadily working on improving these to increase data quality. > If there is a need for changes in these processes, this should be > covered by another proposal. I searched the RIPE NCC's web site and could not find any description of systemic processes for evaluating and improving the quality of registration data. Right now, I don't know whether your threat of deregistration is credible. However, I would suggest that if you want a data maintenance process to apply to the abuse-c object, then you should describe it. As you seem to want the RIPE NCC to remove the registration of address space if abuse-c's are not maintained appropriately, the standards required should be explicit and either included in the policy text or referenced by it. Regards, Leo From tk at abusix.com Tue Nov 29 08:12:57 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 29 Nov 2011 08:12:57 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> Message-ID: <4ED485F9.2070108@abusix.com> Leo, > You previously wrote, that "If there is no cooperation, this can go > down until the deregistration." I don't see how a threat of > deregistration fits alongside a statement that dealing with bogus > data is outside the scope of your proposal. Because you asked what will happen if there is no cooperation and I said that the new abuse-c will be handled in this case as every other object in the RIPE Database. The "what could happen" is described in this document (https://www.ripe.net/ripe/docs/ripe-517#b1). And this document is existing and already in use, so there is no need to describe the same things in our proposal again. And from that point of view dealing with bogus data is outside the scope of this proposal. >> RIPE NCC has processes in place that cover these issues and as far >> as I know, is steadily working on improving these to increase data >> quality. If there is a need for changes in these processes, this >> should be covered by another proposal. > > I searched the RIPE NCC's web site and could not find any description > of systemic processes for evaluating and improving the quality of > registration data. Right now, I don't know whether your threat of > deregistration is credible. However, I would suggest that if you want > a data maintenance process to apply to the abuse-c object, then you > should describe it. As you seem to want the RIPE NCC to remove the > registration of address space if abuse-c's are not maintained > appropriately, the standards required should be explicit and either > included in the policy text or referenced by it. If RIPE NCC is getting notified about bogus data in any of the objects, they first of all contact the responsible member and try to solve the issue that way. If this is not working and the member is not cooperative RIPE NCC can deregistrate. Nobody wants that to happen, but at the end it is the decision of RIPE NCC and I'm absolutely sure, that they take these things very serious. I do not know why this process is not described somewhere on the website or why you haven't been able to find it, if it is there. But I guess it is quite clear that RIPE NCC does not deregistrate members immediately without trying to get in contact first. If you think there is a need to have this process described in a paper we should ask RIPE NCC if they would mind to do it. Maybe they are already working on something, since the data accuracy issue is a big one and needs attention. Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From kzorba at otenet.gr Tue Nov 29 08:41:45 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Tue, 29 Nov 2011 09:41:45 +0200 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> (Leo Vegoda's message of "Mon, 28 Nov 2011 14:08:40 -0800") References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> Message-ID: <87sjl7cr46.fsf@enigma.otenet.gr> Leo Vegoda writes: > > However, I would suggest that if you want > a data maintenance process to apply to the abuse-c object, then you > should describe it. As you seem to want the RIPE NCC to remove the > registration of address space if abuse-c's are not maintained > appropriately, the standards required should be explicit and either > included in the policy text or referenced by it. > I think this is a valid argument. The proposal should contain the desired outcome as clear and explicitly as possible. And I don't think the desired outcome is to just have a role or person object referenced as the abuse contact, but to actually have abuse contacts. -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\ From pk at DENIC.DE Tue Nov 29 08:51:05 2011 From: pk at DENIC.DE (Peter Koch) Date: Tue, 29 Nov 2011 08:51:05 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE0666.8010502@restena.lu> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> Message-ID: <20111129075105.GM9075@x27.adm.denic.de> Gilles, On Thu, Nov 24, 2011 at 09:55:02AM +0100, Gilles Massen wrote: > This policy proposal seems a bit incomplete to, as it fails to address > the problem statement from the summary. thanks for pointing this out. There is a bit of confusion w.r.t. the target audience and intended goals. Let me give you my view. Any change we make to the DB schema or the Port 43 interface is unlikely to please the random end user who is looking for a target to report spam or other issues. Those are much better served by a service like the NCC's "abuse contact finder" tool, which in turn may benefit from a crisper data structure. But there is also a lot of (semi-)automated reporting going on between ISPs, CSIRTs and other entities, where timely detection, reporting and mitigation is crucial. Some of these use standardized message formats. Those are not well served by a web-based service or heuristics that may or may not end up with a "human" mailbox. And there's a range of grey between these examples. > >From the summary: "...it is not clear whether to use the > "abuse-mailbox:" attribute, the "remark:" attribute or an irt object.". > What is supposed to happen to IRT objects, or data from them? > > For existing records: at the very least it should be explicit which tags > should no longer be used or would be deprecated / removed in order to > give clear guidance. Both questions would be addressed in a migration plan, but my reading is that "abuse-mailbox" is going to disappear. > Another point: if the general idea of the policy is acceptable, wouldn't > it be nice to have 2 abuse mailboxes: one for humans, one for bots? +1; -Peter (again, not speaking for the TF) From tk at abusix.com Tue Nov 29 08:58:36 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 29 Nov 2011 08:58:36 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <87sjl7cr46.fsf@enigma.otenet.gr> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> <87sjl7cr46.fsf@enigma.otenet.gr> Message-ID: <4ED490AC.8020504@abusix.com> Hello, >> However, I would suggest that if you want >> a data maintenance process to apply to the abuse-c object, then you >> should describe it. As you seem to want the RIPE NCC to remove the >> registration of address space if abuse-c's are not maintained >> appropriately, the standards required should be explicit and either >> included in the policy text or referenced by it. >> > > I think this is a valid argument. > The proposal should contain the desired outcome as clear and explicitly > as possible. And I don't think the desired outcome is to just have a > role or person object referenced as the abuse contact, but to actually > have abuse contacts. The outcome is, to have an abuse-c in place. That is all. If there is a need to change RIPE NCC processes or start frequent update requests or do anything else to guarantee data accuracy this can be proposed by another proposal. And I'm sure if community asks for we can keep up the Task Force and take the next step. But in this step it is going about the abuse-c. In my opinion it would not make any sense to describe any measures for abuse-c. If we look at data accuracy we need to look at all the data in the database and not only at one small piece. So please keep it simple and lets discuss about the introduction of an abuse-c and ask the Task Force to work on a common data accuracy part after this proposal. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From pk at DENIC.DE Tue Nov 29 08:33:06 2011 From: pk at DENIC.DE (Peter Koch) Date: Tue, 29 Nov 2011 08:33:06 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> Message-ID: <20111129073306.GL9075@x27.adm.denic.de> Leo, > You previously wrote, that "If there is no cooperation, this can go down until the deregistration." I don't see how a threat of deregistration fits alongside a statement that dealing with bogus data is outside the scope of your proposal. I understand this concern and partly share it, which is why I am personally extremely sceptical about the part that would make an abuse-c mandatory (by syntax or business logic) without a clear timeline and migration path. Previous changes to syntax and logic have been accompanied by some timeout and default action, that would have moved obsolete attributes into remarks field or likewise. Now, this may or may not make sense for the proposal at hand, but I do not intend and also do not recommend to create massive amounts of compliance violations by introducing abuse-c and then waiting for "nothing" to happen. This would have to be covered by an NCC impact analysis (due in a potential next step in the PDP) and, IMHO, belongs under "arguments opposing this proposal" in the current version. > I searched the RIPE NCC's web site and could not find any description of systemic processes for evaluating and improving the quality of registration data. I am not aware of such a process, either. There is, however, process in place that is triggered on a case by case basis. -Peter (member of, but not speaking for the TF) From Kauto.Huopio at ficora.fi Tue Nov 29 09:09:19 2011 From: Kauto.Huopio at ficora.fi (Huopio Kauto) Date: Tue, 29 Nov 2011 08:09:19 +0000 Subject: [anti-abuse-wg] Spesific area of concern on WHOIS data.. "PE " Message-ID: <484D2A54C7AEAF4997B452E7572FB9212F3EC989@loota.laru.local> I have seen a lot of malicious activity concentrated on IP resources allocated to parties identifying as "PE Nnnnnn Nnnnnnnn", something like a private enterprise. I would like to recommend a spesific constintency check on all resources allocated to parties identifying themselves with a name starting with "PE ".. --Kauto From pk at DENIC.DE Tue Nov 29 09:16:31 2011 From: pk at DENIC.DE (Peter Koch) Date: Tue, 29 Nov 2011 09:16:31 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ECE2D5A.5030400@abusix.com> References: <4eccf965.dcead80a.390f.7babSMTPIN_ADDED@mx.google.com> <4ECE2D5A.5030400@abusix.com> Message-ID: <20111129081631.GN9075@x27.adm.denic.de> Tobias, > If we use a person object as an example, this person object can be > referenced for example by an admin-c or tech-c attribute at the moment. > > In future it can be referenced by the abuse-c as well, BUT to create > this reference the person objects needs to have an abuse-mailbox > attribute. If there is no abuse-mailbox attribute it can not be > referenced by the abuse-c. This will be done by the business logic. I am confused because i remember the discussion slightly differently and this is also not in line with what the policy proposal text says. We should not overlay existing objects with magic that does or does not make them eligible as a target for a reference. Also, abuse handling is more or a role function, so if at all, we'd talk about a "role:" derivative here. Some gatekeeping is indeed advised. > Same when you query for an ip range - admin-c, tech-c and abuse-c can be > the same person, but output will show an abuse-mailbox attribute in the > abuse-c part. This could be misread as giving different views onto the same object depending on the reference that made it appear in the output. -Peter (usual disclaimer applies) From ripe-anti-spam-wg at powerweb.de Tue Nov 29 09:19:31 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 29 Nov 2011 09:19:31 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111129075105.GM9075@x27.adm.denic.de> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> Message-ID: <4ED49593.4030504@powerweb.de> Peter Koch wrote: > Gilles, > > On Thu, Nov 24, 2011 at 09:55:02AM +0100, Gilles Massen wrote: > >> This policy proposal seems a bit incomplete to, as it fails to address >> the problem statement from the summary. > > thanks for pointing this out. There is a bit of confusion w.r.t. the > target audience and intended goals. Let me give you my view. Any > change we make to the DB schema or the Port 43 interface is unlikely > to please the random end user who is looking for a target to report > spam or other issues. Those are much better served by a service > like the NCC's "abuse contact finder" tool, which in turn may benefit > from a crisper data structure. But there is also a lot of (semi-)automated > reporting going on between ISPs, CSIRTs and other entities, where The proposal helps these kinds of automatic reporting a lot, simply because the field will not be mandatory anymore and there will be only one place to look. Furthermore: the amount of whois queries to the abuse-c cannot be restricted anymore. So: a bit +1 here from us. > timely detection, reporting and mitigation is crucial. Some of these > use standardized message formats. Those are not well served by a > web-based service or heuristics that may or may not end up with a "human" > mailbox. And there's a range of grey between these examples. > >> > From the summary: "...it is not clear whether to use the >> "abuse-mailbox:" attribute, the "remark:" attribute or an irt object.". >> What is supposed to happen to IRT objects, or data from them? >> >> For existing records: at the very least it should be explicit which tags >> should no longer be used or would be deprecated / removed in order to >> give clear guidance. > > Both questions would be addressed in a migration plan, but my reading is > that "abuse-mailbox" is going to disappear. A "migration plan" cannot be located in a proposal, because it heavily depends on the work of the RIPE NCC and a plan include dates (to my understanding) wich shouldnt end up in a proposal. But a "migration outlook/idea" would be a really good idea to have in the proposal. >> Another point: if the general idea of the policy is acceptable, wouldn't >> it be nice to have 2 abuse mailboxes: one for humans, one for bots? > > +1; Having two contacts might complicates things, it might be complicated for the end user to decide wich one to contact. Maybe it would be easier to make one contact wich has to be marked as "person", "role" or "robot". Both, end user or automatic reporting tools, could then decide themself, if the type of the contact fits their intention. It might also be nice to have a "preferred reporting method" field included, what could be "email, phone, url, ARF, X-ARF" or similar. Kind regards, Frank > > -Peter (again, not speaking for the TF) > > > -- Mit freundlichen Gruessen, -- 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 From ripe-wg-antiabuse at kyubu.de Tue Nov 29 09:40:00 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Tue, 29 Nov 2011 09:40:00 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED490AC.8020504@abusix.com> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> <87sjl7cr46.fsf@enigma.otenet.gr> <4ED490AC.8020504@abusix.com> Message-ID: <20111129084000.GA8460@core.kyubu.de> On Tue, Nov 29, 2011 at 08:58:36AM +0100, Tobias Knecht wrote: Hi, > The outcome is, to have an abuse-c in place. That is all. > > In my opinion it would not make any sense to describe any measures for > abuse-c. If we look at data accuracy we need to look at all the data in > the database and not only at one small piece. If I am correct, the proposal is on the improvement on finding the correct and valid contacts for abuse handling. Unfortunately, the proposal does only mention a possible techical solution on how this data can be stored. It leaves speculation on how the goal (such as valid contact data) can be achieved, which is (for my opinion) the most crucial part. (I am not talking about stuff that is beyond not cooperating members, etc.) > So please keep it simple and lets discuss about the introduction of an > abuse-c and ask the Task Force to work on a common data accuracy part > after this proposal. If the above is not covered in this very same proposal, you should do so (maybe in a second proposal) before abuse-c is released. I am convinced that if you specify "just another object", the situation won't be improved (in terms of finding the right contact data). Cheers, Adrian From ripe-wg-antiabuse at kyubu.de Tue Nov 29 09:49:01 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Tue, 29 Nov 2011 09:49:01 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED49593.4030504@powerweb.de> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> Message-ID: <20111129084900.GB8460@core.kyubu.de> On Tue, Nov 29, 2011 at 09:19:31AM +0100, Frank Gadegast wrote: Hi, > A "migration plan" cannot be located in a proposal, because it heavily > depends on the work of the RIPE NCC and a plan include dates (to my > understanding) wich shouldnt end up in a proposal. Lets say order the relevant technical processes should be included in this proposal (Some might call this a plan). > >>Another point: if the general idea of the policy is acceptable, wouldn't > >>it be nice to have 2 abuse mailboxes: one for humans, one for bots? > > > >+1; > > Having two contacts might complicates things, it might be complicated > for the end user to decide wich one to contact. > > Maybe it would be easier to make one contact wich has to be marked > as "person", "role" or "robot". > Both, end user or automatic reporting tools, could then decide themself, > if the type of the contact fits their intention. > It might also be nice to have a "preferred reporting method" field > included, what could be "email, phone, url, ARF, X-ARF" or similar. What if the people or robots reporting to such an address, don't care about robot vs. human mailboxes and/or relevant reporting formats (or are reporting bogus due to bugs)? I would suggest, that every team/member/robot behind such an address should figure that for themselves. Cheers, Adrian From ripe-anti-spam-wg at powerweb.de Tue Nov 29 10:05:12 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 29 Nov 2011 10:05:12 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111129084900.GB8460@core.kyubu.de> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> Message-ID: <4ED4A048.7070106@powerweb.de> Adrian wrote: > On Tue, Nov 29, 2011 at 09:19:31AM +0100, Frank Gadegast wrote: > > Hi, Hi, >> A "migration plan" cannot be located in a proposal, because it heavily >> depends on the work of the RIPE NCC and a plan include dates (to my >> understanding) wich shouldnt end up in a proposal. > > Lets say order the relevant technical processes should be included in this proposal (Some might call this a plan). Agreed. >>>> Another point: if the general idea of the policy is acceptable, wouldn't >>>> it be nice to have 2 abuse mailboxes: one for humans, one for bots? >>> >>> +1; >> >> Having two contacts might complicates things, it might be complicated >> for the end user to decide wich one to contact. >> >> Maybe it would be easier to make one contact wich has to be marked >> as "person", "role" or "robot". >> Both, end user or automatic reporting tools, could then decide themself, >> if the type of the contact fits their intention. >> It might also be nice to have a "preferred reporting method" field >> included, what could be "email, phone, url, ARF, X-ARF" or similar. > > What if the people or robots reporting to such an address, don't care about robot vs. human mailboxes and/or relevant reporting formats (or are reporting bogus due to bugs)? I would suggest, that every team/member/robot behind such an address should figure that for themselves. Also agreed, I recommend a "preferred" reporting method field, what should improve the reporting accuracy (we often receive emails back, wich simply includes a link to an online form, this could be shorted, when the URL is already included in the field). Surely its not 100%. Kind regards, Frank > > Cheers, Adrian > > > > -- Mit freundlichen Gruessen, -- 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 From aftab.siddiqui at gmail.com Tue Nov 29 10:25:37 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 29 Nov 2011 14:25:37 +0500 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111129084000.GA8460@core.kyubu.de> References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> <87sjl7cr46.fsf@enigma.otenet.gr> <4ED490AC.8020504@abusix.com> <20111129084000.GA8460@core.kyubu.de> Message-ID: Hi, > > If I am correct, the proposal is on the improvement on finding the correct > and valid contacts for abuse handling. Unfortunately, the proposal does > only mention a possible techical solution on how this data can be stored. > It leaves speculation on how the goal (such as valid contact data) can be > achieved, which is (for my opinion) the most crucial part. (I am not > talking about stuff that is beyond not cooperating members, etc.) +1, why not review and add how to accomodate the accuracy of data. Regards, Aftab A. Siddiqui. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Tue Nov 29 11:17:39 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 29 Nov 2011 15:47:39 +0530 Subject: [anti-abuse-wg] Spesific area of concern on WHOIS data.. "PE " In-Reply-To: <484D2A54C7AEAF4997B452E7572FB9212F3EC989@loota.laru.local> References: <484D2A54C7AEAF4997B452E7572FB9212F3EC989@loota.laru.local> Message-ID: That would be the Russian equivalent of "LLC" so a rather broad audit indeed. So - it might be better to find some other way to narrow it down - resources routed through a particular ASN or set of ASNs for example. On Tue, Nov 29, 2011 at 1:39 PM, Huopio Kauto wrote: > I have seen a lot of malicious activity concentrated on IP resources > allocated to parties identifying as "PE Nnnnnn Nnnnnnnn", something like > a private enterprise. I would like to recommend a spesific constintency > check on all resources allocated to parties identifying themselves > with a name starting with "PE ".. > > --Kauto -- Suresh Ramasubramanian (ops.lists at gmail.com) From tk at abusix.com Tue Nov 29 11:55:22 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 29 Nov 2011 11:55:22 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <201111231347.pANDlH64028370@pechora5.dc.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A3EB9@EXVPMBX100-1.exc.icann.org> <4ECE4C4A.5090106@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A411A@EXVPMBX100-1.exc.icann.org> <4ED3F845.6080708@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4184@EXVPMBX100-1.exc.icann.org> <4ED4000F.2030800@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A41A0@EXVPMBX100-1.exc.icann.org> <87sjl7cr46.fsf@enigma.otenet.gr> <4ED490AC.8020504@abusix.com> <20111129084000.GA8460@core.kyubu.de> Message-ID: <4ED4BA1A.50406@abusix.com> Hi, > If I am correct, the proposal is on the improvement on finding the > correct and valid contacts for abuse handling. Unfortunately, the > proposal does only mention a possible techical solution on how this > data can be stored. It leaves speculation on how the goal (such as > valid contact data) can be achieved, which is (for my opinion) the > most crucial part. (I am not talking about stuff that is beyond not > cooperating members, etc.) Yes this proposal is only mentioning how the data should look like and how it is stored. Because the Task Force was not intended to do more so far. We all have talked about the problems and how we could solve them, but this was not the intention. Community wanted us to solve the problem on how abuse contact information will show up in the RIPE Database, because the first proposal was too technical and went into a wrong direction. If Community wants the Task Force to go on and take care of the data accuracy. That is fine and I know that the Task Force will be happy to do so. But this proposal is a first step into this direction. Maybe it will get clearer as soon as RIPE NCC has published their implementation thoughts. Since I can not talk for RIPE NCC in behalf of implementation and operational issues I have to stop this discussion here and take care that RIPE NCC is joining this discussion. Never the less thanks for your thoughts and thanks for the suggestions. > +1, why not review and add how to accomodate the accuracy of data. Because we can not boil the ocean at once. ;-) The implementation of this proposal will take steps to make things easier while looking at data accuracy. We have an accuracy problem in the whole database and not only with the abuse-c. So let's differentiate and mix not up things. Thanks, Tobias -- abusix > > > Regards, > > Aftab A. Siddiqui. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Tue Nov 29 12:24:10 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 29 Nov 2011 12:24:10 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111129084900.GB8460@core.kyubu.de> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> Message-ID: <4ED4C0DA.5000808@abusix.com> Hi, > Lets say order the relevant technical processes should be included in > this proposal (Some might call this a plan). I will ask RIPE NCC to join this discussion since I can not talk about implementation in behalf of RIPE NCC. In my opinion it does not make any sense to include implementation details into an policy. Two reasons for that. Nobody cares about the implementation details in 10 years when things are in place. This would pollute the policy. And second, what happens if another proposal coming up in 5 years changes the whole design of database? Policy is policy and implemetation details are implementation details. I agree that RIPE NCC should publish their ideas, but not put it into the proposal text. And an example at the end. If we agree that we have to be in London on 10th of December. We agreed on that. If RIPE NCC tells us to walk and swim, we can say "No way!" and ask them if we could fly, but we do not disagree about being in London. I do not want to mix up the fact of going to London (introducing the abuse-c) with the fact on how to go to London (how to implement things). >>>> Another point: if the general idea of the policy is acceptable, >>>> wouldn't it be nice to have 2 abuse mailboxes: one for humans, >>>> one for bots? >>> >>> +1; >> >> Having two contacts might complicates things, it might be >> complicated for the end user to decide wich one to contact. No. End users should not take the way of whois. They should use the abuse finder tool. This tool will give them exactly what they need. >> Maybe it would be easier to make one contact wich has to be marked >> as "person", "role" or "robot". Both, end user or automatic >> reporting tools, could then decide themself, if the type of the >> contact fits their intention. It might also be nice to have a >> "preferred reporting method" field included, what could be "email, >> phone, url, ARF, X-ARF" or similar. This will make things much more complicated. I agree and we had a discussion about this in the Task Force as well, that a url may be an option as well. On the other hand, parsing email in a standard format is not that difficult and in the abuse community offering a form to report abuse is most likely seen as a "Fuck off!" to the reporter. The idea behind abuse-mailbox and e-mail attribute is the following: The email attribute can be personal information, so you do not want to publish it unrestricted. The information in the abuse-mailbox attribute will be not personal information and can be queried unrestrictedly. If you have no need for a differentiation between those, take the same address for both. That would be absolutely fine. > What if the people or robots reporting to such an address, don't care > about robot vs. human mailboxes and/or relevant reporting formats (or > are reporting bogus due to bugs)? I would suggest, that every > team/member/robot behind such an address should figure that for > themselves. There is a second reason for differentiation. Spam filters on abuse addresses do not make a lot of sense. But spam filters on a team addresses read by humans do make a lot of sense. What if a bot does not care. He will take care, because if he sends the reports to the personal address they will get lost, because the spam filter will take care of them. I'm against every team/member/robot should figure that out themselves. That is exactly the situation at the moment with loads of opportunities. Receiving all kinds of robot reports on one mailbox (abuse-mailbox) is already best practice today. So this is nothing new. A last reason why I would not split up things to far. I want to avoid adding to much opportunities at once. I think there is not reason not to add Jabber/IRC/XMP-PRC/whatever as a new attribute as soon as it shows up and is widely used. At the moment mail is the most common way of exchanging reports about abusive behavior. So that is why I would suggest to stay with email and see if something really new comes up. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ripe-wg-antiabuse at kyubu.de Tue Nov 29 12:41:33 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Tue, 29 Nov 2011 12:41:33 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED4C0DA.5000808@abusix.com> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> Message-ID: <20111129114133.GA9081@core.kyubu.de> On Tue, Nov 29, 2011 at 12:24:10PM +0100, Tobias Knecht wrote: Hi, > In my opinion it does not make any sense to include implementation > details into an policy. Two reasons for that. Nobody cares about the > implementation details in 10 years when things are in place. This would > pollute the policy. And second, what happens if another proposal coming > up in 5 years changes the whole design of database? I am aware of that. I think It would be fine for everyone, if the proposal contains a reference to a document which defines this. > I do not want to mix up the fact of going to London (introducing the > abuse-c) with the fact on how to go to London (how to implement things). Yet, it should be defined to make sure everybody _is_ in London on Dec. 10. > I'm against every team/member/robot should figure that out themselves. So you are proposing a kind of "one-size-fits-all" on how to process data internally. I am curious if this works. Cheers, Adrian From tk at abusix.com Tue Nov 29 12:54:21 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 29 Nov 2011 12:54:21 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20111129114133.GA9081@core.kyubu.de> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> Message-ID: <4ED4C7ED.3070305@abusix.com> Hi, >> In my opinion it does not make any sense to include implementation >> details into an policy. Two reasons for that. Nobody cares about >> the implementation details in 10 years when things are in place. >> This would pollute the policy. And second, what happens if another >> proposal coming up in 5 years changes the whole design of >> database? > > I am aware of that. I think It would be fine for everyone, if the > proposal contains a reference to a document which defines this. I already asked RIPE NCC folks to join the discussion and come up with the implementation details and the operational details on how things are handled if data is inaccurate. >> I do not want to mix up the fact of going to London (introducing >> the abuse-c) with the fact on how to go to London (how to implement >> things). > > Yet, it should be defined to make sure everybody _is_ in London on > Dec. 10. I guess we agree on that. ;-) Additional paper would make sense. >> I'm against every team/member/robot should figure that out >> themselves. > > So you are proposing a kind of "one-size-fits-all" on how to process > data internally. I am curious if this works. We are talking about formats that are intended to be machine readable (arf, xarf, IODEF). Every single of the todays official formats can be parsed full automatic. Even not "official" formats like spamcop or others can be parsed automatically. Things that can not be parsed automatically can be forwarded to an internal mailbox and can be manually reviewed. My experience tells me that more than 98% of the incoming reports are within the top 10 fully automatic parsable formats and only 2% of the incoming traffic has to be reviews manually. This whole routing process takes less than an hour to be implemented in procmail. But that would go to far into another interesting discussion. If you are interested in that we can go on off list. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From denis at ripe.net Tue Nov 29 16:35:24 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 29 Nov 2011 16:35:24 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED4C7ED.3070305@abusix.com> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> Message-ID: <4ED4FBBC.7040101@ripe.net> HI Tobias and others As requested we will prepare a document on a technical implementation, as discussed by the Task Force, for your proposed policy. We expect to be able to publish this tomorrow. Regards Denis Walker Business Analyst RIPE NCC Database Group On 29/11/11:49 12:54 PM, Tobias Knecht wrote: > Hi, > >>> In my opinion it does not make any sense to include implementation >>> details into an policy. Two reasons for that. Nobody cares about >>> the implementation details in 10 years when things are in place. >>> This would pollute the policy. And second, what happens if another >>> proposal coming up in 5 years changes the whole design of >>> database? >> >> I am aware of that. I think It would be fine for everyone, if the >> proposal contains a reference to a document which defines this. > > I already asked RIPE NCC folks to join the discussion and come up with > the implementation details and the operational details on how things are > handled if data is inaccurate. > >>> I do not want to mix up the fact of going to London (introducing >>> the abuse-c) with the fact on how to go to London (how to implement >>> things). >> >> Yet, it should be defined to make sure everybody _is_ in London on >> Dec. 10. > > I guess we agree on that. ;-) Additional paper would make sense. > >>> I'm against every team/member/robot should figure that out >>> themselves. >> >> So you are proposing a kind of "one-size-fits-all" on how to process >> data internally. I am curious if this works. > > We are talking about formats that are intended to be machine readable > (arf, xarf, IODEF). Every single of the todays official formats can be > parsed full automatic. Even not "official" formats like spamcop or > others can be parsed automatically. Things that can not be parsed > automatically can be forwarded to an internal mailbox and can be > manually reviewed. My experience tells me that more than 98% of the > incoming reports are within the top 10 fully automatic parsable formats > and only 2% of the incoming traffic has to be reviews manually. > > This whole routing process takes less than an hour to be implemented in > procmail. > > But that would go to far into another interesting discussion. If you are > interested in that we can go on off list. > > Thanks, > > Tobias > From tk at abusix.com Tue Nov 29 16:49:02 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 29 Nov 2011 16:49:02 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED4FBBC.7040101@ripe.net> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> Message-ID: <4ED4FEEE.9080307@abusix.com> Hi Denis, thank you very much! Looking forward the document. Thanks, Tobias -- abusix Am 29.11.11 16:35, schrieb Denis Walker: > HI Tobias and others > > As requested we will prepare a document on a technical implementation, > as discussed by the Task Force, for your proposed policy. We expect to > be able to publish this tomorrow. > > Regards > Denis Walker > Business Analyst > RIPE NCC Database Group > > On 29/11/11:49 12:54 PM, Tobias Knecht wrote: >> Hi, >> >>>> In my opinion it does not make any sense to include implementation >>>> details into an policy. Two reasons for that. Nobody cares about >>>> the implementation details in 10 years when things are in place. >>>> This would pollute the policy. And second, what happens if another >>>> proposal coming up in 5 years changes the whole design of >>>> database? >>> >>> I am aware of that. I think It would be fine for everyone, if the >>> proposal contains a reference to a document which defines this. >> >> I already asked RIPE NCC folks to join the discussion and come up with >> the implementation details and the operational details on how things are >> handled if data is inaccurate. >> >>>> I do not want to mix up the fact of going to London (introducing >>>> the abuse-c) with the fact on how to go to London (how to implement >>>> things). >>> >>> Yet, it should be defined to make sure everybody _is_ in London on >>> Dec. 10. >> >> I guess we agree on that. ;-) Additional paper would make sense. >> >>>> I'm against every team/member/robot should figure that out >>>> themselves. >>> >>> So you are proposing a kind of "one-size-fits-all" on how to process >>> data internally. I am curious if this works. >> >> We are talking about formats that are intended to be machine readable >> (arf, xarf, IODEF). Every single of the todays official formats can be >> parsed full automatic. Even not "official" formats like spamcop or >> others can be parsed automatically. Things that can not be parsed >> automatically can be forwarded to an internal mailbox and can be >> manually reviewed. My experience tells me that more than 98% of the >> incoming reports are within the top 10 fully automatic parsable formats >> and only 2% of the incoming traffic has to be reviews manually. >> >> This whole routing process takes less than an hour to be implemented in >> procmail. >> >> But that would go to far into another interesting discussion. If you are >> interested in that we can go on off list. >> >> Thanks, >> >> Tobias >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From denis at ripe.net Wed Nov 30 16:25:33 2011 From: denis at ripe.net (Denis Walker) Date: Wed, 30 Nov 2011 16:25:33 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED4FEEE.9080307@abusix.com> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> Message-ID: <4ED64AED.7030503@ripe.net> Dear Tobias and others The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object. https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database Regards Denis Walker Business Analyst RIPE NCC Database Group On 29/11/11:49 4:49 PM, Tobias Knecht wrote: > Hi Denis, > > thank you very much! Looking forward the document. > > Thanks, > > Tobias > From tk at abusix.com Wed Nov 30 18:39:58 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 30 Nov 2011 18:39:58 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED64AED.7030503@ripe.net> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> Message-ID: <4ED66A6E.4000404@abusix.com> Thanks to Denis and RIPE NCC to come up with this view of the planned implementation. Thanks, Tobias -- abusix Am 30.11.11 16:25, schrieb Denis Walker: > Dear Tobias and others > > The RIPE NCC Database Group has now published an article on RIPE Labs > with a detailed explanation of how we propose to implement abuse > handling with an "abuse-c:" attribute referencing a ROLE object. > > https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database > > Regards > Denis Walker > Business Analyst > RIPE NCC Database Group > > > On 29/11/11:49 4:49 PM, Tobias Knecht wrote: >> Hi Denis, >> >> thank you very much! Looking forward the document. >> >> Thanks, >> >> Tobias >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: