From chrish at consol.net Mon Apr 2 13:25:44 2012 From: chrish at consol.net (Chris) Date: Mon, 02 Apr 2012 13:25:44 +0200 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: <20120330133039.GA9050@spin.it> References: <20120329145805.GC84425@Space.Net> <20120329150206.GD84425@Space.Net> <20120329173116.GF84425@Space.Net> <20120329174147.GG84425@Space.Net> <4F758A75.9070209@consol.net> <20120330133039.GA9050@spin.it> Message-ID: <4F798CB8.20804@consol.net> On 03/30/2012 03:30 PM, furio ercolessi wrote: >>From what I understood, the discussion was about networks controlled > by criminals, not about networks abused by criminals. ...and they were called bot-nets. quite ri... err - wrong. ;) > RBN was extremely well known to the antiabuse community. also extremely well known is that the legal situation in russia is quite different from many others. which brings us back to the core of the thread again: no, ripe was not, is not, and can never be a legislative, judicative, or police. if you think you are dealing with criminal activity, go to the legal organisations. if you are unhappy with a country's legislative - well, i don't know, start some war or whatever you do in such cases... > controlled by criminals and used exclusively for criminal activity, to make it short: if you want to deal with criminals, go to the police! apart from that i take it as probable libel. i mean, even if i believed you might sort of really know what you're talking about: 'exclusively for criminal activity' - come on, maybe you're not jurisprudence, but nevertheless, to take part in such discussions, a basic level of accurateness is really a must. at least to be taken seriously, i mean otherwise people just hardly have a choice than to assume what you say is not true. to decide about this is a court's responsibility anyway. > anti-abuse community, until some law enforcements agency or possibly see, you know how it works. (let's ignore the or-part, for civilisation's sake...) > it right here in this thread: people working in the field know very well that's not what i observe. i mean taking away some ips to stop a bot-network... let's just stick to the topic's facts in this discussion, i'd very much appreciate that. what's the point in pointing out how good or bad you think sbdy might be. and from what i see it's more like a political wannabe-fight that can be observed here, than a substantiated technical discussion. (actually, a few of them :) > the RIR side ever because it's not in the RIR mandate. again, in the end you seem to know how it works. > is bigger than in the other regions - was removed from the co-chair i don't know about this issue, what happened and what not - but what i can say is that a chair having problems understanding the nature of ripe - i'd certainly vote to drop that one. > to criminals is being swept under the carpet, with no hope for any when i read this kind of rants, imagining the same people declaring who or what is criminal and what not sends shivers down my spine... let's hope rule of law will be a surviving concept. regards, Chris From laura at ripe.net Tue Apr 3 17:04:31 2012 From: laura at ripe.net (Laura Cobley) Date: Tue, 03 Apr 2012 17:04:31 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form Message-ID: <4F7B117F.4050505@ripe.net> [Apologies for duplicate emails] Dear colleagues, We would like to introduce the RIPE NCC Report Form. Using this form, you can now easily report various issues, including abnormalities in Internet number resource registrations, to us for further investigation. By making it easy to report these issues to us and by putting a clear process in place, we aim to work together with you to further improve the quality of the data in the Internet number resource registry. The first release of the form offers basic functionality. We will review the form, its usage and your feedback before deciding whether further development is needed in the future. You can find more details at: https://labs.ripe.net/Members/andrea/ripe-ncc-report-form If you have any questions or feedback, please contact . Best regards, Laura Cobley RIPE NCC From thor.kottelin at turvasana.com Tue Apr 3 17:15:34 2012 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Tue, 3 Apr 2012 18:15:34 +0300 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F7B117F.4050505@ripe.net> References: <4F7B117F.4050505@ripe.net> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Laura Cobley > Sent: Tuesday, April 03, 2012 6:05 PM > To: anti-abuse-wg at ripe.net > Using this form, you can now easily report various issues, > including > abnormalities in Internet number resource registrations, to us for > further investigation. > The first release of the form offers basic functionality. We will > review > the form, its usage and your feedback before deciding whether > further > development is needed in the future. Thank you. (For the record, the actual form is located at www.ripe.net/report-form.) Could you also make the form work in a way that does not require the user agent to support client-side scripting? -- Thor Kottelin http://www.anta.net/ From P.Vissers at opta.nl Wed Apr 4 09:19:24 2012 From: P.Vissers at opta.nl (Vissers, Pepijn) Date: Wed, 4 Apr 2012 07:19:24 +0000 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: References: <4F7B117F.4050505@ripe.net> Message-ID: > > Using this form, you can now easily report various issues, including > > abnormalities in Internet number resource registrations, to us for > > further investigation. As much as I support this initiative, I can't help thinking "it's about time this was developed". Either way, good to see it's there. > > The first release of the form offers basic functionality We will > > review the form, its usage and your feedback before deciding whether > > further development is needed in the future. I assume (haven't tested but will certainly do in the near future) that a reference/ticket number will be created, although I read that RIPE will not follow up with the complainant. Laura, can you tell us something about the process behind the form? How many people has RIPE reserved for analyzing, correlating and following up the complaints? OPTA receives about 35000 complaints a year through our spam complaint form (which is not too quick to fill out) so we know first hand what it takes to categorize and follow up in a way that does right to every complaint. Best regards, Pepijn Vissers +++++++++++++++++++++++++++++++++++++++++++++ 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. From ripe-wg-antiabuse at kyubu.de Wed Apr 4 10:37:34 2012 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Wed, 4 Apr 2012 08:37:34 +0000 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: References: <20120329144941.GB84425@Space.Net> <20120329145805.GC84425@Space.Net> <20120329150206.GD84425@Space.Net> <20120329173116.GF84425@Space.Net> <20120329174147.GG84425@Space.Net> Message-ID: <20120404083734.GB18608@core.kyubu.de> On Thu, Mar 29, 2012 at 11:33:15PM +0530, Suresh Ramasubramanian wrote: Suresh, > The swiss ccTLD seems to have things set up just right - and I would be Correct me if I am wrong, but this was about RIPE is (not) doing? > for 30 days if an application to this effect is made by an agency > appropriately recognised by the Swiss Federal Office of Communications > (OFCOM). The holder may demand a contestable order against the block from > the Federal Office of Police (FEDPOL) within 30 days of its commencement. > Otherwise, the further procedure and process is governed by the relevant > provisions of the Ordinance on Addressing Resources in the > Telecommunications Sector (OARTS). This defines how things are running after complaints are raised. I doubt they would go deeper other than checking if their standards are met, so this would not prevent me from setting up a malicious .ch domain. Cheers, Adrian From ripe-wg-antiabuse at kyubu.de Wed Apr 4 10:23:18 2012 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Wed, 4 Apr 2012 08:23:18 +0000 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: <20120329145805.GC84425@Space.Net> References: <20120329125049.GR84425@Space.Net> <20120329142834.GW84425@Space.Net> <20120329144045.GA84425@Space.Net> <20120329144941.GB84425@Space.Net> <20120329145805.GC84425@Space.Net> Message-ID: <20120404082318.GA18608@core.kyubu.de> On Thu, Mar 29, 2012 at 04:58:05PM +0200, Gert Doering wrote: Gert, > not solve anything either. So: what should the NCC do, to avoid Second that. Such a system could be subverted easily by criminals (bet they do), thus not improving the current situation. Cheers, Adrian From laura at ripe.net Thu Apr 5 14:06:13 2012 From: laura at ripe.net (Laura Cobley) Date: Thu, 05 Apr 2012 14:06:13 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: References: <4F7B117F.4050505@ripe.net> Message-ID: <4F7D8AB5.4060207@ripe.net> Hi Pepijn, Thanks very much for your mail. Feedback like this is very helpful for us as we look to develop the procedure. On 4/4/12 9:19 AM, Vissers, Pepijn wrote: >>> Using this form, you can now easily report various issues, including >>> abnormalities in Internet number resource registrations, to us for >>> further investigation. > > As much as I support this initiative, I can't help thinking "it's about time this was developed". Either way, good to see it's there. > >>> The first release of the form offers basic functionality We will >>> review the form, its usage and your feedback before deciding whether >>> further development is needed in the future. > > I assume (haven't tested but will certainly do in the near future) that a reference/ticket number will be created, although I read that RIPE will not follow up with the complainant. Yes, a ticket will be created and we'll advise the complainant whether the report can be investigated. We won't go into any details of subsequent actions taken because these are confidential between us and the responsible party. > > Laura, can you tell us something about the process behind the form? How many people has RIPE reserved for analyzing, correlating and following up the complaints? OPTA receives about 35000 complaints a year through our spam complaint form (which is not too quick to fill out) so we know first hand what it takes to categorize and follow up in a way that does right to every complaint. Handling reports is a normal part of our operations within the RIPE NCC and the report form makes it easier for people to get in touch with us. It also makes for more streamlined and consistent processing, so hopefully it will make things easier for us as well as for the reporter. You can find more information about the procedure here: https://www.ripe.net/contact/reporting-procedure If you have any further feedback, especially as we make developments to the form and the procedure, please do let us know. Best regards, Laura Cobley RIPE NCC > > Best regards, > Pepijn Vissers > +++++++++++++++++++++++++++++++++++++++++++++ > 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. From shane at time-travellers.org Thu Apr 5 15:15:37 2012 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 5 Apr 2012 15:15:37 +0200 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> Message-ID: <20120405151537.3b7a1c0c@shane-eeepc.home.time-travellers.org> Suresh, [ Sorry for the late reply! ] On Thursday, 2012-03-29 15:57:07 +0530, Suresh Ramasubramanian wrote: > On Thu, Mar 29, 2012 at 2:23 PM, Shane Kerr > wrote: > > The issue is making sure that the bad guys are simply not able to get > themselves a /15 whenever they like simply because the paperwork > verification is close enough to nonexistent. If that is the only issue that you care about, then a community self-help site is not what you want. I was going to go through your long mail point by point but then realized that it would be a waste of time. I think that it is fair that you have other goals, but perhaps you can refrain from commenting further on this proposal so that people who might find it useful can discuss it? Thanks. > This is an entirely strawman set of arguments. Can you please > explain to me what part of SOCA's proposals about crosschecking ID / > email address etc triggers a single antitrust regulation? Or a > privacy regulation for that matter? I guess you mean the British Serious Organised Crime Agency? I have no idea what that proposal is. Was it discussed on this list? Can you please send a link? -- Shane From shane at time-travellers.org Thu Apr 5 16:27:11 2012 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 5 Apr 2012 16:27:11 +0200 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: <878vijmca3.fsf@mid.deneb.enyo.de> References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> <878vijmca3.fsf@mid.deneb.enyo.de> Message-ID: <20120405162711.33c7e6cd@shane-eeepc.home.time-travellers.org> Florian, On Thursday, 2012-03-29 21:34:44 +0200, Florian Weimer wrote: > > Plus it is hard to get the RIPE NCC membership to support mechanisms > > which cost them money and limit their freedoms. > > Is it? As a first approximation, RIPE NCC only executes the policies > set by the RIPE community. Their function is mostly bureaucratic, so > as an organization, RIPE NCC inevitably has a tendency to acquire > additional responsibilities, diversify and grow. This is especially > important because we're approaching the end of address scarcity. It might be a failure of imagination on my part, but I think that attempting to prevent "bad guys" from getting addresses involves extra work to prove somehow that they companies not criminal. I don't see a lot of call by LIRs to increase the amount of paperwork and delay when dealing with the RIPE NCC. :) > > Maybe it makes sense to make something like a web forum for each > > allocated resource, or perhaps for the organization responsible for > > each. > > We'd have to find someone host such a site in the U.S. because > otherwise, the hoster will be responsible for such user-generated > content. There are also privacy issues. Interesting, because we have sites that review online resellers here in Holland, and that seems to work somehow. So maybe this is possible in some countries in the RIPE region too? > Alternatively, with heavy moderation, the net result would not be that > much different from Spamhaus' ROKSO list, would it? Does ROKSO cover any issue, or just spam? Certainly there is nothing preventing anyone who can afford a VPS from setting up some reputation site, but if it was RIPE NCC-hosted it might have a different level of gravitas. Cheers, -- Shane From ops.lists at gmail.com Fri Apr 6 05:30:21 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 6 Apr 2012 09:00:21 +0530 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: <20120405151537.3b7a1c0c@shane-eeepc.home.time-travellers.org> References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> <20120405151537.3b7a1c0c@shane-eeepc.home.time-travellers.org> Message-ID: Hi Shane First, for SOCA's proposal - here you go. http://news.dot-nxt.com/2012/03/12/five-cs-whois-validation-model Let us put it this way. There's nothing that stops you or RIPE NCC or anyone else from creating such a "community resource" It would not be the brightest idea in the world to treat that as a viable alternative for action to prevent and revoke bogus allocations, and wash your hands off the matter. Personally speaking, I find it rather amusing when people from an organization have a different set of opinions in one community, whereas their counterparts from other parts (say the security side rather than the IP engg side) of the organization have an entirely different set of opinions in a totally different community. Sure there's absolutely nothing wrong in having and holding different opinions, but when it translates to entirely different kinds of policy .. and when it also translates to one community being not entirely happy with the policy decisions coming from the other community .. It would be an interesting thought experiment to have most of the RIPE NCC members most supportive of the "we are not the document police" idea turn up at, say, a MAAWG meeting, while their counterparts who usually go to MAAWG come to a RIPE meeting [and yes, participate in the mailing lists of those communities during the months that lead up to the meeting]. Especially when there are several key proposals on whois, IP allocation and vetting policies etc on the agenda .. Do remember that the "community" in both cases, RIPE and MAAWG, is basically individuals in their capacity as representatives of an organization such as a broadband carrier, datacenter, or say ISC in your case. So it is no longer a question of personal opinion - it is a question of deciding on policies that, at times, severely affect your colleagues from other parts of your organization. --srs On Thu, Apr 5, 2012 at 6:45 PM, Shane Kerr wrote: > > > I think that it is fair that you have other goals, but perhaps you can > refrain from commenting further on this proposal so that people who > might find it useful can discuss it? Thanks. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Fri Apr 6 05:37:05 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 6 Apr 2012 09:07:05 +0530 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: <20120405162711.33c7e6cd@shane-eeepc.home.time-travellers.org> References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> <878vijmca3.fsf@mid.deneb.enyo.de> <20120405162711.33c7e6cd@shane-eeepc.home.time-travellers.org> Message-ID: On Thu, Apr 5, 2012 at 7:57 PM, Shane Kerr wrote: > It might be a failure of imagination on my part, but I think that > attempting to prevent "bad guys" from getting addresses involves extra > work to prove somehow that they companies not criminal. I don't see a > lot of call by LIRs to increase the amount of paperwork and delay when > dealing with the RIPE NCC. :) Did you calculate just how much expense your colleagues in another department (security or spam filtering or whatever) face because you can't collectively be bothered to do some paperwork, and/or RIPE NCC can't be bothered to streamline and automate their processes? > Does ROKSO cover any issue, or just spam? Certainly there is nothing > preventing anyone who can afford a VPS from setting up some reputation > site, but if it was RIPE NCC-hosted it might have a different level of > gravitas. It covers groups or people that have a long history of spam and termination from at least three service providers for violation of their policies. But the word "spam" - and so the category of people listed in ROKSO - covers everything from unsolicited marketing of mail order junk (borderline fraud at worst), to criminals involved in credit card theft and child pornography. As for "reputation" wrt spam - I would take spamhaus' word for this over the word of any organization or community that is "not the document police". You see, if you are not the document police and then go around publishing something about a netblock's reputation being bad or fishy .. well then, you have published that based on very little actual fact available to you. So why would I or anybody else value it for more than the paper (or sectors on a hard disk) it is written on? --srs From russ at consumer.net Fri Apr 6 05:58:10 2012 From: russ at consumer.net (russ at consumer.net) Date: Thu, 05 Apr 2012 23:58:10 -0400 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> <20120405151537.3b7a1c0c@shane-eeepc.home.time-travellers.org> Message-ID: <4F7E69D2.4030308@consumer.net> >Personally speaking, I find it rather amusing when people from an organization have a different set of opinions in >one community, whereas their counterparts from other parts (say the security side rather than the IP engg side) of >the organization have an entirely different set of opinions in a totally different community. You do the same thing. You never want to balance security, privacy and legal issues. Because you deal with spam complaints all day you tend to disregard privacy and legal issues. The privacy and legal people often do the same thing and issues often never get resolved. From shane at time-travellers.org Fri Apr 6 08:53:00 2012 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 6 Apr 2012 08:53:00 +0200 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> <878vijmca3.fsf@mid.deneb.enyo.de> <20120405162711.33c7e6cd@shane-eeepc.home.time-travellers.org> Message-ID: <20120406085300.41e898d4@shane-eeepc.home.time-travellers.org> Suresh, On Friday, 2012-04-06 09:07:05 +0530, Suresh Ramasubramanian wrote: > On Thu, Apr 5, 2012 at 7:57 PM, Shane Kerr > wrote: > > > It might be a failure of imagination on my part, but I think that > > attempting to prevent "bad guys" from getting addresses involves > > extra work to prove somehow that they companies not criminal. I > > don't see a lot of call by LIRs to increase the amount of paperwork > > and delay when dealing with the RIPE NCC. :) > > Did you calculate just how much expense your colleagues in another > department (security or spam filtering or whatever) face because you > can't collectively be bothered to do some paperwork, and/or RIPE NCC > can't be bothered to streamline and automate their processes? Just so we're clear - I don't represent an LIR, and never have. I don't vote on the RIPE NCC budget or the RIPE NCC board. I agree that there are externalized costs in handling network abuse. That's the very reason the spam problem exists!!! However companies are by and large short-sighted and selfish - even more than human beings, since companies have neither friends nor families. Externalized costs ("somebody else has to pay for my expenses, increasing my profits") are good from their point of view. RIPE allows not a level playing field, but one just balanced enough to allow necessary cooperation. This is true of any forum used for collaboration within a particular industry. (Vodafone and T-Mobile may be competitors, but their customers need to be able to call each other.) I neither defend nor attack the views of people regarding how much control is needed for stopping abuse, but I do recognize that these views exist. If you want any agenda pushed forward, I believe you need to recognize that other people have other positions and try to come up with solutions that work for them too. > > Does ROKSO cover any issue, or just spam? Certainly there is nothing > > preventing anyone who can afford a VPS from setting up some > > reputation site, but if it was RIPE NCC-hosted it might have a > > different level of gravitas. > > It covers groups or people that have a long history of spam and > termination from at least three service providers for violation of > their policies. So from your point of view, there already exists a reasonable reputation service that covers both networks and their operators. I guess ROKSO provides some sort of networking blacklisting automation, right? (Or perhaps even whitelisting?) Is there a reason not to use that for filtering and not worry whether the RIPE NCC or any other LIR has allocated any particular addresses? > But the word "spam" - and so the category of people listed in ROKSO - > covers everything from unsolicited marketing of mail order junk > (borderline fraud at worst), to criminals involved in credit card > theft and child pornography. I guess I was wondering if it covered literally any nefarious activities, so that it could be used as a general reputation service. If I am getting DoS'd or penetration tested from an ISP who doesn't do anything about it, I'd want that sort of thing tracked too. > As for "reputation" wrt spam - I would take spamhaus' word for this > over the word of any organization or community that is "not the > document police". You see, if you are not the document police and > then go around publishing something about a netblock's reputation > being bad or fishy .. well then, you have published that based on very > little actual fact available to you. So why would I or anybody else > value it for more than the paper (or sectors on a hard disk) it is > written on? I actually think you *should* take a 3rd-party reputation service's opinion more seriously. Realistically the RIPE NCC will *always* have a conflict of interest - they want to serve the wider community but their direct members are the LIRs. (OTOH 3rd-party reputation is not a cure-all if not set up properly, as the recent collapse of the Certificate Authority (CA) system has shown us.) My goal of putting some sort of forum associated with the RIPE allocation information was to get this 3rd-party information as close as possible to the "authoritative" information about network addresses without triggering any conflict of interests. I never claimed it was a completely baked idea, certainly. :-P -- Shane From jaap at NLnetLabs.nl Fri Apr 6 10:39:36 2012 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Fri, 06 Apr 2012 10:39:36 +0200 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> <20120405151537.3b7a1c0c@shane-eeepc.home.time-travellers.org> Message-ID: <201204060839.q368dbZS066382@bartok.nlnetlabs.nl> First, for SOCA's proposal - here you go. http://news.dot-nxt.com/2012/03/12/five-cs-whois-validation-model No, this is what somebody thinks what that the model is. I tried to find documentation on it on the SOCA site, but a search for "validation model" doesn't give a satisfying result. Searching for "whois validation" gives no results at all. jaap From ops.lists at gmail.com Fri Apr 6 15:51:56 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 6 Apr 2012 19:21:56 +0530 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: <20120406085300.41e898d4@shane-eeepc.home.time-travellers.org> References: <20120329105328.4dcceb0d@shane-eeepc.home.time-travellers.org> <878vijmca3.fsf@mid.deneb.enyo.de> <20120405162711.33c7e6cd@shane-eeepc.home.time-travellers.org> <20120406085300.41e898d4@shane-eeepc.home.time-travellers.org> Message-ID: On Fri, Apr 6, 2012 at 12:23 PM, Shane Kerr wrote: > Just so we're clear - I don't represent an LIR, and never have. I don't > vote on the RIPE NCC budget or the RIPE NCC board. Never said that was the case. > However companies are by and large short-sighted and selfish - even > more than human beings, since companies have neither friends nor > families. Externalized costs ("somebody else has to pay for my > expenses, increasing my profits") are good from their point of view. If that externalized cost is passed on to another department and it causes a longer term increase in overall costs - you'd hear from the CFO if that cost spiked to a strange extent. > RIPE allows not a level playing field, but one just balanced enough to > allow necessary cooperation. This is true of any forum used for So does MAAWG - you have microsoft and google and ... and comcast and att and ... the sort of companies that compete against each other, and on occasion take each other before the FTC. There's this unique kind of cooperation in both the RIPE and MAAWG communities though that cuts across organizational boundaries. It is "operational" cooperation as you will admit. > So from your point of view, there already exists a reasonable > reputation service that covers both networks and their operators. I would call it so, yes. > I guess ROKSO provides some sort of networking blacklisting automation, > right? (Or perhaps even whitelisting?) Is there a reason not to use that > for filtering and not worry whether the RIPE NCC or any other LIR has > allocated any particular addresses? Umm. That is like "I have efficient pest control in my house and I don't care that there's an uncleared garbage dump outside"? And if the spammers get themselves /13s to burn through for a period of spamming and then essentially discard, what do you do when some poor network in some part of africa (or a small dutch consulting firm for that matter) wants some v4 space? And who do you find that's going to be stupid enough to take any part of that /13 or whatever when RIPE eventually reclaims it because the guy didn't pay his bills? > I guess I was wondering if it covered literally any nefarious > activities, so that it could be used as a general reputation service. > If I am getting DoS'd or penetration tested from an ISP who doesn't do > anything about it, I'd want that sort of thing tracked too. That is for an IDS / IPS and there are blocklists that target that too - possibly much more widely known in the firewall vendor community rather than the spam filtering community. Blackhole communities, s/rtbh etc etc. Spamhaus does list DDoS botnet c2 infrastructure by the way .. http://www.spamhaus.org/sbl/query/SBL131169 for example. Only - it is mixed in with a lot of other stuff that's primarily targeted at smtp blocking so it is not exactly what you want to feed to an IDS / IPS [and you ever try stuffing 6 or 7 million IPs into an IDS's memory?] > I actually think you *should* take a 3rd-party reputation service's > opinion more seriously. Realistically the RIPE NCC will *always* have a > conflict of interest - they want to serve the wider community but their > direct members are the LIRs. (OTOH 3rd-party reputation is not a .. and maawg's members are ISPs and datacenter hosts, some of which might have bad customers downstream. But a major focus is on policy improvements to remove and/or prevent such customers from even signing on in the first place .. definitely not just working on newer and better spam filtering and reputation mechanisms. So - just relying on filters to deter spam is not going to scale, like that analogy of pest control inside your home when there's a city dump with tonnes of uncleared and rotting garbage next door. > My goal of putting some sort of forum associated with the RIPE > allocation information was to get this 3rd-party information as close > as possible to the "authoritative" information about network addresses > without triggering any conflict of interests. I never claimed it was a > completely baked idea, certainly. :-P Spamhaus does list a lot of RIPE (and ARIN, and APNIC and ..) whois listings in the record for various IP ranges that it blocks. That's as close enough I guess. The focus here is on trying to conserve a scarce resource, not let the bad guys have as much of it as they can (and lay in huge stocks of v6 for the future). If you believe v6 won't ever run out .. that's what people thought when v4 first came into the picture so I won't play futurist and second guess what's going to go on 30 years down the line. Not even given the size of v6. From fw at deneb.enyo.de Fri Apr 6 20:45:45 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 06 Apr 2012 20:45:45 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F7B117F.4050505@ripe.net> (Laura Cobley's message of "Tue, 03 Apr 2012 17:04:31 +0200") References: <4F7B117F.4050505@ripe.net> Message-ID: <87hawwaecm.fsf@mid.deneb.enyo.de> * Laura Cobley: > Using this form, you can now easily report various issues, including > abnormalities in Internet number resource registrations, to us for > further investigation. I looked at "Incorrect contact information in the RIPE Database", and "I confirm that I have reported the incorrect information to all of the contacts listed in the relevant object" is a required checkbox. This seems to require that complainants try postal addresses, phone and fax numbers before reporting errors in email addresses. Is this really your goal? Isn't this a step backwards? From joe at oregon.uoregon.edu Fri Apr 6 22:25:52 2012 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Fri, 6 Apr 2012 13:25:52 -0700 (PDT) Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form Message-ID: <12040613255230_443B@oregon.uoregon.edu> Florian commented: #I looked at "Incorrect contact information in the RIPE Database", and #"I confirm that I have reported the incorrect information to all of #the contacts listed in the relevant object" is a required checkbox. # #This seems to require that complainants try postal addresses, phone #and fax numbers before reporting errors in email addresses. Is this #really your goal? Isn't this a step backwards? I agree. >From my POV, each data element should be treated independently. The existence of a valid FAX number, for example, should not offset or eliminate the importance (or the reportability) of working to correct an invalid/non-deliverable email address. Similarly, having found an invalid field in the whois, the reporter's "responsibility" should be considered discharged upon their identifying and reporting that data to RIPE. They should not be expected to exhaust all potential contact methods, or to make multiple attempts to the broken contact channel, or to hypothetically attempt to visit the listed address in person, :-), just in order to be eligible to report a problem with data of record. The goal should be correcting potentially bad data, not making it hard to report bad data or shifting work back upon public spirited community volunteers. Regards, Joe From ops.lists at gmail.com Sat Apr 7 03:42:52 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 7 Apr 2012 07:12:52 +0530 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <12040613255230_443B@oregon.uoregon.edu> References: <12040613255230_443B@oregon.uoregon.edu> Message-ID: i agree. RIPE NCC shouldnt be trying to make it this hard to report things to them RIPE should be relying on its LIRs to reach out to customers with incomplete whois records, and possibly also collecting information on how many allocations with totally fake addresses (maildrops, empty lots) are made by a single LIR. Especially for /17 and larger, or /16 and larger netblocks. And also, a closer look at netblocks assigned to entities that are outside the normal geographical area that ripe serves. like 95.130.120.0/21registered to some entity apparently in Panama --srs On Saturday, April 7, 2012, Joe St Sauver wrote: > Florian commented: > > #I looked at "Incorrect contact information in the RIPE Database", and > #"I confirm that I have reported the incorrect information to all of > #the contacts listed in the relevant object" is a required checkbox. > # > #This seems to require that complainants try postal addresses, phone > #and fax numbers before reporting errors in email addresses. Is this > #really your goal? Isn't this a step backwards? > > I agree. > > >From my POV, each data element should be treated independently. The > existence of a valid FAX number, for example, should not offset or > eliminate the importance (or the reportability) of working to correct > an invalid/non-deliverable email address. > > Similarly, having found an invalid field in the whois, the reporter's > "responsibility" should be considered discharged upon their identifying > and reporting that data to RIPE. They should not be expected to exhaust > all potential contact methods, or to make multiple attempts to the > broken contact channel, or to hypothetically attempt to visit the > listed address in person, :-), just in order to be eligible to report > a problem with data of record. > > The goal should be correcting potentially bad data, not making it hard > to report bad data or shifting work back upon public spirited community > volunteers. > > Regards, > > Joe > > -- Suresh Ramasubramanian (ops.lists at gmail.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Sun Apr 8 14:31:40 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 08 Apr 2012 14:31:40 +0200 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: (Suresh Ramasubramanian's message of "Fri, 30 Mar 2012 09:36:38 +0530") References: <20120329144941.GB84425@Space.Net> <20120329145805.GC84425@Space.Net> <20120329150206.GD84425@Space.Net> <20120329173116.GF84425@Space.Net> <20120329174147.GG84425@Space.Net> <20120329200227.GH84425@Space.Net> Message-ID: <87ty0uz9oz.fsf@mid.deneb.enyo.de> * Suresh Ramasubramanian: > Does the average russian botmaster who submits paperwork for a new /20 > say he needs the /20 to host his botnet c&cs? I think the LIR submits a request for "dedicated server hosting for customers" to RIPE NCC. The LIR might not even know the actual purpose because it is providing infrastructure to a reseller. From ops.lists at gmail.com Sun Apr 8 14:35:15 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 8 Apr 2012 18:05:15 +0530 Subject: [anti-abuse-wg] Enabling community self-help? In-Reply-To: <87ty0uz9oz.fsf@mid.deneb.enyo.de> References: <20120329144941.GB84425@Space.Net> <20120329145805.GC84425@Space.Net> <20120329150206.GD84425@Space.Net> <20120329173116.GF84425@Space.Net> <20120329174147.GG84425@Space.Net> <20120329200227.GH84425@Space.Net> <87ty0uz9oz.fsf@mid.deneb.enyo.de> Message-ID: On Sun, Apr 8, 2012 at 6:01 PM, Florian Weimer wrote: > I think the LIR submits a request for "dedicated server hosting for > customers" to RIPE NCC. ?The LIR might not even know the actual > purpose because it is providing infrastructure to a reseller. Given the right LIR .. yes, dedicated server hosting for customers would cover that use case. Just about. They never did say what sort of customer did they? :) -- Suresh Ramasubramanian (ops.lists at gmail.com) From chrish at consol.net Tue Apr 10 14:17:50 2012 From: chrish at consol.net (chrish at consol.net) Date: Tue, 10 Apr 2012 14:17:50 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <12040613255230_443B@oregon.uoregon.edu> References: <12040613255230_443B@oregon.uoregon.edu> Message-ID: <4F8424EE.3010503@consol.net> On 04/06/2012 10:25 PM, Joe St Sauver wrote: > #This seems to require that complainants try postal addresses, phone > #and fax numbers before reporting errors in email addresses. Is this > #really your goal? Isn't this a step backwards? > > I agree. i disagree. 1) if you have a legal problem, go to a legal organisation ("police"), not ripe. clarify your legal issues there. ripe isn't the place for this. 2) i generally appreciate ripe ncc's efforts to provide adequate aid in case of any problems - nevertheless it has it's functions and tasks to stick to, letting sbdy use it to mess with ripe-external stuff inevitably has to create big trouble (and if we're talking about legal stuff: doubly so). and especially when it comes to spending money on non-ripe-tasks i strongly oppose, as i don't accept being charged for such. non-ripe-charged 'ripe-extraterritorials' creating lengthy flamey threats as to what kind of services they "demand" from ripe, i btw find - err - "curious"... 3) if the complainant isn't prepared, able, or willing to express his complaint against the alleged suspect, this probably already says it all... (ok so much: then ncc shouldn't play bully for some troll) regards, Chris From joe at oregon.uoregon.edu Tue Apr 10 17:18:00 2012 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Tue, 10 Apr 2012 08:18:00 -0700 (PDT) Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form Message-ID: <12041008180052_4495@oregon.uoregon.edu> Chris commented: #1) if you have a legal problem, go to a legal organisation ("police"), not #ripe. clarify your legal issues there. ripe isn't the place for this. Errors in registration details are not a police matter. Errors in registration details ARE directly germane to RIPE's remit as administrator of number resources, a function it provides for those in its region on behalf of the worldwide Internet community. #2) i generally appreciate ripe ncc's efforts to provide adequate aid in case of #any problems - nevertheless it has it's functions and tasks to stick to, #letting sbdy use it to mess with ripe-external stuff Maintenance of the database documenting who's been allocated/assigned space is *core* to RIPE's mission. #non-ripe-charged 'ripe-extraterritorials' creating lengthy flamey #threats as to what kind of services they "demand" from ripe, i btw #find - err - "curious"... Note that by RIPE policy, participation in RIPE Working Groups (including the Anti-Abuse Working Group) is open to all, which is, I believe, an appropriate reflection of the fact that RIPE-allocated resources can and do have an impact on users worldwide. Of course, if you take issue with that policy, you're free to propose a new policy that would change that. #3) if the complainant isn't prepared, able, or willing to express his complaint #against the alleged suspect, this probably already says it all... (ok so much: #then ncc shouldn't play bully for some troll) The question on the table was a simple one: what should be required of a party notifying RIPE of a data inaccuracy in the existing database. Should the notifying party be required to demonstrate exhaustion of all possible self-notification channels before referring the matter to RIPE as a "last resort?" No. A good Samaritan volunteer reporters has no obligation to do RIPE's work for them, and any attempt to impose arbitrary additional obligations on voluntary reporters is misplaced and inappropriate, and shows a lack of respect for the community member making that report. I see nothing wrong or inappropriate about expecting a RIR to maintain accurate records concerning the resouces it oversees, nor do I see how that makes anyone a "troll." Regards, Joe From michele at blacknight.ie Tue Apr 10 18:39:57 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Tue, 10 Apr 2012 16:39:57 +0000 Subject: [anti-abuse-wg] {Disarmed} Re: Introducing the RIPE NCC Report Form In-Reply-To: References: <12040613255230_443B@oregon.uoregon.edu>, Message-ID: <4F2538C315ACAC42AD334C533C247C47263E87F3@bkexchmbx01.blacknight.local> Suresh Just because an entity isn't based in the EU / RIPE region doesn't mean that they are up to no good or that they don't have a valid reason to have an allocation We have clients from over 120 countries and obviously a lot of those countries are outside the RIPE region. Assuming that my non-RIPE region clients are up to no good is a dangerous assumption. It also assumes that those from within the RIPE region are "kosher". I would agree with you, however, that reporting potential issues should be made as easy as possible. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________ From: anti-abuse-wg-bounces at ripe.net [anti-abuse-wg-bounces at ripe.net] on behalf of Suresh Ramasubramanian [ops.lists at gmail.com] Sent: 07 April 2012 02:42 To: Joe St Sauver Cc: fw at deneb.enyo.de; anti-abuse-wg at ripe.net Subject: {Disarmed} Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form i agree. RIPE NCC shouldnt be trying to make it this hard to report things to them RIPE should be relying on its LIRs to reach out to customers with incomplete whois records, and possibly also collecting information on how many allocations with totally fake addresses (maildrops, empty lots) are made by a single LIR. Especially for /17 and larger, or /16 and larger netblocks. And also, a closer look at netblocks assigned to entities that are outside the normal geographical area that ripe serves. like MailScanner has detected a possible fraud attempt from "95.130.120.0" claiming to be 95.130.120.0/21 registered to some entity apparently in Panama --srs On Saturday, April 7, 2012, Joe St Sauver wrote: Florian commented: #I looked at "Incorrect contact information in the RIPE Database", and #"I confirm that I have reported the incorrect information to all of #the contacts listed in the relevant object" is a required checkbox. # #This seems to require that complainants try postal addresses, phone #and fax numbers before reporting errors in email addresses. Is this #really your goal? Isn't this a step backwards? I agree. >From my POV, each data element should be treated independently. The existence of a valid FAX number, for example, should not offset or eliminate the importance (or the reportability) of working to correct an invalid/non-deliverable email address. Similarly, having found an invalid field in the whois, the reporter's "responsibility" should be considered discharged upon their identifying and reporting that data to RIPE. They should not be expected to exhaust all potential contact methods, or to make multiple attempts to the broken contact channel, or to hypothetically attempt to visit the listed address in person, :-), just in order to be eligible to report a problem with data of record. The goal should be correcting potentially bad data, not making it hard to report bad data or shifting work back upon public spirited community volunteers. Regards, Joe -- Suresh Ramasubramanian (ops.lists at gmail.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Wed Apr 11 03:38:32 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Apr 2012 07:08:32 +0530 Subject: [anti-abuse-wg] {Disarmed} Re: Introducing the RIPE NCC Report Form In-Reply-To: <4F2538C315ACAC42AD334C533C247C47263E87F3@bkexchmbx01.blacknight.local> References: <12040613255230_443B@oregon.uoregon.edu> <4F2538C315ACAC42AD334C533C247C47263E87F3@bkexchmbx01.blacknight.local> Message-ID: On Tue, Apr 10, 2012 at 10:09 PM, Michele Neylon :: Blacknight wrote: > Just because an entity isn't based in the EU / RIPE region doesn't mean that > they are up to no good or that they don't have a valid reason to have an > allocation I'm not talking about *all* out of region allocations. However a company with the german GmbH in it and with an accomodation address in Panama .. The point is that if you see signs that a range is bad, and you also see signs of strangeness in the whois, sometimes it is a good idea to correlate them The same thing with ARIN or any other RIR whois .. if you find a UPS store maildrop with a bunch of /20s mapped to it .. and each successive /20 you find is entirely populated with "something bad" .. then a full text search of the RIR's db for all netblocks registered to that UPS store might be instructive. --srs From ops.lists at gmail.com Wed Apr 11 03:40:16 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Apr 2012 07:10:16 +0530 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <12041008180052_4495@oregon.uoregon.edu> References: <12041008180052_4495@oregon.uoregon.edu> Message-ID: Joe ALWAYS says everything I want to say, in much better detail. RIPE NCC can rely on the community for reports - but not for all the due diligence that RIPE staff would normally have to perform in validating those reports On Tue, Apr 10, 2012 at 8:48 PM, Joe St Sauver wrote: > A good Samaritan volunteer reporters has no obligation to do RIPE's work > for them, and any attempt to impose arbitrary additional obligations on > voluntary reporters is misplaced and inappropriate, and shows a lack of > respect for the community member making that report. -- Suresh Ramasubramanian (ops.lists at gmail.com) From chrish at consol.net Wed Apr 11 12:03:46 2012 From: chrish at consol.net (Chris) Date: Wed, 11 Apr 2012 12:03:46 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <12041008180052_4495@oregon.uoregon.edu> References: <12041008180052_4495@oregon.uoregon.edu> Message-ID: <4F855702.6080107@consol.net> On 04/10/2012 05:18 PM, Joe St Sauver wrote: > Errors in registration details are not a police matter. if they aren't, they're not a matter at all. your private stuff isn't a public matter (interesting fact: the ancient greeks had a word for that attitude...) > Errors in registration details ARE directly germane to RIPE's remit as > administrator of number resources, a function it provides for those in > its region on behalf of the worldwide Internet community. ripe is the administration of number resources. one of the services kindly provided by ripe is a whois db. if you have an issue where that db might help you - good. that's independent from any legal issue. if you have a legal issue, and db doesn't help you, you will have to go the canonical way (you'll have to anyway, even if db tells you what you want). you have no claim towards the services sbdy provides you to be of general help. ripe knows where it allocates the space to. if judiciary asks ripe (failing or not willing to read the db), ripe tells them. actually, if sbdy else than judiciary asked, telling them would be illegal - if it wasn't data entered into a public database. to let some steam off, why don't you go to internic et al (like godaddy and whoever) with your whois db ideas, that'd be a great place to run riot, wouldn't it... and you could even pretend it's kind of your business... > Maintenance of the database documenting who's been allocated/assigned > space is *core* to RIPE's mission. simply wrong. ripe's core is allocation. that's what they do. your mission is your private error. > Note that by RIPE policy, participation in RIPE Working Groups (including just re-read my statement you are refering to. telling me that i and not you have to pay for your weirdness, i find impertinent. > party notifying RIPE of a data inaccuracy in the existing database. Should > the notifying party be required to demonstrate exhaustion of all possible > self-notification channels before referring the matter to RIPE as a "last > resort?" No. well, you know, you'll tell them "i did!" anyway. and trust me, they know that, too. and to get to the point, i just hope and am currently convinced that ncc will act apropriately according to the individual case... > A good Samaritan volunteer reporters has no obligation to do RIPE's work that's a good one. the good samaritan troll. ;)) ok, the good guy is free to report to ripe whatever he thinks he should. i think that's good. having this discussion over and over again sucks. i guess it's time to think about using the refer attribute for inet*num. regards, Chris From brian.nisbet at heanet.ie Wed Apr 11 14:13:39 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 11 Apr 2012 13:13:39 +0100 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F855702.6080107@consol.net> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> Message-ID: <4F857573.2010904@heanet.ie> Chris, "Chris" wrote the following on 11/04/2012 11:03: > On 04/10/2012 05:18 PM, Joe St Sauver wrote: >> Maintenance of the database documenting who's been allocated/assigned >> space is *core* to RIPE's mission. > > simply wrong. > ripe's core is allocation. that's what they do. your mission is your private error. http://www.ripe.net/lir-services/ncc/functions Specifically the development and maintenance of the RIPE DB. Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. I do speak for the NCC, but a substantial amount of the narrative recently has been around keeping that registry up to date and, indeed, attempting to find new and interesting ways of making sure the members put the right data in the right place. Brian. From laura at ripe.net Wed Apr 11 14:34:08 2012 From: laura at ripe.net (Laura Cobley) Date: Wed, 11 Apr 2012 14:34:08 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <87hawwaecm.fsf@mid.deneb.enyo.de> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> Message-ID: <4F857A40.3050402@ripe.net> Dear Florian and all, Over time, contact information in the RIPE Database can become outdated due to staffing changes, oversight and lack of knowledge on the part of the maintainer. Bringing the irregularity directly to the attention of this maintainer can be the quickest way to get it fixed. If you subsequently experience difficulties with this, we can help you to get in touch with the maintainer by forwarding your report to the person responsible for the Internet number resource registration. Handling reports is a normal part of our operations within the RIPE NCC and the report form makes it easier to get in touch with us. We ask you to include information such as mail delivery failure notices and copies of emails with headers, which clearly show the problem and the subsequent difficulties you are having. These help to substantiate the report. Our aim is to work together with you to further improve the quality of the data in the Internet number resource registry. Best regards, Laura Cobley RIPE NCC On 4/6/12 8:45 PM, Florian Weimer wrote: > * Laura Cobley: > >> Using this form, you can now easily report various issues, including >> abnormalities in Internet number resource registrations, to us for >> further investigation. > > I looked at "Incorrect contact information in the RIPE Database", and > "I confirm that I have reported the incorrect information to all of > the contacts listed in the relevant object" is a required checkbox. > > This seems to require that complainants try postal addresses, phone > and fax numbers before reporting errors in email addresses. Is this > really your goal? Isn't this a step backwards? > From ripe-anti-spam-wg at powerweb.de Wed Apr 11 15:17:32 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 15:17:32 +0200 Subject: [anti-abuse-wg] current business practices In-Reply-To: <4F857A40.3050402@ripe.net> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: <4F85846C.4090900@powerweb.de> Laura Cobley wrote: > Dear Florian and all, Hi, (some details from our current experiences with RIPE NCC and accuracy of the RIPE objects) we currently have one case where a really big German cablenet ISP is having exacly one abuse-eMail address for their tech-c, abuse-mailbox and admin-c, for all their objects. And this one email has a domain, what does not belong to the ISP anymore, since November 2011, its currently owned by a domain grabber, because the ISP deleted the domain on purpose (on behalf of a change in the company name years ago). There is no other working contact information (phone lets you end up at their hotline where they have absolutly no idea about abuse), snail mail is no option, fax number is not supplied. We tried mailing there peering contact, their normal customer email from their website, filled their online feedback form and then opened a normal ticket at RIPE NCC, were just told to open another ticket at RIPE NCC and invested about 5 hours already describing the problem at RIPE NCC. Simply no chance, RIPE NCC is responding to tickets on a daily basis, even during business hours (jesus, we will respond in about 5 minutes if something serious like that will happen to our networks). The interest at the RIPE NCC to fix database problems does not seem to have any priority. Ah, I forgot: the maillist server mamba.ripe.net has technical problems during the last 3 weeks, we opened tickets for that as well and even got a response once, still not fixed, the maillist server is probably not reacheable for 90% of the members ... whoever will receives this could please make a telnet mamba.ripe.net 25 from some IPs he own (best would be not using his or her usual IP, if he or she likes, lets see how big that problem really is, thats why I have to mail the most active people directly). -------- Little update: seems like RIPE NCC changed the maillist server to postgirl.ripe.net and that one works. Looks like they had to change this in a hurry, because the old server did hang in the nameserver caches quite long (great, that I have to find that out myself, instead that somebody from the RIPE NCC is simply telling me that or posting to the list). -------- Sorry, if nearly the same email comes twice now ... have to test it. So: abuse does not have priority in a lot of peoples heads those days, even when they tell you that daily ... (we have about 100 abuse incidents with that ISP monthly and the ISP even resides in the same country than we are, but its still, if they reside on the other side of the moon, maybe I should demonstrate if front of the office building with a big sign saying: "you dont have a working abuse appartment") Kind regards, Frank > > Over time, contact information in the RIPE Database can become outdated > due to staffing changes, oversight and lack of knowledge on the part of > the maintainer. Bringing the irregularity directly to the attention of > this maintainer can be the quickest way to get it fixed. > > If you subsequently experience difficulties with this, we can help you > to get in touch with the maintainer by forwarding your report to the > person responsible for the Internet number resource registration. > Handling reports is a normal part of our operations within the RIPE NCC > and the report form makes it easier to get in touch with us. > > We ask you to include information such as mail delivery failure notices > and copies of emails with headers, which clearly show the problem and > the subsequent difficulties you are having. These help to substantiate > the report. Our aim is to work together with you to further improve the > quality of the data in the Internet number resource registry. > > Best regards, > > Laura Cobley > RIPE NCC > > On 4/6/12 8:45 PM, Florian Weimer wrote: >> * Laura Cobley: >> >>> Using this form, you can now easily report various issues, including >>> abnormalities in Internet number resource registrations, to us for >>> further investigation. >> >> I looked at "Incorrect contact information in the RIPE Database", and >> "I confirm that I have reported the incorrect information to all of >> the contacts listed in the relevant object" is a required checkbox. >> >> This seems to require that complainants try postal addresses, phone >> and fax numbers before reporting errors in email addresses. Is this >> really your goal? Isn't this a step backwards? >> > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From ripe-anti-spam-wg at powerweb.de Wed Apr 11 15:37:40 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 15:37:40 +0200 Subject: [anti-abuse-wg] lists.ripe.net In-Reply-To: <20120411132917.GN84425@Space.Net> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> <20120411132917.GN84425@Space.Net> Message-ID: <4F858924.2000501@powerweb.de> Gert Doering wrote: > hi, Hi, lists.ripe.net is a simple CNAME to mamba.ripe.net without own MX records Any mailserver will try to deliver mail directly to the A record, if there are problems with the reachability of the zone, the network or the main MX records (and surely he will cache this descission). There were network issues, like RIPE NCC told me. Maybe its time to have a fallback MX for the subdomain itself ? That are pointing to postgirl.ripe.net and postlady.ripe.net ? So that no mailserver ever thinks to send mail directly to to the A record ? Just an idea .... Kind regards, Frank > > On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: >> On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast >> wrote: >>> will receives this could please make a >>> telnet mamba.ripe.net 25 >>> from some IPs he own (best would be not using his or her usual IP, >>> if he or she likes, lets see how big that problem really >>> is, thats why I have to mail the most active people directly). >> >> suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp >> Trying 2001:67c:2e8:11::c100:1328... >> Trying 193.0.19.40... >> telnet: Unable to connect to remote host: Connection refused >> >> Things seem to be RIPE for a change eh? > > So, what exactly causes the assumption that mamba is supposed to be > reachable from the outside, on Port 25? > > $ host -t mx ripe.net > ripe.net mail is handled by 250 postlady.ripe.net. > ripe.net mail is handled by 200 postgirl.ripe.net. > > Now, obviously, expecting anti-spammers to understand about MX records > and how to read Received: lines might be asking for a bit much... > > Gert Doering > -- NetMaster -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From gert at space.net Wed Apr 11 15:40:08 2012 From: gert at space.net (Gert Doering) Date: Wed, 11 Apr 2012 15:40:08 +0200 Subject: [anti-abuse-wg] lists.ripe.net In-Reply-To: <4F858924.2000501@powerweb.de> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> <20120411132917.GN84425@Space.Net> <4F858924.2000501@powerweb.de> Message-ID: <20120411134008.GP84425@Space.Net> Hi, On Wed, Apr 11, 2012 at 03:37:40PM +0200, Frank Gadegast wrote: > lists.ripe.net is a simple CNAME to mamba.ripe.net without > own MX records So what? There are no mail addresses @lists.ripe.net, so why should that host have an MX records? Even if RIPE list mail is handled at lists/mamba internally, all the mail addresses are @ripe.net - and those have MXes, and those MXes are reachable. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ripe-anti-spam-wg at powerweb.de Wed Apr 11 15:48:02 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 15:48:02 +0200 Subject: [anti-abuse-wg] current business practices In-Reply-To: References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F85846C.4090900@powerweb.de> Message-ID: <4F858B92.5060609@powerweb.de> Vissers, Pepijn wrote: > Hi Frank, Hi, > > > > Interesting story. Here in NL, we act as LEA towards an ISP if the abuse we see is related to spam and/or malware (because that is our (OPTA) function as telco regulator). In most cases, abuse reports from a law enforcement agency tend to be picked up with a little more urgency so the strategy is quite effective. > > > > If the ISP is non-cooperative, we might choose to apply a little more pressure by a subpoena of some kind. Usually applying such pressure results in a positively correlated attitude towards handling said abuse tickets. The strategy is derived from the theory of 'responsive regulation' by Braithwait. > > > > Do you have such a regulator (with investigative capabilities) who you could team up with in DE? Surely not. Its the role of RIPE NCC (too my understanding) to keep their database up-to-date. subpoena by deleting the wrong AS object from the database ;o) Pretty simple ... Kind regards, Frank > > > > Kind regards, > > Pepijn > > > >> -----Oorspronkelijk bericht----- > >> Van: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > >> bounces at ripe.net] Namens Frank Gadegast > >> Verzonden: woensdag 11 april 2012 15:18 > >> Aan: anti-abuse-wg at ripe.net > >> Onderwerp: Re: [anti-abuse-wg] current business practices > >> > >> Laura Cobley wrote: > >>> Dear Florian and all, > >> > >> Hi, > >> > >> (some details from our current experiences with RIPE NCC and accuracy > >> of the RIPE objects) > >> > >> we currently have one case where a really big German cablenet ISP is > >> having exacly one abuse-eMail address for their tech-c, abuse-mailbox > >> and admin-c, for all their objects. > >> > >> And this one email has a domain, what does not belong to the ISP > >> anymore, since November 2011, its currently owned by a domain grabber, > >> because the ISP deleted the domain on purpose (on behalf of a change in > >> the company name years ago). > >> There is no other working contact information (phone lets you end up at > >> their hotline where they have absolutly no idea about abuse), snail > >> mail is no option, fax number is not supplied. > >> > >> We tried mailing there peering contact, their normal customer email > >> from their website, filled their online feedback form and then opened a > >> normal ticket at RIPE NCC, were just told to open another ticket at > >> RIPE NCC and invested about 5 hours already describing the problem at > >> RIPE NCC. > >> Simply no chance, RIPE NCC is responding to tickets on a daily basis, > >> even during business hours (jesus, we will respond in about 5 minutes > >> if something serious like that will happen to our networks). > >> The interest at the RIPE NCC to fix database problems does not seem to > >> have any priority. > >> > >> Ah, I forgot: > >> the maillist server mamba.ripe.net has technical problems during the > >> last 3 weeks, we opened tickets for that as well and even got a > >> response once, still not fixed, the maillist server is probably not > >> reacheable for 90% of the members ... whoever will receives this could > >> please make a telnet mamba.ripe.net 25 from some IPs he own (best would > >> be not using his or her usual IP, if he or she likes, lets see how big > >> that problem really is, thats why I have to mail the most active people > >> directly). > >> > >> -------- > >> Little update: seems like RIPE NCC changed the maillist server to > >> postgirl.ripe.net and that one works. > >> Looks like they had to change this in a hurry, because the old server > >> did hang in the nameserver caches quite long (great, that I have to > >> find that out myself, instead that > >> somebody from the RIPE NCC is simply telling me that or posting > >> to the list). > >> -------- > >> Sorry, if nearly the same email comes twice now ... have to test it. > >> > >> So: abuse does not have priority in a lot of peoples heads those days, > >> even when they tell you that daily ... > >> > >> (we have about 100 abuse incidents with that ISP monthly and the ISP > >> even resides in the same country than we are, but its still, if they > >> reside on the other side of the moon, maybe I should demonstrate > >> if front of the office building with a big sign saying: > >> "you dont have a working abuse appartment") > >> > >> > >> Kind regards, Frank > >>> > >>> Over time, contact information in the RIPE Database can become > >>> outdated due to staffing changes, oversight and lack of knowledge on > >>> the part of the maintainer. Bringing the irregularity directly to the > >>> attention of this maintainer can be the quickest way to get it fixed. > >>> > >>> If you subsequently experience difficulties with this, we can help > >> you > >>> to get in touch with the maintainer by forwarding your report to the > >>> person responsible for the Internet number resource registration. > >>> Handling reports is a normal part of our operations within the RIPE > >>> NCC and the report form makes it easier to get in touch with us. > >>> > >>> We ask you to include information such as mail delivery failure > >>> notices and copies of emails with headers, which clearly show the > >>> problem and the subsequent difficulties you are having. These help to > >>> substantiate the report. Our aim is to work together with you to > >>> further improve the quality of the data in the Internet number > >> resource registry. > >>> > >>> Best regards, > >>> > >>> Laura Cobley > >>> RIPE NCC > >>> > >>> On 4/6/12 8:45 PM, Florian Weimer wrote: > >>>> * Laura Cobley: > >>>> > >>>>> Using this form, you can now easily report various issues, > >> including > >>>>> abnormalities in Internet number resource registrations, to us for > >>>>> further investigation. > >>>> > >>>> I looked at "Incorrect contact information in the RIPE Database", > >> and > >>>> "I confirm that I have reported the incorrect information to all of > >>>> the contacts listed in the relevant object" is a required checkbox. > >>>> > >>>> This seems to require that complainants try postal addresses, phone > >>>> and fax numbers before reporting errors in email addresses. Is this > >>>> really your goal? Isn't this a step backwards? > >>>> > >>> > >>> > >>> > >> > >> > >> -- > >> > >> Mit freundlichen Gruessen, > >> -- > >> MOTD: "have you enabled SSL on a website or mailbox today ?" > >> -- > >> 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 > >> ====================================================================== > >> > >> > > > > +++++++++++++++++++++++++++++++++++++++++++++ > > 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. > > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From julien at tayon.net Wed Apr 11 15:49:01 2012 From: julien at tayon.net (julien tayon) Date: Wed, 11 Apr 2012 15:49:01 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F857573.2010904@heanet.ie> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> Message-ID: 2012/4/11 Brian Nisbet : > Chris, > > "Chris" wrote the following on 11/04/2012 11:03: >> >> On 04/10/2012 05:18 PM, Joe St Sauver wrote: >>> >>> Maintenance of the database documenting who's been allocated/assigned >>> space is *core* to RIPE's mission. >> >> >> simply wrong. >> ripe's core is allocation. that's what they do. your mission is your >> private error. > > Ripe's core is at least to provide **change management** over contact on allocation of internet resources (IP, AS) so that stakeholder's can cooperate, since internet protocols relies on swift cooperation between entities. Imagine a world in which you cannot reach a LIR or RIR having wrong BGP rules ? Furthermore, RIPE NCC is bound by its contract with ICANN in its mission of allocating resources. I think reading the actual contract might settle the topic pretty fast. Since I don't have the contract under my eyes right now, I will make a simple reasoning based on public informations and personnal experience. Let's stick to the common sense of database first : *Data accuracy is the most important property of a database.* Ripe NCC is entitled to manage the whois database, therefore it is in their mission to ensure DB integrity. If it is not convincing enough, let's remember data accuracy is considered by ICANN as a **MUST DO** for delegated entities (both for gTLD and resources). Just search ICANN web sites and you'll have extended papers explaining why accuracy matters, and how this responsability is also delegated. http://www.icann.org/en/gsearch/accuracy In a world without accurate whois contact it will be the the strongest's rule that shall prevail. What tickles me is how can RIPE NCC bill instances they don't have the **accurate** contacts ? Are there 2 DBs one for billing (with accurate data) and another one for public access with inaccurate data ? RIPE NCC cant choose the parts it likes in its delegated mission from ICANN. A contract is a contract and RIPE NCC is bound by its duties regarding ICANN. If ICANN states RIPE NCC MUST have accurates data, and MUST enforce internet policies I cannot see how RIPE NCC or RIPE can decide it is does not fall into their responsabilities. Now, all everybody needs to know : * what level of accuracy ICANN can realistcly expect from its delegates ? * what are the internet policies ICANN mentions ? Cheers. -- Jul Experienced freelance for years (having worked for ISP). From ripe-anti-spam-wg at powerweb.de Wed Apr 11 16:08:11 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 16:08:11 +0200 Subject: [anti-abuse-wg] current business practices In-Reply-To: References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F85846C.4090900@powerweb.de> <4F858B92.5060609@powerweb.de> Message-ID: <4F85904B.8090203@powerweb.de> V >> subpoena by deleting the wrong AS object from the database > >> ;o) > > > > Heh. ACK on the role. But I was thinking towards urging the ISP itself to take action (once you HAVE contacted them) on the abuse complaints. That's where the pressure of a lea agency can come in handy, if such a regulator is available. > > Well, the only possibility would be the police. They do care here in Germany are kind of technical disadvanced :o( There is some organizations this ISP is a member of (like the ECO), and they have also a abuse clearing board, but that one isnt really useful because it never did anything against their members ... And why should they do something, they are not responsible for the resources ... Kind regards, Frank > > Pepijn > > +++++++++++++++++++++++++++++++++++++++++++++ > > 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. > > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From Chris.Heinze at consol.de Wed Apr 11 14:49:13 2012 From: Chris.Heinze at consol.de (Chris Heinze) Date: Wed, 11 Apr 2012 14:49:13 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F857573.2010904@heanet.ie> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> Message-ID: <4F857DC9.8060905@consol.de> On 04/11/2012 02:13 PM, Brian Nisbet wrote: >> ripe's core is allocation. that's what they do. your mission is your private error. > > http://www.ripe.net/lir-services/ncc/functions right, that sums it up nicely, thanks. > Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. ripe's job isn't defined by and doesn't depend on whether or not v4 space is completely allocated (which it btw probably never will). keeping a good registry is as explained a service kindly provided by ripe to help - and it did that since the beginning. regards, Chris From gert at space.net Wed Apr 11 15:29:17 2012 From: gert at space.net (Gert Doering) Date: Wed, 11 Apr 2012 15:29:17 +0200 Subject: [anti-abuse-wg] current business practices In-Reply-To: References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> Message-ID: <20120411132917.GN84425@Space.Net> hi, On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > wrote: > > will receives this could please make a > > telnet mamba.ripe.net 25 > > from some IPs he own (best would be not using his or her usual IP, > > if he or she likes, lets see how big that problem really > > is, thats why I have to mail the most active people directly). > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > Trying 2001:67c:2e8:11::c100:1328... > Trying 193.0.19.40... > telnet: Unable to connect to remote host: Connection refused > > Things seem to be RIPE for a change eh? So, what exactly causes the assumption that mamba is supposed to be reachable from the outside, on Port 25? $ host -t mx ripe.net ripe.net mail is handled by 250 postlady.ripe.net. ripe.net mail is handled by 200 postgirl.ripe.net. Now, obviously, expecting anti-spammers to understand about MX records and how to read Received: lines might be asking for a bit much... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From michele at blacknight.ie Wed Apr 11 15:32:48 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 11 Apr 2012 13:32:48 +0000 Subject: [anti-abuse-wg] current business practices In-Reply-To: <20120411132917.GN84425@Space.Net> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> , <20120411132917.GN84425@Space.Net> Message-ID: <4F2538C315ACAC42AD334C533C247C47263EFF60@bkexchmbx01.blacknight.local> So this list is now turned into an "experts" exchange on SMTP? *sigh* -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________________ From: Gert Doering [gert at space.net] Sent: 11 April 2012 14:29 To: Suresh Ramasubramanian Cc: Frank Gadegast; Laura Cobley; Florian Weimer; anti-abuse-wg at ripe.net; Brian Nisbet; chrish at consol.net; shane at time-travellers.org; Michele Neylon :: Blacknight; Gert Doering; Tobias Knecht Subject: Re: [anti-abuse-wg] current business practices hi, On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > wrote: > > will receives this could please make a > > telnet mamba.ripe.net 25 > > from some IPs he own (best would be not using his or her usual IP, > > if he or she likes, lets see how big that problem really > > is, thats why I have to mail the most active people directly). > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > Trying 2001:67c:2e8:11::c100:1328... > Trying 193.0.19.40... > telnet: Unable to connect to remote host: Connection refused > > Things seem to be RIPE for a change eh? So, what exactly causes the assumption that mamba is supposed to be reachable from the outside, on Port 25? $ host -t mx ripe.net ripe.net mail is handled by 250 postlady.ripe.net. ripe.net mail is handled by 200 postgirl.ripe.net. Now, obviously, expecting anti-spammers to understand about MX records and how to read Received: lines might be asking for a bit much... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ops.lists at gmail.com Wed Apr 11 15:20:02 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Apr 2012 18:50:02 +0530 Subject: [anti-abuse-wg] current business practices In-Reply-To: <4F8580CD.4000502@powerweb.de> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> Message-ID: On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast wrote: > will receives this could please make a > telnet mamba.ripe.net 25 > from some IPs he own (best would be not using his or her usual IP, > if he or she likes, lets see how big that problem really > is, thats why I have to mail the most active people directly). suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp Trying 2001:67c:2e8:11::c100:1328... Trying 193.0.19.40... telnet: Unable to connect to remote host: Connection refused Things seem to be RIPE for a change eh? -- Suresh Ramasubramanian (ops.lists at gmail.com) From ripe-anti-spam-wg at powerweb.de Wed Apr 11 15:02:05 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 15:02:05 +0200 Subject: [anti-abuse-wg] current business practices In-Reply-To: <4F857A40.3050402@ripe.net> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: <4F8580CD.4000502@powerweb.de> Laura Cobley wrote: > Dear Florian and all, Hi, (some details from our current experiences with RIPE NCC and accuracy of the RIPE objects) we currently have one case where a really big German cablenet ISP is having exacly one abuse-eMail address for their tech-c, abuse-mailbox and admin-c, for all their objects. And this one email has a domain, what does not belong to the ISP anymore, since November 2011, its currently owned by a domain grabber, because the ISP deleted the domain on purpose (on behalf of a change in the company name years ago). There is no other working contact information (phone lets you end up at their hotline where they have absolutly no idea about abuse), snail mail is no option, fax number is not supplied. We tried mailing there peering contact, their normal customer email from their website, filled their online feedback form and then opened a normal ticket at RIPE NCC, were just told to open another ticket at RIPE NCC and invested about 5 hours already describing the problem at RIPE NCC. Simply no chance, RIPE NCC is responding to tickets on a daily basis, even during business hours (jesus, we will respond in about 5 minutes if something serious like that will happen to our networks). The interest at the RIPE NCC to fix database problems does not seem to have any priority. Ah, I forgot: the maillist server mamba.ripe.net has technical problems during the last 3 weeks, we opened tickets for that as well and even got a response once, still not fixed, the maillist server is probably not reacheable for 90% of the members ... whoever will receives this could please make a telnet mamba.ripe.net 25 from some IPs he own (best would be not using his or her usual IP, if he or she likes, lets see how big that problem really is, thats why I have to mail the most active people directly). So: abuse does not have priority in a lot of peoples heads those days, even when they tell you that daily ... (we have about 100 abuse incidents with that ISP monthly and the ISP even resides in the same country than we are, but its still, if they reside on the other side of the moon, maybe I should demonstrate if front of the office building with a big sign saying: "you dont have a working abuse appartment") Kind regards, Frank > > Over time, contact information in the RIPE Database can become outdated > due to staffing changes, oversight and lack of knowledge on the part of > the maintainer. Bringing the irregularity directly to the attention of > this maintainer can be the quickest way to get it fixed. > > If you subsequently experience difficulties with this, we can help you > to get in touch with the maintainer by forwarding your report to the > person responsible for the Internet number resource registration. > Handling reports is a normal part of our operations within the RIPE NCC > and the report form makes it easier to get in touch with us. > > We ask you to include information such as mail delivery failure notices > and copies of emails with headers, which clearly show the problem and > the subsequent difficulties you are having. These help to substantiate > the report. Our aim is to work together with you to further improve the > quality of the data in the Internet number resource registry. > > Best regards, > > Laura Cobley > RIPE NCC > > On 4/6/12 8:45 PM, Florian Weimer wrote: >> * Laura Cobley: >> >>> Using this form, you can now easily report various issues, including >>> abnormalities in Internet number resource registrations, to us for >>> further investigation. >> >> I looked at "Incorrect contact information in the RIPE Database", and >> "I confirm that I have reported the incorrect information to all of >> the contacts listed in the relevant object" is a required checkbox. >> >> This seems to require that complainants try postal addresses, phone >> and fax numbers before reporting errors in email addresses. Is this >> really your goal? Isn't this a step backwards? >> > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From ripe-anti-spam-wg at powerweb.de Wed Apr 11 16:35:57 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 16:35:57 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F857DC9.8060905@consol.de> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F857DC9.8060905@consol.de> Message-ID: <4F8596CD.5020009@powerweb.de> Chris Heinze wrote: > On 04/11/2012 02:13 PM, Brian Nisbet wrote: >>> ripe's core is allocation. that's what they do. your mission is your private error. >> >> http://www.ripe.net/lir-services/ncc/functions > > right, that sums it up nicely, thanks. > >> Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. > > ripe's job isn't defined by and doesn't depend on whether or not v4 space is completely allocated (which it btw probably never will). > keeping a good registry is as explained a service kindly provided by ripe to help - and it did that since the beginning. > Hm, current stats here for April (worldwide): - 4.112 abuse reports submitted - about 800 whois records without any email address - about 600 reports returned with "user unknown" - about 150 reports returned with "mailserver unreachable" - about 100 reports returned with "mailbox full" 30% spam and abuse from the RIPE region (russia alone has 11,18% here with us). A quick estimation shows me, that we find about 1000 objects in RIPEs database PER MONTH, that have none or a not working abuse email contact. Maybe the RIPE NCC tries, but they do not try hard enough ... Kind regards, Frank > regards, > > Chris > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From P.Vissers at opta.nl Wed Apr 11 16:44:57 2012 From: P.Vissers at opta.nl (Vissers, Pepijn) Date: Wed, 11 Apr 2012 14:44:57 +0000 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F8596CD.5020009@powerweb.de> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F857DC9.8060905@consol.de> <4F8596CD.5020009@powerweb.de> Message-ID: > Hm, current stats here for April (worldwide): Whoa. Frank, I will be in touch with you pretty soon. I have been pondering on something for quite a while and, well, the time seems to be ripe (pun.. thanks srsh). +++++++++++++++++++++++++++++++++++++++++++++ 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. From brian.nisbet at heanet.ie Wed Apr 11 16:48:01 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 11 Apr 2012 15:48:01 +0100 Subject: [anti-abuse-wg] lists.ripe.net In-Reply-To: <20120411134008.GP84425@Space.Net> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> <20120411132917.GN84425@Space.Net> <4F858924.2000501@powerweb.de> <20120411134008.GP84425@Space.Net> Message-ID: <4F8599A1.9010209@heanet.ie> Folks, this is absolutely not the place to discuss the NCC's mailservers. If the conversation has to happen at all, then I'm sure NCC Services would love to hear about it. :) Brian. "Gert Doering" wrote the following on 11/04/2012 14:40: > Hi, > > On Wed, Apr 11, 2012 at 03:37:40PM +0200, Frank Gadegast wrote: >> lists.ripe.net is a simple CNAME to mamba.ripe.net without >> own MX records > > So what? There are no mail addresses @lists.ripe.net, so why should > that host have an MX records? > > Even if RIPE list mail is handled at lists/mamba internally, all the mail > addresses are @ripe.net - and those have MXes, and those MXes are reachable. > > Gert Doering > -- NetMaster From ripe-anti-spam-wg at powerweb.de Wed Apr 11 17:01:12 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 17:01:12 +0200 Subject: [anti-abuse-wg] lists.ripe.net In-Reply-To: <4F8599A1.9010209@heanet.ie> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> <20120411132917.GN84425@Space.Net> <4F858924.2000501@powerweb.de> <20120411134008.GP84425@Space.Net> <4F8599A1.9010209@heanet.ie> Message-ID: <4F859CB8.5080903@powerweb.de> Brian Nisbet wrote: > Folks, this is absolutely not the place to discuss the NCC's mailservers. Hm, dont think so, because the lists itself was kind of broken and I mailed the RIPE NCC about 3 weeks ago about it (and you two twice) before I tried to get this solve with the help of other on this list (and they finally help in minutes, a good example how the community is working better and quicker than organisations). At least we could figure out that the address anti-abuse-wg at lists.ripe.net was used and working once, but is not anymore. > If the conversation has to happen at all, then I'm sure NCC Services > would love to hear about it. :) They did not care at all, the ticket is now 3 weeks old. One useless response and no answer to another too mails to the same ticket. And because the discussion here was about the priorities of RIPE NCCs work I thought, this is a good example. Kind regards, Frank P.S.: want to hear more details of my case with that cablenet ISP and how RIPE NCC handled it ? ok, will not sent THAT to the list, but anyone can mail me directly, if he wants to shiver ... > Brian. > > "Gert Doering" wrote the following on 11/04/2012 14:40: >> Hi, >> >> On Wed, Apr 11, 2012 at 03:37:40PM +0200, Frank Gadegast wrote: >>> lists.ripe.net is a simple CNAME to mamba.ripe.net without >>> own MX records >> >> So what? There are no mail addresses @lists.ripe.net, so why should >> that host have an MX records? >> >> Even if RIPE list mail is handled at lists/mamba internally, all the mail >> addresses are @ripe.net - and those have MXes, and those MXes are >> reachable. >> >> Gert Doering >> -- NetMaster > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From fw at deneb.enyo.de Wed Apr 11 17:31:51 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 11 Apr 2012 17:31:51 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F857A40.3050402@ripe.net> (Laura Cobley's message of "Wed, 11 Apr 2012 14:34:08 +0200") References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: <87iph6xp20.fsf@mid.deneb.enyo.de> * Laura Cobley: > We ask you to include information such as mail delivery failure notices > and copies of emails with headers, which clearly show the problem and > the subsequent difficulties you are having. These help to substantiate > the report. Our aim is to work together with you to further improve the > quality of the data in the Internet number resource registry. Laura, I'm afraid you haven't answered my question. Let's suppose I've experienced a reproducible email delivery issue which affects a role object. I have reported this to related role and person objects by *email*, but after a reasonable time period, the situation has not been addressed. I have not sent letters to the postal addresses of those objects, or have tried the phone and fax numbers. Can I still use the report form? Sorry if this comes across as obnoxious, but among WHOIS operators, there is a whole spectrum of policies regarding incorrect contact information, ranging from "we care about a single incorrect email address" to "we need proof that mail cannot be delivered to that postal address *and* that no one by that name lives or does business at that place". I'm just curious where RIPE NCC is located on this spectrum. From ops.lists at gmail.com Wed Apr 11 17:34:59 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Apr 2012 21:04:59 +0530 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F8596CD.5020009@powerweb.de> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F857DC9.8060905@consol.de> <4F8596CD.5020009@powerweb.de> Message-ID: <8B10348C-CE6C-40EF-B70D-89EAD1C6A06C@gmail.com> did you aggregate those reports by cidr / asn / shared ns or shared whois for the domain etc? --srs (iPad) On 11-Apr-2012, at 20:05, Frank Gadegast wrote: > Chris Heinze wrote: >> On 04/11/2012 02:13 PM, Brian Nisbet wrote: >>>> ripe's core is allocation. that's what they do. your mission is your private error. >>> >>> http://www.ripe.net/lir-services/ncc/functions >> >> right, that sums it up nicely, thanks. >> >>> Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. >> >> ripe's job isn't defined by and doesn't depend on whether or not v4 space is completely allocated (which it btw probably never will). >> keeping a good registry is as explained a service kindly provided by ripe to help - and it did that since the beginning. >> > > Hm, current stats here for April (worldwide): > > - 4.112 abuse reports submitted > - about 800 whois records without any email address > - about 600 reports returned with "user unknown" > - about 150 reports returned with "mailserver unreachable" > - about 100 reports returned with "mailbox full" > > 30% spam and abuse from the RIPE region (russia alone has 11,18% here > with us). > > A quick estimation shows me, that we find about 1000 objects in RIPEs > database PER MONTH, that have none or a not working abuse email contact. > > Maybe the RIPE NCC tries, but they do not try hard enough ... > > > Kind regards, Frank > >> regards, >> >> Chris >> >> >> > > > -- > > Mit freundlichen Gruessen, > -- > MOTD: "have you enabled SSL on a website or mailbox today ?" > -- > 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 > ====================================================================== > > From denatrisconsult at hotmail.nl Wed Apr 11 17:38:11 2012 From: denatrisconsult at hotmail.nl (Wout de Natris) Date: Wed, 11 Apr 2012 17:38:11 +0200 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 9 In-Reply-To: References: Message-ID: "Re: Contents of anti-abuse-wg digest..." Why does this discussion take so many words and arguments? 1. Primarily RIPE NCC needs or at least should need a proper overview of who its members are for several reasons that all have to do with internal processes like reaching out, billing and maintaining correct records, in short common business practice. 2. There is an abuse function for well ... abuse, so members can reach out to each other and amend whatever goes wrong. All this isn't strange or weird, but normal practice for any company, club, association, etc. As soon as an address isn't correct the company, club, association, university, etc. reaches out to the customer, member, student concerned in order to get new relevant data, so it can do billing, maintenance of records, send news, etc. If the customer, member, et al, does not respond, steps are taken to terminate the relation. This is common practice to any company, club, association, etc. and has, primarily, nothing to do with law enforcement of any kind, but with customer/member relations, correct records, due payment, etc. So how come that as soon as this discussion is about the Internet, whether domain name registrations or in this case IP addresses, this totally normal form of doing business is denied as being standard practice? If data is not correct and there is no way the, in this case RIPE NCC, member can be found, it is not so strange that, after a published notice with a due time frame, a relation is terminated. Certainly in a period of scarcity in IPv4 addresses, this should be common practice. (And if it happens to concern a criminal organisation, they won't show up any way. All others will within about 2 seconds of termination.) So if correct data is standard practice and law enforcement needs them for whatever reason, they can access this data either through Whois of through correct proceedings in the Dutch law. Like it should be. Correct data saves money in the end, for all concerned, and makes becoming a member less attractive for individuals or organisations that most of us agree don't need a place on the internet. I don't think LEAs ask for more than that, but as a RIPE member I would look at my own organisation first. LEAs need to deal with LIRs more than an RIR, I'd guess, so assist them in finding these LIRs. Wout > From: anti-abuse-wg-request at ripe.net > Subject: anti-abuse-wg Digest, Vol 8, Issue 9 > To: anti-abuse-wg at ripe.net > Date: Wed, 11 Apr 2012 16:13:31 +0200 > > 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. Re: Introducing the RIPE NCC Report Form (julien tayon) > 2. Re: current business practices (Frank Gadegast) > 3. Re: Introducing the RIPE NCC Report Form (Chris Heinze) > 4. Re: current business practices (Gert Doering) > 5. Re: current business practices (Michele Neylon :: Blacknight) > 6. Re: current business practices (Suresh Ramasubramanian) > 7. Re: current business practices (Frank Gadegast) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 11 Apr 2012 15:49:01 +0200 > From: julien tayon > Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form > To: Brian Nisbet > Cc: anti-abuse-wg at ripe.net > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > 2012/4/11 Brian Nisbet : > > Chris, > > > > "Chris" wrote the following on 11/04/2012 11:03: > >> > >> On 04/10/2012 05:18 PM, Joe St Sauver wrote: > >>> > >>> Maintenance of the database documenting who's been allocated/assigned > >>> space is *core* to RIPE's mission. > >> > >> > >> simply wrong. > >> ripe's core is allocation. that's what they do. your mission is your > >> private error. > > > > > Ripe's core is at least to provide **change management** over > contact on allocation of internet resources (IP, AS) so that > stakeholder's can cooperate, since internet protocols relies on swift > cooperation between entities. Imagine a world in which you cannot > reach a LIR or RIR having wrong BGP rules ? > > Furthermore, RIPE NCC is bound by its contract with ICANN in its > mission of allocating resources. I think reading the actual contract > might settle the topic pretty fast. > > Since I don't have the contract under my eyes right now, I will make a > simple reasoning based on public informations and personnal > experience. > > Let's stick to the common sense of database first : > *Data accuracy is the most important property of a database.* Ripe NCC > is entitled to manage the whois database, therefore it is in their > mission to ensure DB integrity. > > If it is not convincing enough, let's remember data accuracy is > considered by ICANN as a **MUST DO** for delegated entities (both for > gTLD and resources). > Just search ICANN web sites and you'll have extended papers explaining > why accuracy matters, and how this responsability is also delegated. > http://www.icann.org/en/gsearch/accuracy > > In a world without accurate whois contact it will be the the > strongest's rule that shall prevail. > > What tickles me is how can RIPE NCC bill instances they don't have the > **accurate** contacts ? Are there 2 DBs one for billing (with accurate > data) and another one for public access with inaccurate data ? > > RIPE NCC cant choose the parts it likes in its delegated mission from > ICANN. A contract is a contract and RIPE NCC is bound by its duties > regarding ICANN. If ICANN states RIPE NCC MUST have accurates data, > and MUST enforce internet policies I cannot see how RIPE NCC or RIPE > can decide it is does not fall into their responsabilities. > > Now, all everybody needs to know : > * what level of accuracy ICANN can realistcly expect from its delegates ? > * what are the internet policies ICANN mentions ? > > Cheers. > > -- > Jul > Experienced freelance for years (having worked for ISP). > > > > ------------------------------ > > Message: 2 > Date: Wed, 11 Apr 2012 16:08:11 +0200 > From: Frank Gadegast > Subject: Re: [anti-abuse-wg] current business practices > To: "anti-abuse-wg at ripe.net" > Message-ID: <4F85904B.8090203 at powerweb.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > V > > >> > subpoena by deleting the wrong AS object from the database > > > >> ;o) > > > > > > > > Heh. ACK on the role. But I was thinking towards urging the ISP itself to take action (once you HAVE contacted them) on the abuse complaints. That's where the pressure of a lea agency can come in handy, if such a regulator is available. > > > > > > Well, the only possibility would be the police. > They do care here in Germany are kind of > technical disadvanced :o( > > There is some organizations this ISP is a member of > (like the ECO), and they have also a abuse clearing > board, but that one isnt really useful because > it never did anything against their members ... > > And why should they do something, they are not > responsible for the resources ... > > > Kind regards, Frank > > > > > Pepijn > > > > +++++++++++++++++++++++++++++++++++++++++++++ > > > > 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. > > > > > > > > > > > > > -- > > Mit freundlichen Gruessen, > -- > MOTD: "have you enabled SSL on a website or mailbox today ?" > -- > 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 > ====================================================================== > > > > > ------------------------------ > > Message: 3 > Date: Wed, 11 Apr 2012 14:49:13 +0200 > From: Chris Heinze > Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form > To: anti-abuse-wg at ripe.net > Message-ID: <4F857DC9.8060905 at consol.de> > Content-Type: text/plain; charset=UTF-8 > > On 04/11/2012 02:13 PM, Brian Nisbet wrote: > >> ripe's core is allocation. that's what they do. your mission is your private error. > > > > http://www.ripe.net/lir-services/ncc/functions > > right, that sums it up nicely, thanks. > > > Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. > > ripe's job isn't defined by and doesn't depend on whether or not v4 space is completely allocated (which it btw probably never will). > keeping a good registry is as explained a service kindly provided by ripe to help - and it did that since the beginning. > > regards, > > Chris > > > > ------------------------------ > > Message: 4 > Date: Wed, 11 Apr 2012 15:29:17 +0200 > From: Gert Doering > Subject: Re: [anti-abuse-wg] current business practices > To: Suresh Ramasubramanian > Cc: shane at time-travellers.org, Brian Nisbet , > anti-abuse-wg at ripe.net, Tobias Knecht , "Michele Neylon > :: Blacknight" , Laura Cobley , > Florian Weimer , Frank Gadegast > , Gert Doering > Message-ID: <20120411132917.GN84425 at Space.Net> > Content-Type: text/plain; charset="us-ascii" > > hi, > > On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: > > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > > wrote: > > > will receives this could please make a > > > telnet mamba.ripe.net 25 > > > from some IPs he own (best would be not using his or her usual IP, > > > if he or she likes, lets see how big that problem really > > > is, thats why I have to mail the most active people directly). > > > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > > Trying 2001:67c:2e8:11::c100:1328... > > Trying 193.0.19.40... > > telnet: Unable to connect to remote host: Connection refused > > > > Things seem to be RIPE for a change eh? > > So, what exactly causes the assumption that mamba is supposed to be > reachable from the outside, on Port 25? > > $ host -t mx ripe.net > ripe.net mail is handled by 250 postlady.ripe.net. > ripe.net mail is handled by 200 postgirl.ripe.net. > > Now, obviously, expecting anti-spammers to understand about MX records > and how to read Received: lines might be asking for a bit much... > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 306 bytes > Desc: not available > Url : https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20120411/76082102/attachment-0001.bin > > ------------------------------ > > Message: 5 > Date: Wed, 11 Apr 2012 13:32:48 +0000 > From: "Michele Neylon :: Blacknight" > Subject: Re: [anti-abuse-wg] current business practices > To: Gert Doering , Suresh Ramasubramanian > > Cc: "shane at time-travellers.org" , Brian > Nisbet , "anti-abuse-wg at ripe.net" > , Tobias Knecht , Laura Cobley > , Florian Weimer , Frank Gadegast > > Message-ID: > <4F2538C315ACAC42AD334C533C247C47263EFF60 at bkexchmbx01.blacknight.local> > > Content-Type: text/plain; charset="us-ascii" > > So this list is now turned into an "experts" exchange on SMTP? > > *sigh* > > -- > Mr Michele Neylon > Blacknight Solutions > Hosting & Colocation, Brand Protection > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://mneylon.tel/ > Intl. +353 (0) 59 9183072 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > ________________________________________ > From: Gert Doering [gert at space.net] > Sent: 11 April 2012 14:29 > To: Suresh Ramasubramanian > Cc: Frank Gadegast; Laura Cobley; Florian Weimer; anti-abuse-wg at ripe.net; Brian Nisbet; chrish at consol.net; shane at time-travellers.org; Michele Neylon :: Blacknight; Gert Doering; Tobias Knecht > Subject: Re: [anti-abuse-wg] current business practices > > hi, > > On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: > > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > > wrote: > > > will receives this could please make a > > > telnet mamba.ripe.net 25 > > > from some IPs he own (best would be not using his or her usual IP, > > > if he or she likes, lets see how big that problem really > > > is, thats why I have to mail the most active people directly). > > > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > > Trying 2001:67c:2e8:11::c100:1328... > > Trying 193.0.19.40... > > telnet: Unable to connect to remote host: Connection refused > > > > Things seem to be RIPE for a change eh? > > So, what exactly causes the assumption that mamba is supposed to be > reachable from the outside, on Port 25? > > $ host -t mx ripe.net > ripe.net mail is handled by 250 postlady.ripe.net. > ripe.net mail is handled by 200 postgirl.ripe.net. > > Now, obviously, expecting anti-spammers to understand about MX records > and how to read Received: lines might be asking for a bit much... > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > > > ------------------------------ > > Message: 6 > Date: Wed, 11 Apr 2012 18:50:02 +0530 > From: Suresh Ramasubramanian > Subject: Re: [anti-abuse-wg] current business practices > To: Frank Gadegast > Cc: shane at time-travellers.org, Brian Nisbet , > anti-abuse-wg at ripe.net, Tobias Knecht , "Michele Neylon > :: Blacknight" , Laura Cobley , > Florian Weimer , Gert Doering > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > wrote: > > will receives this could please make a > > telnet mamba.ripe.net 25 > > from some IPs he own (best would be not using his or her usual IP, > > if he or she likes, lets see how big that problem really > > is, thats why I have to mail the most active people directly). > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > Trying 2001:67c:2e8:11::c100:1328... > Trying 193.0.19.40... > telnet: Unable to connect to remote host: Connection refused > > Things seem to be RIPE for a change eh? > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > > > ------------------------------ > > Message: 7 > Date: Wed, 11 Apr 2012 15:02:05 +0200 > From: Frank Gadegast > Subject: Re: [anti-abuse-wg] current business practices > To: Laura Cobley > Cc: shane at time-travellers.org, Brian Nisbet , > anti-abuse-wg at ripe.net, Tobias Knecht , "Michele Neylon > :: Blacknight" , Florian Weimer > , ops.lists at gmail.com, Gert Doering > Message-ID: <4F8580CD.4000502 at powerweb.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Laura Cobley wrote: > > Dear Florian and all, > > Hi, > > (some details from our current experiences with RIPE NCC and accuracy > of the RIPE objects) > > we currently have one case where a really big German cablenet ISP > is having exacly one abuse-eMail address for their tech-c, abuse-mailbox > and admin-c, for all their objects. > > And this one email has a domain, what does not belong to the ISP > anymore, since November 2011, its currently owned by a domain grabber, > because the ISP deleted the domain on purpose (on behalf of a > change in the company name years ago). > There is no other working contact information (phone lets you end up at > their hotline where they have absolutly no idea about abuse), snail mail > is no option, fax number is not supplied. > > We tried mailing there peering contact, their normal customer email > from their website, filled their online feedback form and then > opened a normal ticket at RIPE NCC, were just told > to open another ticket at RIPE NCC and invested about 5 hours > already describing the problem at RIPE NCC. > Simply no chance, RIPE NCC is responding to tickets on a daily basis, > even during business hours (jesus, we will respond in about 5 minutes > if something serious like that will happen to our networks). > The interest at the RIPE NCC to fix database problems does not seem > to have any priority. > > Ah, I forgot: > the maillist server mamba.ripe.net has technical problems during > the last 3 weeks, we opened tickets for that as well and even > got a response once, still not fixed, the maillist server > is probably not reacheable for 90% of the members ... whoever > will receives this could please make a > telnet mamba.ripe.net 25 > from some IPs he own (best would be not using his or her usual IP, > if he or she likes, lets see how big that problem really > is, thats why I have to mail the most active people directly). > > So: abuse does not have priority in a lot of peoples heads those days, > even when they tell you that daily ... > > (we have about 100 abuse incidents with that ISP monthly and the ISP > even resides in the same country than we are, but its still, if they > reside on the other side of the moon, maybe I should demonstrate > if front of the office building with a big sign saying: > "you dont have a working abuse appartment") > > > Kind regards, Frank > > > > Over time, contact information in the RIPE Database can become outdated > > due to staffing changes, oversight and lack of knowledge on the part of > > the maintainer. Bringing the irregularity directly to the attention of > > this maintainer can be the quickest way to get it fixed. > > > > If you subsequently experience difficulties with this, we can help you > > to get in touch with the maintainer by forwarding your report to the > > person responsible for the Internet number resource registration. > > Handling reports is a normal part of our operations within the RIPE NCC > > and the report form makes it easier to get in touch with us. > > > > We ask you to include information such as mail delivery failure notices > > and copies of emails with headers, which clearly show the problem and > > the subsequent difficulties you are having. These help to substantiate > > the report. Our aim is to work together with you to further improve the > > quality of the data in the Internet number resource registry. > > > > Best regards, > > > > Laura Cobley > > RIPE NCC > > > > On 4/6/12 8:45 PM, Florian Weimer wrote: > >> * Laura Cobley: > >> > >>> Using this form, you can now easily report various issues, including > >>> abnormalities in Internet number resource registrations, to us for > >>> further investigation. > >> > >> I looked at "Incorrect contact information in the RIPE Database", and > >> "I confirm that I have reported the incorrect information to all of > >> the contacts listed in the relevant object" is a required checkbox. > >> > >> This seems to require that complainants try postal addresses, phone > >> and fax numbers before reporting errors in email addresses. Is this > >> really your goal? Isn't this a step backwards? > >> > > > > > > > > > -- > > Mit freundlichen Gruessen, > -- > MOTD: "have you enabled SSL on a website or mailbox today ?" > -- > 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 > ====================================================================== > > > > > End of anti-abuse-wg Digest, Vol 8, Issue 9 > ******************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at blacknight.ie Wed Apr 11 17:55:23 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 11 Apr 2012 15:55:23 +0000 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 9 In-Reply-To: References: Message-ID: On 11 Apr 2012, at 16:38, Wout de Natris wrote: > "Re: Contents of anti-abuse-wg digest..." > > > Why does this discussion take so many words and arguments? > > 1. Primarily RIPE NCC needs or at least should need a proper overview of who its members are for several reasons that all have to do with internal processes like reaching out, billing and maintaining correct records, in short common business practice. Which it already has and does. > > 2. There is an abuse function for well ? abuse Where? As has been discussed to death on this list (and elsewhere) there currently isn't a standardised abuse contact for an IP range and there is no obligation for any LIR to assign an abuse object (that they may designate) to an IP or range of IPs or are you referring to something else? > , so members can reach out to each other and amend whatever goes wrong. > > All this isn't strange or weird, but normal practice for any company, club, association, etc. As soon as an address isn't correct the company, club, association, university, etc. reaches out to the customer, member, student concerned in order to get new relevant data, so it can do billing, maintenance of records, send news, etc. If the customer, member, et al, does not respond, steps are taken to terminate the relation. This is common practice to any company, club, association, etc. and has, primarily, nothing to do with law enforcement of any kind, but with customer/member relations, correct records, due payment, etc. > > So how come that as soon as this discussion is about the Internet, whether domain name registrations or in this case IP addresses, this totally normal form of doing business is denied as being standard practice? If data is not correct and there is no way the, in this case RIPE NCC, And here is where your logic breaks very badly While all IP addresses are going to be assigned to LIRs a lot of the discussion is about IP objects and blocks - these are usually assigned to LIR's customers RIPE can contact the LIR The LIR can probably contact their customer The disjoint could be in the database BUT Assuming like you have that an entry in the database can only relate directly to a LIR is wrong. > member can be found, it is not so strange that, after a published notice with a due time frame, a relation is terminated. Certainly in a period of scarcity in IPv4 addresses, this should be common practice. (And if it happens to concern a criminal organisation, they won't show up any way. All others will within about 2 seconds of termination.) > > So if correct data is standard practice and law enforcement needs them for whatever reason, they can access this data either through Whois of through correct proceedings in the Dutch law. Like it should be. Correct data saves money in the end, for all concerned, and makes becoming a member less attractive for individuals or organisations that most of us agree don't need a place on the internet. I don't think LEAs ask for more than that, but as a RIPE member I would look at my own organisation first. LEAs need to deal with LIRs more than an RIR, I'd guess, so assist them in finding these LIRs. > > Wout > > > > From: anti-abuse-wg-request at ripe.net > > Subject: anti-abuse-wg Digest, Vol 8, Issue 9 > > To: anti-abuse-wg at ripe.net > > Date: Wed, 11 Apr 2012 16:13:31 +0200 > > > > 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. Re: Introducing the RIPE NCC Report Form (julien tayon) > > 2. Re: current business practices (Frank Gadegast) > > 3. Re: Introducing the RIPE NCC Report Form (Chris Heinze) > > 4. Re: current business practices (Gert Doering) > > 5. Re: current business practices (Michele Neylon :: Blacknight) > > 6. Re: current business practices (Suresh Ramasubramanian) > > 7. Re: current business practices (Frank Gadegast) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 11 Apr 2012 15:49:01 +0200 > > From: julien tayon > > Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form > > To: Brian Nisbet > > Cc: anti-abuse-wg at ripe.net > > Message-ID: > > > > Content-Type: text/plain; charset=UTF-8 > > > > 2012/4/11 Brian Nisbet : > > > Chris, > > > > > > "Chris" wrote the following on 11/04/2012 11:03: > > >> > > >> On 04/10/2012 05:18 PM, Joe St Sauver wrote: > > >>> > > >>> Maintenance of the database documenting who's been allocated/assigned > > >>> space is *core* to RIPE's mission. > > >> > > >> > > >> simply wrong. > > >> ripe's core is allocation. that's what they do. your mission is your > > >> private error. > > > > > > > > Ripe's core is at least to provide **change management** over > > contact on allocation of internet resources (IP, AS) so that > > stakeholder's can cooperate, since internet protocols relies on swift > > cooperation between entities. Imagine a world in which you cannot > > reach a LIR or RIR having wrong BGP rules ? > > > > Furthermore, RIPE NCC is bound by its contract with ICANN in its > > mission of allocating resources. I think reading the actual contract > > might settle the topic pretty fast. > > > > Since I don't have the contract under my eyes right now, I will make a > > simple reasoning based on public informations and personnal > > experience. > > > > Let's stick to the common sense of database first : > > *Data accuracy is the most important property of a database.* Ripe NCC > > is entitled to manage the whois database, therefore it is in their > > mission to ensure DB integrity. > > > > If it is not convincing enough, let's remember data accuracy is > > considered by ICANN as a **MUST DO** for delegated entities (both for > > gTLD and resources). > > Just search ICANN web sites and you'll have extended papers explaining > > why accuracy matters, and how this responsability is also delegated. > > http://www.icann.org/en/gsearch/accuracy > > > > In a world without accurate whois contact it will be the the > > strongest's rule that shall prevail. > > > > What tickles me is how can RIPE NCC bill instances they don't have the > > **accurate** contacts ? Are there 2 DBs one for billing (with accurate > > data) and another one for public access with inaccurate data ? > > > > RIPE NCC cant choose the parts it likes in its delegated mission from > > ICANN. A contract is a contract and RIPE NCC is bound by its duties > > regarding ICANN. If ICANN states RIPE NCC MUST have accurates data, > > and MUST enforce internet policies I cannot see how RIPE NCC or RIPE > > can decide it is does not fall into their responsabilities. > > > > Now, all everybody needs to know : > > * what level of accuracy ICANN can realistcly expect from its delegates ? > > * what are the internet policies ICANN mentions ? > > > > Cheers. > > > > -- > > Jul > > Experienced freelance for years (having worked for ISP). > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 11 Apr 2012 16:08:11 +0200 > > From: Frank Gadegast > > Subject: Re: [anti-abuse-wg] current business practices > > To: "anti-abuse-wg at ripe.net" > > Message-ID: <4F85904B.8090203 at powerweb.de> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > V > > > > >> > > subpoena by deleting the wrong AS object from the database > > > > > >> ;o) > > > > > > > > > > > > Heh. ACK on the role. But I was thinking towards urging the ISP itself to take action (once you HAVE contacted them) on the abuse complaints. That's where the pressure of a lea agency can come in handy, if such a regulator is available. > > > > > > > > > > Well, the only possibility would be the police. > > They do care here in Germany are kind of > > technical disadvanced :o( > > > > There is some organizations this ISP is a member of > > (like the ECO), and they have also a abuse clearing > > board, but that one isnt really useful because > > it never did anything against their members ... > > > > And why should they do something, they are not > > responsible for the resources ... > > > > > > Kind regards, Frank > > > > > > > > Pepijn > > > > > > +++++++++++++++++++++++++++++++++++++++++++++ > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > -- > > > > Mit freundlichen Gruessen, > > -- > > MOTD: "have you enabled SSL on a website or mailbox today ?" > > -- > > 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 > > ====================================================================== > > > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 11 Apr 2012 14:49:13 +0200 > > From: Chris Heinze > > Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form > > To: anti-abuse-wg at ripe.net > > Message-ID: <4F857DC9.8060905 at consol.de> > > Content-Type: text/plain; charset=UTF-8 > > > > On 04/11/2012 02:13 PM, Brian Nisbet wrote: > > >> ripe's core is allocation. that's what they do. your mission is your private error. > > > > > > http://www.ripe.net/lir-services/ncc/functions > > > > right, that sums it up nicely, thanks. > > > > > Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. > > > > ripe's job isn't defined by and doesn't depend on whether or not v4 space is completely allocated (which it btw probably never will). > > keeping a good registry is as explained a service kindly provided by ripe to help - and it did that since the beginning. > > > > regards, > > > > Chris > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Wed, 11 Apr 2012 15:29:17 +0200 > > From: Gert Doering > > Subject: Re: [anti-abuse-wg] current business practices > > To: Suresh Ramasubramanian > > Cc: shane at time-travellers.org, Brian Nisbet , > > anti-abuse-wg at ripe.net, Tobias Knecht , "Michele Neylon > > :: Blacknight" , Laura Cobley , > > Florian Weimer , Frank Gadegast > > , Gert Doering > > Message-ID: <20120411132917.GN84425 at Space.Net> > > Content-Type: text/plain; charset="us-ascii" > > > > hi, > > > > On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: > > > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > > > wrote: > > > > will receives this could please make a > > > > telnet mamba.ripe.net 25 > > > > from some IPs he own (best would be not using his or her usual IP, > > > > if he or she likes, lets see how big that problem really > > > > is, thats why I have to mail the most active people directly). > > > > > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > > > Trying 2001:67c:2e8:11::c100:1328... > > > Trying 193.0.19.40... > > > telnet: Unable to connect to remote host: Connection refused > > > > > > Things seem to be RIPE for a change eh? > > > > So, what exactly causes the assumption that mamba is supposed to be > > reachable from the outside, on Port 25? > > > > $ host -t mx ripe.net > > ripe.net mail is handled by 250 postlady.ripe.net. > > ripe.net mail is handled by 200 postgirl.ripe.net. > > > > Now, obviously, expecting anti-spammers to understand about MX records > > and how to read Received: lines might be asking for a bit much... > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: not available > > Type: application/pgp-signature > > Size: 306 bytes > > Desc: not available > > Url : https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20120411/76082102/attachment-0001.bin > > > > ------------------------------ > > > > Message: 5 > > Date: Wed, 11 Apr 2012 13:32:48 +0000 > > From: "Michele Neylon :: Blacknight" > > Subject: Re: [anti-abuse-wg] current business practices > > To: Gert Doering , Suresh Ramasubramanian > > > > Cc: "shane at time-travellers.org" , Brian > > Nisbet , "anti-abuse-wg at ripe.net" > > , Tobias Knecht , Laura Cobley > > , Florian Weimer , Frank Gadegast > > > > Message-ID: > > <4F2538C315ACAC42AD334C533C247C47263EFF60 at bkexchmbx01.blacknight.local> > > > > Content-Type: text/plain; charset="us-ascii" > > > > So this list is now turned into an "experts" exchange on SMTP? > > > > *sigh* > > > > -- > > Mr Michele Neylon > > Blacknight Solutions > > Hosting & Colocation, Brand Protection > > http://www.blacknight.com/ > > http://blog.blacknight.com/ > > http://mneylon.tel/ > > Intl. +353 (0) 59 9183072 > > Locall: 1850 929 929 > > Direct Dial: +353 (0)59 9183090 > > Fax. +353 (0) 1 4811 763 > > Twitter: http://twitter.com/mneylon > > ------------------------------- > > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > > > ________________________________________ > > From: Gert Doering [gert at space.net] > > Sent: 11 April 2012 14:29 > > To: Suresh Ramasubramanian > > Cc: Frank Gadegast; Laura Cobley; Florian Weimer; anti-abuse-wg at ripe.net; Brian Nisbet; chrish at consol.net; shane at time-travellers.org; Michele Neylon :: Blacknight; Gert Doering; Tobias Knecht > > Subject: Re: [anti-abuse-wg] current business practices > > > > hi, > > > > On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: > > > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > > > wrote: > > > > will receives this could please make a > > > > telnet mamba.ripe.net 25 > > > > from some IPs he own (best would be not using his or her usual IP, > > > > if he or she likes, lets see how big that problem really > > > > is, thats why I have to mail the most active people directly). > > > > > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > > > Trying 2001:67c:2e8:11::c100:1328... > > > Trying 193.0.19.40... > > > telnet: Unable to connect to remote host: Connection refused > > > > > > Things seem to be RIPE for a change eh? > > > > So, what exactly causes the assumption that mamba is supposed to be > > reachable from the outside, on Port 25? > > > > $ host -t mx ripe.net > > ripe.net mail is handled by 250 postlady.ripe.net. > > ripe.net mail is handled by 200 postgirl.ripe.net. > > > > Now, obviously, expecting anti-spammers to understand about MX records > > and how to read Received: lines might be asking for a bit much... > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > > > > > > > ------------------------------ > > > > Message: 6 > > Date: Wed, 11 Apr 2012 18:50:02 +0530 > > From: Suresh Ramasubramanian > > Subject: Re: [anti-abuse-wg] current business practices > > To: Frank Gadegast > > Cc: shane at time-travellers.org, Brian Nisbet , > > anti-abuse-wg at ripe.net, Tobias Knecht , "Michele Neylon > > :: Blacknight" , Laura Cobley , > > Florian Weimer , Gert Doering > > Message-ID: > > > > Content-Type: text/plain; charset=UTF-8 > > > > On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast > > wrote: > > > will receives this could please make a > > > telnet mamba.ripe.net 25 > > > from some IPs he own (best would be not using his or her usual IP, > > > if he or she likes, lets see how big that problem really > > > is, thats why I have to mail the most active people directly). > > > > suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp > > Trying 2001:67c:2e8:11::c100:1328... > > Trying 193.0.19.40... > > telnet: Unable to connect to remote host: Connection refused > > > > Things seem to be RIPE for a change eh? > > > > -- > > Suresh Ramasubramanian (ops.lists at gmail.com) > > > > > > > > ------------------------------ > > > > Message: 7 > > Date: Wed, 11 Apr 2012 15:02:05 +0200 > > From: Frank Gadegast > > Subject: Re: [anti-abuse-wg] current business practices > > To: Laura Cobley > > Cc: shane at time-travellers.org, Brian Nisbet , > > anti-abuse-wg at ripe.net, Tobias Knecht , "Michele Neylon > > :: Blacknight" , Florian Weimer > > , ops.lists at gmail.com, Gert Doering > > Message-ID: <4F8580CD.4000502 at powerweb.de> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Laura Cobley wrote: > > > Dear Florian and all, > > > > Hi, > > > > (some details from our current experiences with RIPE NCC and accuracy > > of the RIPE objects) > > > > we currently have one case where a really big German cablenet ISP > > is having exacly one abuse-eMail address for their tech-c, abuse-mailbox > > and admin-c, for all their objects. > > > > And this one email has a domain, what does not belong to the ISP > > anymore, since November 2011, its currently owned by a domain grabber, > > because the ISP deleted the domain on purpose (on behalf of a > > change in the company name years ago). > > There is no other working contact information (phone lets you end up at > > their hotline where they have absolutly no idea about abuse), snail mail > > is no option, fax number is not supplied. > > > > We tried mailing there peering contact, their normal customer email > > from their website, filled their online feedback form and then > > opened a normal ticket at RIPE NCC, were just told > > to open another ticket at RIPE NCC and invested about 5 hours > > already describing the problem at RIPE NCC. > > Simply no chance, RIPE NCC is responding to tickets on a daily basis, > > even during business hours (jesus, we will respond in about 5 minutes > > if something serious like that will happen to our networks). > > The interest at the RIPE NCC to fix database problems does not seem > > to have any priority. > > > > Ah, I forgot: > > the maillist server mamba.ripe.net has technical problems during > > the last 3 weeks, we opened tickets for that as well and even > > got a response once, still not fixed, the maillist server > > is probably not reacheable for 90% of the members ... whoever > > will receives this could please make a > > telnet mamba.ripe.net 25 > > from some IPs he own (best would be not using his or her usual IP, > > if he or she likes, lets see how big that problem really > > is, thats why I have to mail the most active people directly). > > > > So: abuse does not have priority in a lot of peoples heads those days, > > even when they tell you that daily ... > > > > (we have about 100 abuse incidents with that ISP monthly and the ISP > > even resides in the same country than we are, but its still, if they > > reside on the other side of the moon, maybe I should demonstrate > > if front of the office building with a big sign saying: > > "you dont have a working abuse appartment") > > > > > > Kind regards, Frank > > > > > > Over time, contact information in the RIPE Database can become outdated > > > due to staffing changes, oversight and lack of knowledge on the part of > > > the maintainer. Bringing the irregularity directly to the attention of > > > this maintainer can be the quickest way to get it fixed. > > > > > > If you subsequently experience difficulties with this, we can help you > > > to get in touch with the maintainer by forwarding your report to the > > > person responsible for the Internet number resource registration. > > > Handling reports is a normal part of our operations within the RIPE NCC > > > and the report form makes it easier to get in touch with us. > > > > > > We ask you to include information such as mail delivery failure notices > > > and copies of emails with headers, which clearly show the problem and > > > the subsequent difficulties you are having. These help to substantiate > > > the report. Our aim is to work together with you to further improve the > > > quality of the data in the Internet number resource registry. > > > > > > Best regards, > > > > > > Laura Cobley > > > RIPE NCC > > > > > > On 4/6/12 8:45 PM, Florian Weimer wrote: > > >> * Laura Cobley: > > >> > > >>> Using this form, you can now easily report various issues, including > > >>> abnormalities in Internet number resource registrations, to us for > > >>> further investigation. > > >> > > >> I looked at "Incorrect contact information in the RIPE Database", and > > >> "I confirm that I have reported the incorrect information to all of > > >> the contacts listed in the relevant object" is a required checkbox. > > >> > > >> This seems to require that complainants try postal addresses, phone > > >> and fax numbers before reporting errors in email addresses. Is this > > >> really your goal? Isn't this a step backwards? > > >> > > > > > > > > > > > > > > > -- > > > > Mit freundlichen Gruessen, > > -- > > MOTD: "have you enabled SSL on a website or mailbox today ?" > > -- > > 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 > > ====================================================================== > > > > > > > > > > End of anti-abuse-wg Digest, Vol 8, Issue 9 > > ******************************************* 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 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 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 ripe-anti-spam-wg at powerweb.de Wed Apr 11 18:04:28 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 18:04:28 +0200 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 9 In-Reply-To: References: Message-ID: <4F85AB8C.7010400@powerweb.de> Michele Neylon :: Blacknight wrote: > >> >> 2. There is an abuse function for well ? abuse > > Where? the (not working) abuse finder tool ? the new "forms" at ripe ? > > > And here is where your logic breaks very badly Not SOO badly. If RIPE NCC finally will force the LIRs to have correct abuse contacts, it means that the LIR has to take care (well he inserted the objects himself or delegated access to them to his customer), its not interesting, if the customer provides correct details at all. The LIR has to provide them, there are only objects inherited from the LIR. And if he doesnt, well, punish the LIR ... Kind regards, Frank > > While all IP addresses are going to be assigned to LIRs a lot of the discussion is about IP objects and blocks - these are usually assigned to LIR's customers > > RIPE can contact the LIR > > The LIR can probably contact their customer > > The disjoint could be in the database > > BUT > > Assuming like you have that an entry in the database can only relate directly to a LIR is wrong. > > > >> member can be found, it is not so strange that, after a published notice with a due time frame, a relation is terminated. Certainly in a period of scarcity in IPv4 addresses, this should be common practice. (And if it happens to concern a criminal organisation, they won't show up any way. All others will within about 2 seconds of termination.) >> >> So if correct data is standard practice and law enforcement needs them for whatever reason, they can access this data either through Whois of through correct proceedings in the Dutch law. Like it should be. Correct data saves money in the end, for all concerned, and makes becoming a member less attractive for individuals or organisations that most of us agree don't need a place on the internet. I don't think LEAs ask for more than that, but as a RIPE member I would look at my own organisation first. LEAs need to deal with LIRs more than an RIR, I'd guess, so assist them in finding these LIRs. >> >> Wout >> >> >>> From: anti-abuse-wg-request at ripe.net >>> Subject: anti-abuse-wg Digest, Vol 8, Issue 9 >>> To: anti-abuse-wg at ripe.net >>> Date: Wed, 11 Apr 2012 16:13:31 +0200 >>> >>> 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. Re: Introducing the RIPE NCC Report Form (julien tayon) >>> 2. Re: current business practices (Frank Gadegast) >>> 3. Re: Introducing the RIPE NCC Report Form (Chris Heinze) >>> 4. Re: current business practices (Gert Doering) >>> 5. Re: current business practices (Michele Neylon :: Blacknight) >>> 6. Re: current business practices (Suresh Ramasubramanian) >>> 7. Re: current business practices (Frank Gadegast) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 11 Apr 2012 15:49:01 +0200 >>> From: julien tayon >>> Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form >>> To: Brian Nisbet >>> Cc: anti-abuse-wg at ripe.net >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> 2012/4/11 Brian Nisbet: >>>> Chris, >>>> >>>> "Chris" wrote the following on 11/04/2012 11:03: >>>>> >>>>> On 04/10/2012 05:18 PM, Joe St Sauver wrote: >>>>>> >>>>>> Maintenance of the database documenting who's been allocated/assigned >>>>>> space is *core* to RIPE's mission. >>>>> >>>>> >>>>> simply wrong. >>>>> ripe's core is allocation. that's what they do. your mission is your >>>>> private error. >>>> >>>> >>> Ripe's core is at least to provide **change management** over >>> contact on allocation of internet resources (IP, AS) so that >>> stakeholder's can cooperate, since internet protocols relies on swift >>> cooperation between entities. Imagine a world in which you cannot >>> reach a LIR or RIR having wrong BGP rules ? >>> >>> Furthermore, RIPE NCC is bound by its contract with ICANN in its >>> mission of allocating resources. I think reading the actual contract >>> might settle the topic pretty fast. >>> >>> Since I don't have the contract under my eyes right now, I will make a >>> simple reasoning based on public informations and personnal >>> experience. >>> >>> Let's stick to the common sense of database first : >>> *Data accuracy is the most important property of a database.* Ripe NCC >>> is entitled to manage the whois database, therefore it is in their >>> mission to ensure DB integrity. >>> >>> If it is not convincing enough, let's remember data accuracy is >>> considered by ICANN as a **MUST DO** for delegated entities (both for >>> gTLD and resources). >>> Just search ICANN web sites and you'll have extended papers explaining >>> why accuracy matters, and how this responsability is also delegated. >>> http://www.icann.org/en/gsearch/accuracy >>> >>> In a world without accurate whois contact it will be the the >>> strongest's rule that shall prevail. >>> >>> What tickles me is how can RIPE NCC bill instances they don't have the >>> **accurate** contacts ? Are there 2 DBs one for billing (with accurate >>> data) and another one for public access with inaccurate data ? >>> >>> RIPE NCC cant choose the parts it likes in its delegated mission from >>> ICANN. A contract is a contract and RIPE NCC is bound by its duties >>> regarding ICANN. If ICANN states RIPE NCC MUST have accurates data, >>> and MUST enforce internet policies I cannot see how RIPE NCC or RIPE >>> can decide it is does not fall into their responsabilities. >>> >>> Now, all everybody needs to know : >>> * what level of accuracy ICANN can realistcly expect from its delegates ? >>> * what are the internet policies ICANN mentions ? >>> >>> Cheers. >>> >>> -- >>> Jul >>> Experienced freelance for years (having worked for ISP). >>> >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Wed, 11 Apr 2012 16:08:11 +0200 >>> From: Frank Gadegast >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: "anti-abuse-wg at ripe.net" >>> Message-ID:<4F85904B.8090203 at powerweb.de> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> V >>> >>>>> >>> subpoena by deleting the wrong AS object from the database >>>> >>>>> ;o) >>>> >>>> >>>> >>>> Heh. ACK on the role. But I was thinking towards urging the ISP itself to take action (once you HAVE contacted them) on the abuse complaints. That's where the pressure of a lea agency can come in handy, if such a regulator is available. >>>> >>>> >>> >>> Well, the only possibility would be the police. >>> They do care here in Germany are kind of >>> technical disadvanced :o( >>> >>> There is some organizations this ISP is a member of >>> (like the ECO), and they have also a abuse clearing >>> board, but that one isnt really useful because >>> it never did anything against their members ... >>> >>> And why should they do something, they are not >>> responsible for the resources ... >>> >>> >>> Kind regards, Frank >>> >>>> >>>> Pepijn >>>> >>>> +++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Mit freundlichen Gruessen, >>> -- >>> MOTD: "have you enabled SSL on a website or mailbox today ?" >>> -- >>> 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 >>> ====================================================================== >>> >>> >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Wed, 11 Apr 2012 14:49:13 +0200 >>> From: Chris Heinze >>> Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form >>> To: anti-abuse-wg at ripe.net >>> Message-ID:<4F857DC9.8060905 at consol.de> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> On 04/11/2012 02:13 PM, Brian Nisbet wrote: >>>>> ripe's core is allocation. that's what they do. your mission is your private error. >>>> >>>> http://www.ripe.net/lir-services/ncc/functions >>> >>> right, that sums it up nicely, thanks. >>> >>>> Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. >>> >>> ripe's job isn't defined by and doesn't depend on whether or not v4 space is completely allocated (which it btw probably never will). >>> keeping a good registry is as explained a service kindly provided by ripe to help - and it did that since the beginning. >>> >>> regards, >>> >>> Chris >>> >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Wed, 11 Apr 2012 15:29:17 +0200 >>> From: Gert Doering >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Suresh Ramasubramanian >>> Cc: shane at time-travellers.org, Brian Nisbet, >>> anti-abuse-wg at ripe.net, Tobias Knecht, "Michele Neylon >>> :: Blacknight", Laura Cobley, >>> Florian Weimer, Frank Gadegast >>> , Gert Doering >>> Message-ID:<20120411132917.GN84425 at Space.Net> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> hi, >>> >>> On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: >>>> On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast >>>> wrote: >>>>> will receives this could please make a >>>>> telnet mamba.ripe.net 25 >>>>> from some IPs he own (best would be not using his or her usual IP, >>>>> if he or she likes, lets see how big that problem really >>>>> is, thats why I have to mail the most active people directly). >>>> >>>> suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp >>>> Trying 2001:67c:2e8:11::c100:1328... >>>> Trying 193.0.19.40... >>>> telnet: Unable to connect to remote host: Connection refused >>>> >>>> Things seem to be RIPE for a change eh? >>> >>> So, what exactly causes the assumption that mamba is supposed to be >>> reachable from the outside, on Port 25? >>> >>> $ host -t mx ripe.net >>> ripe.net mail is handled by 250 postlady.ripe.net. >>> ripe.net mail is handled by 200 postgirl.ripe.net. >>> >>> Now, obviously, expecting anti-spammers to understand about MX records >>> and how to read Received: lines might be asking for a bit much... >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >>> -------------- next part -------------- >>> A non-text attachment was scrubbed... >>> Name: not available >>> Type: application/pgp-signature >>> Size: 306 bytes >>> Desc: not available >>> Url : https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20120411/76082102/attachment-0001.bin >>> >>> ------------------------------ >>> >>> Message: 5 >>> Date: Wed, 11 Apr 2012 13:32:48 +0000 >>> From: "Michele Neylon :: Blacknight" >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Gert Doering, Suresh Ramasubramanian >>> >>> Cc: "shane at time-travellers.org", Brian >>> Nisbet, "anti-abuse-wg at ripe.net" >>> , Tobias Knecht, Laura Cobley >>> , Florian Weimer, Frank Gadegast >>> >>> Message-ID: >>> <4F2538C315ACAC42AD334C533C247C47263EFF60 at bkexchmbx01.blacknight.local> >>> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> So this list is now turned into an "experts" exchange on SMTP? >>> >>> *sigh* >>> >>> -- >>> Mr Michele Neylon >>> Blacknight Solutions >>> Hosting& Colocation, Brand Protection >>> http://www.blacknight.com/ >>> http://blog.blacknight.com/ >>> http://mneylon.tel/ >>> Intl. +353 (0) 59 9183072 >>> Locall: 1850 929 929 >>> Direct Dial: +353 (0)59 9183090 >>> Fax. +353 (0) 1 4811 763 >>> Twitter: http://twitter.com/mneylon >>> ------------------------------- >>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty >>> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >>> >>> ________________________________________ >>> From: Gert Doering [gert at space.net] >>> Sent: 11 April 2012 14:29 >>> To: Suresh Ramasubramanian >>> Cc: Frank Gadegast; Laura Cobley; Florian Weimer; anti-abuse-wg at ripe.net; Brian Nisbet; chrish at consol.net; shane at time-travellers.org; Michele Neylon :: Blacknight; Gert Doering; Tobias Knecht >>> Subject: Re: [anti-abuse-wg] current business practices >>> >>> hi, >>> >>> On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: >>>> On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast >>>> wrote: >>>>> will receives this could please make a >>>>> telnet mamba.ripe.net 25 >>>>> from some IPs he own (best would be not using his or her usual IP, >>>>> if he or she likes, lets see how big that problem really >>>>> is, thats why I have to mail the most active people directly). >>>> >>>> suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp >>>> Trying 2001:67c:2e8:11::c100:1328... >>>> Trying 193.0.19.40... >>>> telnet: Unable to connect to remote host: Connection refused >>>> >>>> Things seem to be RIPE for a change eh? >>> >>> So, what exactly causes the assumption that mamba is supposed to be >>> reachable from the outside, on Port 25? >>> >>> $ host -t mx ripe.net >>> ripe.net mail is handled by 250 postlady.ripe.net. >>> ripe.net mail is handled by 200 postgirl.ripe.net. >>> >>> Now, obviously, expecting anti-spammers to understand about MX records >>> and how to read Received: lines might be asking for a bit much... >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >>> >>> >>> >>> ------------------------------ >>> >>> Message: 6 >>> Date: Wed, 11 Apr 2012 18:50:02 +0530 >>> From: Suresh Ramasubramanian >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Frank Gadegast >>> Cc: shane at time-travellers.org, Brian Nisbet, >>> anti-abuse-wg at ripe.net, Tobias Knecht, "Michele Neylon >>> :: Blacknight", Laura Cobley, >>> Florian Weimer, Gert Doering >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast >>> wrote: >>>> will receives this could please make a >>>> telnet mamba.ripe.net 25 >>>> from some IPs he own (best would be not using his or her usual IP, >>>> if he or she likes, lets see how big that problem really >>>> is, thats why I have to mail the most active people directly). >>> >>> suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp >>> Trying 2001:67c:2e8:11::c100:1328... >>> Trying 193.0.19.40... >>> telnet: Unable to connect to remote host: Connection refused >>> >>> Things seem to be RIPE for a change eh? >>> >>> -- >>> Suresh Ramasubramanian (ops.lists at gmail.com) >>> >>> >>> >>> ------------------------------ >>> >>> Message: 7 >>> Date: Wed, 11 Apr 2012 15:02:05 +0200 >>> From: Frank Gadegast >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Laura Cobley >>> Cc: shane at time-travellers.org, Brian Nisbet, >>> anti-abuse-wg at ripe.net, Tobias Knecht, "Michele Neylon >>> :: Blacknight", Florian Weimer >>> , ops.lists at gmail.com, Gert Doering >>> Message-ID:<4F8580CD.4000502 at powerweb.de> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> Laura Cobley wrote: >>>> Dear Florian and all, >>> >>> Hi, >>> >>> (some details from our current experiences with RIPE NCC and accuracy >>> of the RIPE objects) >>> >>> we currently have one case where a really big German cablenet ISP >>> is having exacly one abuse-eMail address for their tech-c, abuse-mailbox >>> and admin-c, for all their objects. >>> >>> And this one email has a domain, what does not belong to the ISP >>> anymore, since November 2011, its currently owned by a domain grabber, >>> because the ISP deleted the domain on purpose (on behalf of a >>> change in the company name years ago). >>> There is no other working contact information (phone lets you end up at >>> their hotline where they have absolutly no idea about abuse), snail mail >>> is no option, fax number is not supplied. >>> >>> We tried mailing there peering contact, their normal customer email >>> from their website, filled their online feedback form and then >>> opened a normal ticket at RIPE NCC, were just told >>> to open another ticket at RIPE NCC and invested about 5 hours >>> already describing the problem at RIPE NCC. >>> Simply no chance, RIPE NCC is responding to tickets on a daily basis, >>> even during business hours (jesus, we will respond in about 5 minutes >>> if something serious like that will happen to our networks). >>> The interest at the RIPE NCC to fix database problems does not seem >>> to have any priority. >>> >>> Ah, I forgot: >>> the maillist server mamba.ripe.net has technical problems during >>> the last 3 weeks, we opened tickets for that as well and even >>> got a response once, still not fixed, the maillist server >>> is probably not reacheable for 90% of the members ... whoever >>> will receives this could please make a >>> telnet mamba.ripe.net 25 >>> from some IPs he own (best would be not using his or her usual IP, >>> if he or she likes, lets see how big that problem really >>> is, thats why I have to mail the most active people directly). >>> >>> So: abuse does not have priority in a lot of peoples heads those days, >>> even when they tell you that daily ... >>> >>> (we have about 100 abuse incidents with that ISP monthly and the ISP >>> even resides in the same country than we are, but its still, if they >>> reside on the other side of the moon, maybe I should demonstrate >>> if front of the office building with a big sign saying: >>> "you dont have a working abuse appartment") >>> >>> >>> Kind regards, Frank >>>> >>>> Over time, contact information in the RIPE Database can become outdated >>>> due to staffing changes, oversight and lack of knowledge on the part of >>>> the maintainer. Bringing the irregularity directly to the attention of >>>> this maintainer can be the quickest way to get it fixed. >>>> >>>> If you subsequently experience difficulties with this, we can help you >>>> to get in touch with the maintainer by forwarding your report to the >>>> person responsible for the Internet number resource registration. >>>> Handling reports is a normal part of our operations within the RIPE NCC >>>> and the report form makes it easier to get in touch with us. >>>> >>>> We ask you to include information such as mail delivery failure notices >>>> and copies of emails with headers, which clearly show the problem and >>>> the subsequent difficulties you are having. These help to substantiate >>>> the report. Our aim is to work together with you to further improve the >>>> quality of the data in the Internet number resource registry. >>>> >>>> Best regards, >>>> >>>> Laura Cobley >>>> RIPE NCC >>>> >>>> On 4/6/12 8:45 PM, Florian Weimer wrote: >>>>> * Laura Cobley: >>>>> >>>>>> Using this form, you can now easily report various issues, including >>>>>> abnormalities in Internet number resource registrations, to us for >>>>>> further investigation. >>>>> >>>>> I looked at "Incorrect contact information in the RIPE Database", and >>>>> "I confirm that I have reported the incorrect information to all of >>>>> the contacts listed in the relevant object" is a required checkbox. >>>>> >>>>> This seems to require that complainants try postal addresses, phone >>>>> and fax numbers before reporting errors in email addresses. Is this >>>>> really your goal? Isn't this a step backwards? >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Mit freundlichen Gruessen, >>> -- >>> MOTD: "have you enabled SSL on a website or mailbox today ?" >>> -- >>> 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 >>> ====================================================================== >>> >>> >>> >>> >>> End of anti-abuse-wg Digest, Vol 8, Issue 9 >>> ******************************************* > > 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 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > 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 > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From ops.lists at gmail.com Wed Apr 11 18:07:52 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Apr 2012 21:37:52 +0530 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 9 In-Reply-To: <4F85AB8C.7010400@powerweb.de> References: <4F85AB8C.7010400@powerweb.de> Message-ID: icann does use this measure against registrars, not too infrequently --srs (iPad) On 11-Apr-2012, at 21:34, Frank Gadegast wrote: > If RIPE NCC finally will force the LIRs to have correct abuse > contacts, it means that the LIR has to take care (well he inserted > the objects himself or delegated access to them to his customer), > its not interesting, if the customer provides correct details at all. > The LIR has to provide them, there are only objects inherited from > the LIR. > > And if he doesnt, well, punish the LIR ... From frank at powerweb.de Wed Apr 11 18:02:34 2012 From: frank at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 18:02:34 +0200 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 9 In-Reply-To: References: Message-ID: <4F85AB1A.60906@powerweb.de> Michele Neylon :: Blacknight wrote: > >> >> 2. There is an abuse function for well ? abuse > > Where? the (not working) abuse finder tool ? the new "forms" at ripe ? > > > And here is where your logic breaks very badly Not SOO badly. If RIPE NCC finally will force the LIRs to have correct abuse contacts, it means that the LIR has to take care (well he inserted the objects himself or delegated access to them to his customer), its not interesting, if the customer provides correct details at all. The LIR has to provide them. And if he doesnt, well, punish him ... Kind regards, Frank > > While all IP addresses are going to be assigned to LIRs a lot of the discussion is about IP objects and blocks - these are usually assigned to LIR's customers > > RIPE can contact the LIR > > The LIR can probably contact their customer > > The disjoint could be in the database > > BUT > > Assuming like you have that an entry in the database can only relate directly to a LIR is wrong. > > > >> member can be found, it is not so strange that, after a published notice with a due time frame, a relation is terminated. Certainly in a period of scarcity in IPv4 addresses, this should be common practice. (And if it happens to concern a criminal organisation, they won't show up any way. All others will within about 2 seconds of termination.) >> >> So if correct data is standard practice and law enforcement needs them for whatever reason, they can access this data either through Whois of through correct proceedings in the Dutch law. Like it should be. Correct data saves money in the end, for all concerned, and makes becoming a member less attractive for individuals or organisations that most of us agree don't need a place on the internet. I don't think LEAs ask for more than that, but as a RIPE member I would look at my own organisation first. LEAs need to deal with LIRs more than an RIR, I'd guess, so assist them in finding these LIRs. >> >> Wout >> >> >>> From: anti-abuse-wg-request at ripe.net >>> Subject: anti-abuse-wg Digest, Vol 8, Issue 9 >>> To: anti-abuse-wg at ripe.net >>> Date: Wed, 11 Apr 2012 16:13:31 +0200 >>> >>> 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. Re: Introducing the RIPE NCC Report Form (julien tayon) >>> 2. Re: current business practices (Frank Gadegast) >>> 3. Re: Introducing the RIPE NCC Report Form (Chris Heinze) >>> 4. Re: current business practices (Gert Doering) >>> 5. Re: current business practices (Michele Neylon :: Blacknight) >>> 6. Re: current business practices (Suresh Ramasubramanian) >>> 7. Re: current business practices (Frank Gadegast) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 11 Apr 2012 15:49:01 +0200 >>> From: julien tayon >>> Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form >>> To: Brian Nisbet >>> Cc: anti-abuse-wg at ripe.net >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> 2012/4/11 Brian Nisbet: >>>> Chris, >>>> >>>> "Chris" wrote the following on 11/04/2012 11:03: >>>>> >>>>> On 04/10/2012 05:18 PM, Joe St Sauver wrote: >>>>>> >>>>>> Maintenance of the database documenting who's been allocated/assigned >>>>>> space is *core* to RIPE's mission. >>>>> >>>>> >>>>> simply wrong. >>>>> ripe's core is allocation. that's what they do. your mission is your >>>>> private error. >>>> >>>> >>> Ripe's core is at least to provide **change management** over >>> contact on allocation of internet resources (IP, AS) so that >>> stakeholder's can cooperate, since internet protocols relies on swift >>> cooperation between entities. Imagine a world in which you cannot >>> reach a LIR or RIR having wrong BGP rules ? >>> >>> Furthermore, RIPE NCC is bound by its contract with ICANN in its >>> mission of allocating resources. I think reading the actual contract >>> might settle the topic pretty fast. >>> >>> Since I don't have the contract under my eyes right now, I will make a >>> simple reasoning based on public informations and personnal >>> experience. >>> >>> Let's stick to the common sense of database first : >>> *Data accuracy is the most important property of a database.* Ripe NCC >>> is entitled to manage the whois database, therefore it is in their >>> mission to ensure DB integrity. >>> >>> If it is not convincing enough, let's remember data accuracy is >>> considered by ICANN as a **MUST DO** for delegated entities (both for >>> gTLD and resources). >>> Just search ICANN web sites and you'll have extended papers explaining >>> why accuracy matters, and how this responsability is also delegated. >>> http://www.icann.org/en/gsearch/accuracy >>> >>> In a world without accurate whois contact it will be the the >>> strongest's rule that shall prevail. >>> >>> What tickles me is how can RIPE NCC bill instances they don't have the >>> **accurate** contacts ? Are there 2 DBs one for billing (with accurate >>> data) and another one for public access with inaccurate data ? >>> >>> RIPE NCC cant choose the parts it likes in its delegated mission from >>> ICANN. A contract is a contract and RIPE NCC is bound by its duties >>> regarding ICANN. If ICANN states RIPE NCC MUST have accurates data, >>> and MUST enforce internet policies I cannot see how RIPE NCC or RIPE >>> can decide it is does not fall into their responsabilities. >>> >>> Now, all everybody needs to know : >>> * what level of accuracy ICANN can realistcly expect from its delegates ? >>> * what are the internet policies ICANN mentions ? >>> >>> Cheers. >>> >>> -- >>> Jul >>> Experienced freelance for years (having worked for ISP). >>> >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Wed, 11 Apr 2012 16:08:11 +0200 >>> From: Frank Gadegast >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: "anti-abuse-wg at ripe.net" >>> Message-ID:<4F85904B.8090203 at powerweb.de> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> V >>> >>>>> >>> subpoena by deleting the wrong AS object from the database >>>> >>>>> ;o) >>>> >>>> >>>> >>>> Heh. ACK on the role. But I was thinking towards urging the ISP itself to take action (once you HAVE contacted them) on the abuse complaints. That's where the pressure of a lea agency can come in handy, if such a regulator is available. >>>> >>>> >>> >>> Well, the only possibility would be the police. >>> They do care here in Germany are kind of >>> technical disadvanced :o( >>> >>> There is some organizations this ISP is a member of >>> (like the ECO), and they have also a abuse clearing >>> board, but that one isnt really useful because >>> it never did anything against their members ... >>> >>> And why should they do something, they are not >>> responsible for the resources ... >>> >>> >>> Kind regards, Frank >>> >>>> >>>> Pepijn >>>> >>>> +++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Mit freundlichen Gruessen, >>> -- >>> MOTD: "have you enabled SSL on a website or mailbox today ?" >>> -- >>> 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 >>> ====================================================================== >>> >>> >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Wed, 11 Apr 2012 14:49:13 +0200 >>> From: Chris Heinze >>> Subject: Re: [anti-abuse-wg] Introducing the RIPE NCC Report Form >>> To: anti-abuse-wg at ripe.net >>> Message-ID:<4F857DC9.8060905 at consol.de> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> On 04/11/2012 02:13 PM, Brian Nisbet wrote: >>>>> ripe's core is allocation. that's what they do. your mission is your private error. >>>> >>>> http://www.ripe.net/lir-services/ncc/functions >>> >>> right, that sums it up nicely, thanks. >>> >>>> Once all of v4 space is allocated (soon now, soon), the primary job of the NCC and the other four RIRs will be keeping a good registry. >>> >>> ripe's job isn't defined by and doesn't depend on whether or not v4 space is completely allocated (which it btw probably never will). >>> keeping a good registry is as explained a service kindly provided by ripe to help - and it did that since the beginning. >>> >>> regards, >>> >>> Chris >>> >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Wed, 11 Apr 2012 15:29:17 +0200 >>> From: Gert Doering >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Suresh Ramasubramanian >>> Cc: shane at time-travellers.org, Brian Nisbet, >>> anti-abuse-wg at ripe.net, Tobias Knecht, "Michele Neylon >>> :: Blacknight", Laura Cobley, >>> Florian Weimer, Frank Gadegast >>> , Gert Doering >>> Message-ID:<20120411132917.GN84425 at Space.Net> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> hi, >>> >>> On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: >>>> On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast >>>> wrote: >>>>> will receives this could please make a >>>>> telnet mamba.ripe.net 25 >>>>> from some IPs he own (best would be not using his or her usual IP, >>>>> if he or she likes, lets see how big that problem really >>>>> is, thats why I have to mail the most active people directly). >>>> >>>> suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp >>>> Trying 2001:67c:2e8:11::c100:1328... >>>> Trying 193.0.19.40... >>>> telnet: Unable to connect to remote host: Connection refused >>>> >>>> Things seem to be RIPE for a change eh? >>> >>> So, what exactly causes the assumption that mamba is supposed to be >>> reachable from the outside, on Port 25? >>> >>> $ host -t mx ripe.net >>> ripe.net mail is handled by 250 postlady.ripe.net. >>> ripe.net mail is handled by 200 postgirl.ripe.net. >>> >>> Now, obviously, expecting anti-spammers to understand about MX records >>> and how to read Received: lines might be asking for a bit much... >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >>> -------------- next part -------------- >>> A non-text attachment was scrubbed... >>> Name: not available >>> Type: application/pgp-signature >>> Size: 306 bytes >>> Desc: not available >>> Url : https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20120411/76082102/attachment-0001.bin >>> >>> ------------------------------ >>> >>> Message: 5 >>> Date: Wed, 11 Apr 2012 13:32:48 +0000 >>> From: "Michele Neylon :: Blacknight" >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Gert Doering, Suresh Ramasubramanian >>> >>> Cc: "shane at time-travellers.org", Brian >>> Nisbet, "anti-abuse-wg at ripe.net" >>> , Tobias Knecht, Laura Cobley >>> , Florian Weimer, Frank Gadegast >>> >>> Message-ID: >>> <4F2538C315ACAC42AD334C533C247C47263EFF60 at bkexchmbx01.blacknight.local> >>> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> So this list is now turned into an "experts" exchange on SMTP? >>> >>> *sigh* >>> >>> -- >>> Mr Michele Neylon >>> Blacknight Solutions >>> Hosting& Colocation, Brand Protection >>> http://www.blacknight.com/ >>> http://blog.blacknight.com/ >>> http://mneylon.tel/ >>> Intl. +353 (0) 59 9183072 >>> Locall: 1850 929 929 >>> Direct Dial: +353 (0)59 9183090 >>> Fax. +353 (0) 1 4811 763 >>> Twitter: http://twitter.com/mneylon >>> ------------------------------- >>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty >>> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >>> >>> ________________________________________ >>> From: Gert Doering [gert at space.net] >>> Sent: 11 April 2012 14:29 >>> To: Suresh Ramasubramanian >>> Cc: Frank Gadegast; Laura Cobley; Florian Weimer; anti-abuse-wg at ripe.net; Brian Nisbet; chrish at consol.net; shane at time-travellers.org; Michele Neylon :: Blacknight; Gert Doering; Tobias Knecht >>> Subject: Re: [anti-abuse-wg] current business practices >>> >>> hi, >>> >>> On Wed, Apr 11, 2012 at 06:50:02PM +0530, Suresh Ramasubramanian wrote: >>>> On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast >>>> wrote: >>>>> will receives this could please make a >>>>> telnet mamba.ripe.net 25 >>>>> from some IPs he own (best would be not using his or her usual IP, >>>>> if he or she likes, lets see how big that problem really >>>>> is, thats why I have to mail the most active people directly). >>>> >>>> suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp >>>> Trying 2001:67c:2e8:11::c100:1328... >>>> Trying 193.0.19.40... >>>> telnet: Unable to connect to remote host: Connection refused >>>> >>>> Things seem to be RIPE for a change eh? >>> >>> So, what exactly causes the assumption that mamba is supposed to be >>> reachable from the outside, on Port 25? >>> >>> $ host -t mx ripe.net >>> ripe.net mail is handled by 250 postlady.ripe.net. >>> ripe.net mail is handled by 200 postgirl.ripe.net. >>> >>> Now, obviously, expecting anti-spammers to understand about MX records >>> and how to read Received: lines might be asking for a bit much... >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >>> >>> >>> >>> ------------------------------ >>> >>> Message: 6 >>> Date: Wed, 11 Apr 2012 18:50:02 +0530 >>> From: Suresh Ramasubramanian >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Frank Gadegast >>> Cc: shane at time-travellers.org, Brian Nisbet, >>> anti-abuse-wg at ripe.net, Tobias Knecht, "Michele Neylon >>> :: Blacknight", Laura Cobley, >>> Florian Weimer, Gert Doering >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> On Wed, Apr 11, 2012 at 6:32 PM, Frank Gadegast >>> wrote: >>>> will receives this could please make a >>>> telnet mamba.ripe.net 25 >>>> from some IPs he own (best would be not using his or her usual IP, >>>> if he or she likes, lets see how big that problem really >>>> is, thats why I have to mail the most active people directly). >>> >>> suresh at frodo 03:54:25 :~$ telnet mamba.ripe.net smtp >>> Trying 2001:67c:2e8:11::c100:1328... >>> Trying 193.0.19.40... >>> telnet: Unable to connect to remote host: Connection refused >>> >>> Things seem to be RIPE for a change eh? >>> >>> -- >>> Suresh Ramasubramanian (ops.lists at gmail.com) >>> >>> >>> >>> ------------------------------ >>> >>> Message: 7 >>> Date: Wed, 11 Apr 2012 15:02:05 +0200 >>> From: Frank Gadegast >>> Subject: Re: [anti-abuse-wg] current business practices >>> To: Laura Cobley >>> Cc: shane at time-travellers.org, Brian Nisbet, >>> anti-abuse-wg at ripe.net, Tobias Knecht, "Michele Neylon >>> :: Blacknight", Florian Weimer >>> , ops.lists at gmail.com, Gert Doering >>> Message-ID:<4F8580CD.4000502 at powerweb.de> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> Laura Cobley wrote: >>>> Dear Florian and all, >>> >>> Hi, >>> >>> (some details from our current experiences with RIPE NCC and accuracy >>> of the RIPE objects) >>> >>> we currently have one case where a really big German cablenet ISP >>> is having exacly one abuse-eMail address for their tech-c, abuse-mailbox >>> and admin-c, for all their objects. >>> >>> And this one email has a domain, what does not belong to the ISP >>> anymore, since November 2011, its currently owned by a domain grabber, >>> because the ISP deleted the domain on purpose (on behalf of a >>> change in the company name years ago). >>> There is no other working contact information (phone lets you end up at >>> their hotline where they have absolutly no idea about abuse), snail mail >>> is no option, fax number is not supplied. >>> >>> We tried mailing there peering contact, their normal customer email >>> from their website, filled their online feedback form and then >>> opened a normal ticket at RIPE NCC, were just told >>> to open another ticket at RIPE NCC and invested about 5 hours >>> already describing the problem at RIPE NCC. >>> Simply no chance, RIPE NCC is responding to tickets on a daily basis, >>> even during business hours (jesus, we will respond in about 5 minutes >>> if something serious like that will happen to our networks). >>> The interest at the RIPE NCC to fix database problems does not seem >>> to have any priority. >>> >>> Ah, I forgot: >>> the maillist server mamba.ripe.net has technical problems during >>> the last 3 weeks, we opened tickets for that as well and even >>> got a response once, still not fixed, the maillist server >>> is probably not reacheable for 90% of the members ... whoever >>> will receives this could please make a >>> telnet mamba.ripe.net 25 >>> from some IPs he own (best would be not using his or her usual IP, >>> if he or she likes, lets see how big that problem really >>> is, thats why I have to mail the most active people directly). >>> >>> So: abuse does not have priority in a lot of peoples heads those days, >>> even when they tell you that daily ... >>> >>> (we have about 100 abuse incidents with that ISP monthly and the ISP >>> even resides in the same country than we are, but its still, if they >>> reside on the other side of the moon, maybe I should demonstrate >>> if front of the office building with a big sign saying: >>> "you dont have a working abuse appartment") >>> >>> >>> Kind regards, Frank >>>> >>>> Over time, contact information in the RIPE Database can become outdated >>>> due to staffing changes, oversight and lack of knowledge on the part of >>>> the maintainer. Bringing the irregularity directly to the attention of >>>> this maintainer can be the quickest way to get it fixed. >>>> >>>> If you subsequently experience difficulties with this, we can help you >>>> to get in touch with the maintainer by forwarding your report to the >>>> person responsible for the Internet number resource registration. >>>> Handling reports is a normal part of our operations within the RIPE NCC >>>> and the report form makes it easier to get in touch with us. >>>> >>>> We ask you to include information such as mail delivery failure notices >>>> and copies of emails with headers, which clearly show the problem and >>>> the subsequent difficulties you are having. These help to substantiate >>>> the report. Our aim is to work together with you to further improve the >>>> quality of the data in the Internet number resource registry. >>>> >>>> Best regards, >>>> >>>> Laura Cobley >>>> RIPE NCC >>>> >>>> On 4/6/12 8:45 PM, Florian Weimer wrote: >>>>> * Laura Cobley: >>>>> >>>>>> Using this form, you can now easily report various issues, including >>>>>> abnormalities in Internet number resource registrations, to us for >>>>>> further investigation. >>>>> >>>>> I looked at "Incorrect contact information in the RIPE Database", and >>>>> "I confirm that I have reported the incorrect information to all of >>>>> the contacts listed in the relevant object" is a required checkbox. >>>>> >>>>> This seems to require that complainants try postal addresses, phone >>>>> and fax numbers before reporting errors in email addresses. Is this >>>>> really your goal? Isn't this a step backwards? >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Mit freundlichen Gruessen, >>> -- >>> MOTD: "have you enabled SSL on a website or mailbox today ?" >>> -- >>> 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 >>> ====================================================================== >>> >>> >>> >>> >>> End of anti-abuse-wg Digest, Vol 8, Issue 9 >>> ******************************************* > > 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 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > 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 > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From ripe-anti-spam-wg at powerweb.de Wed Apr 11 18:12:48 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 18:12:48 +0200 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 9 In-Reply-To: References: <4F85AB8C.7010400@powerweb.de> Message-ID: <4F85AD80.1070404@powerweb.de> Suresh Ramasubramanian wrote: > icann does use this measure against registrars, not too infrequently and most domain registry also do ... I would say, its common sense to validate email addresses in the database of internet resources. RIPE NCC is not doing this Is there somebody from the other RIRs on this list ? Are other RIRs validating the abuse email addresses ? Kind regards, Frank > > --srs (iPad) > > On 11-Apr-2012, at 21:34, Frank Gadegast wrote: > >> If RIPE NCC finally will force the LIRs to have correct abuse >> contacts, it means that the LIR has to take care (well he inserted >> the objects himself or delegated access to them to his customer), >> its not interesting, if the customer provides correct details at all. >> The LIR has to provide them, there are only objects inherited from >> the LIR. >> >> And if he doesnt, well, punish the LIR ... > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From chrish at consol.net Wed Apr 11 18:27:14 2012 From: chrish at consol.net (Chris) Date: Wed, 11 Apr 2012 18:27:14 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> Message-ID: <4F85B0E2.1070408@consol.net> time to aggregate: "ripe's core task is to provide the db in the form *i* want it" obviously not true. ripe's core task is number resource coordination, the db is a service, if ripe decided not to provide for it - then there simply wouldn't be one. "icann says $foobar" go talk with icann about that. "$foo cannot be reached. we phoned them up, but they didn't react to our inquiries the way we wanted them to. we didn't want to send them postal mail. they didn't publish an email in whois, but we mailed them anyway, but they didn't answer the way we wanted them to. we want ripe to take their resources away because we say so, and because of this example, we want everybody to be forced to publish a spamable email address that works [by which probably a heap of further madness is implied]" i think this summary is already formulated in a way so my points are clear... another thing: if $a has about 100 issues per month with $b, and they even are in the same country and jurisdiction - sorry, but the picture painted is something like: $a nags $b (big time - i mean, a hundred issues per month...) because $a wants something from $b, but $b obviously seems to have a different view on the issue, and obviously the law is on $b's side (that ther's no lea in said jurisdiction is ofc a very blatant lie), and therefore $a wants ripe to take "somebody's" resources away in case they don't comply to rules $a wants to put up (and which don't make rational sense). i'd call _that_ abuse... if "ugly" db statistics are the issue, the working and straightforward solution would be a refer attribute in inet*num objects. with the ripe's allocation objects remaining, the quality of the ripe whois db would probably be very good. regards, Chris From ripe-anti-spam-wg at powerweb.de Wed Apr 11 18:43:29 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 11 Apr 2012 18:43:29 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F85B0E2.1070408@consol.net> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F85B0E2.1070408@consol.net> Message-ID: <4F85B4B1.5080103@powerweb.de> Chris wrote: > > "ripe's core task is to provide the db in the form *i* want it" > > obviously not true. ripe's core task is number resource coordination, the db is a service, if ripe decided not to provide for it - then there simply wouldn't be one. > Sorry, but the above statement IS true indeed. Chris: you are mixing RIPE and RIPE NCC. The community has a real interest in an up-to-date and working whois db, e.g. we all can see on this list. And RIPE NCC has to fullfill this interest. Its only on us to define how far RIPE NCC should go. And if the data in the whois db is not correct enough for us, we need to tell the NCC how to improve this. I would recommend an RFC about validation methods, RIPE NCC should implement after Tobias new abuse-c is in place. Kind regards, Frank > "icann says $foobar" > > go talk with icann about that. > > "$foo cannot be reached. we phoned them up, but they didn't react to our inquiries the way we wanted them to. we didn't want to send them postal mail. they didn't publish an email in whois, but we mailed them anyway, but they didn't answer the way we wanted them to. we want ripe to take their resources away because we say so, and because of this example, we want everybody to be forced to publish a spamable email address that works [by which probably a heap of further madness is implied]" > > i think this summary is already formulated in a way so my points are clear... > another thing: if $a has about 100 issues per month with $b, and they even are in the same country and jurisdiction - sorry, but the picture painted is something like: $a nags $b (big time - i mean, a hundred issues per month...) because $a wants something from $b, but $b obviously seems to have a different view on the issue, and obviously the law is on $b's side (that ther's no lea in said jurisdiction is ofc a very blatant lie), and therefore $a wants ripe to take "somebody's" resources away in case they don't comply to rules $a wants to put up (and which don't make rational sense). > i'd call _that_ abuse... > > if "ugly" db statistics are the issue, the working and straightforward solution would be a refer attribute in inet*num objects. with the ripe's allocation objects remaining, the quality of the ripe whois db would probably be very good. > > regards, > > Chris > > -- 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 ====================================================================== From brian.nisbet at heanet.ie Wed Apr 11 18:50:13 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 11 Apr 2012 17:50:13 +0100 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F857573.2010904@heanet.ie> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> Message-ID: <4F85B645.6000809@heanet.ie> "Brian Nisbet" wrote the following on 11/04/2012 13:13: > Chris, > > "Chris" wrote the following on 11/04/2012 11:03: >> On 04/10/2012 05:18 PM, Joe St Sauver wrote: >>> Maintenance of the database documenting who's been allocated/assigned >>> space is *core* to RIPE's mission. >> >> simply wrong. >> ripe's core is allocation. that's what they do. your mission is your >> private error. > > http://www.ripe.net/lir-services/ncc/functions > > Specifically the development and maintenance of the RIPE DB. Once all of > v4 space is allocated (soon now, soon), the primary job of the NCC and > the other four RIRs will be keeping a good registry. I do speak for the > NCC, but a substantial amount of the narrative recently has been around > keeping that registry up to date and, indeed, attempting to find new and > interesting ways of making sure the members put the right data in the > right place. As has been correctly pointed out, I managed to leave out a negative above. I do *not* speak for the NCC. Sorry for any confusion that may have caused. Brian. From chrish at consol.net Wed Apr 11 19:05:43 2012 From: chrish at consol.net (Chris) Date: Wed, 11 Apr 2012 19:05:43 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F85B4B1.5080103@powerweb.de> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F85B0E2.1070408@consol.net> <4F85B4B1.5080103@powerweb.de> Message-ID: <4F85B9E7.4090607@consol.net> On 04/11/2012 06:43 PM, Frank Gadegast wrote: >> obviously not true. ripe's core task is number resource coordination, the db is a service, if ripe decided not to provide for it - then there simply wouldn't be one. >> > > Sorry, but the above statement IS true indeed. > Chris: you are mixing RIPE and RIPE NCC. no. it is ripe's and ncc's core task. so talking about ripe as a superset or at least including ncc this is absolutely correct. > The community has a real interest in an up-to-date and working whois db, first of all it's not up to you (or any single one else) to decide for the community. and it's e.g. my and probably many others' interest that ncc can coordinate to make ip work. what you are calling for - no matter what you call it - doesn't affect this coordination task. what you are calling for essentially also isn't a working db (it works, and you are free to talk to people to ask them to change their objects according to your ideas), but making ripe some sort of police-substitute, and forcing everybody to follow your strange ideas which are not ripe-business. but being an enlightened (errm - i mean that french thing, you know, don't mistake this for hybris, please :) ) netizen, data economy btw is a real interest for me (actually it's the law)... maybe sbdy from ncc has an estimate on introducing a refer attribute in inet*num objects. i guess this should effectively lead to a technically less complex, as more streamlined, db. regards, Chris From fw at deneb.enyo.de Wed Apr 11 20:16:48 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 11 Apr 2012 20:16:48 +0200 Subject: [anti-abuse-wg] {Disarmed} Re: Introducing the RIPE NCC Report Form In-Reply-To: (Suresh Ramasubramanian's message of "Wed, 11 Apr 2012 07:08:32 +0530") References: <12040613255230_443B@oregon.uoregon.edu> <4F2538C315ACAC42AD334C533C247C47263E87F3@bkexchmbx01.blacknight.local> Message-ID: <87obqyuoa7.fsf@mid.deneb.enyo.de> * Suresh Ramasubramanian: > The same thing with ARIN or any other RIR whois .. if you find a UPS > store maildrop with a bunch of /20s mapped to it .. and each > successive /20 you find is entirely populated with "something bad" .. > then a full text search of the RIR's db for all netblocks registered > to that UPS store might be instructive. Instructive for what? As long as the responsible LIR is readily identifiable, I don't think RIPE NCC needs to get involved, at least from a network abuse perspective. Typically, the LIR is in a much better position to implement effective measures. Other LIRs may have concerns about misuse of address resources and encourage RIPE NCC to investigate things more aggressively from a resource usage perspective, but this is unrelated to actual network and abuse, and it is totally unclear whether we will experience address shortage in a significant way, ever. Admittedly, proper LIR identification is not a completely solved issue, mainly because the RIPE DB does not contain cross-references to official registers (where applicable; these are generally provided during LIR enrollment), the database does not contain the contracting LIR for provider-independent objects, and tools like the abuse mailbox finder do not implement LIR fallback even if the required information is present in the public database. From ops.lists at gmail.com Wed Apr 11 20:37:54 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 12 Apr 2012 00:07:54 +0530 Subject: [anti-abuse-wg] {Disarmed} Re: Introducing the RIPE NCC Report Form In-Reply-To: <87obqyuoa7.fsf@mid.deneb.enyo.de> References: <12040613255230_443B@oregon.uoregon.edu> <4F2538C315ACAC42AD334C533C247C47263E87F3@bkexchmbx01.blacknight.local> <87obqyuoa7.fsf@mid.deneb.enyo.de> Message-ID: <4777A321-AF48-4A71-8B3A-65FE39BF2045@gmail.com> it depends, on whether we saw a pattern of such large allocations coming through the same LIR on multiple occasions. engaging the LIR might work in some but not all cases such as where the LIR itself is a front for whatever activity you are complaining to it about. Like say sending an abuse report to estdomains that a domain registered through them was used by the rbn. --srs (iPad) On 11-Apr-2012, at 23:46, Florian Weimer wrote: > * Suresh Ramasubramanian: > >> The same thing with ARIN or any other RIR whois .. if you find a UPS >> store maildrop with a bunch of /20s mapped to it .. and each >> successive /20 you find is entirely populated with "something bad" .. >> then a full text search of the RIR's db for all netblocks registered >> to that UPS store might be instructive. > > Instructive for what? > > As long as the responsible LIR is readily identifiable, I don't think > RIPE NCC needs to get involved, at least from a network abuse > perspective. Typically, the LIR is in a much better position to > implement effective measures. Other LIRs may have concerns about > misuse of address resources and encourage RIPE NCC to investigate > things more aggressively from a resource usage perspective, but this > is unrelated to actual network and abuse, and it is totally unclear > whether we will experience address shortage in a significant way, > ever. > > Admittedly, proper LIR identification is not a completely solved > issue, mainly because the RIPE DB does not contain cross-references to > official registers (where applicable; these are generally provided > during LIR enrollment), the database does not contain the contracting > LIR for provider-independent objects, and tools like the abuse mailbox > finder do not implement LIR fallback even if the required information > is present in the public database. From ripe-anti-spam-wg at powerweb.de Thu Apr 12 00:02:33 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 12 Apr 2012 00:02:33 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F85B9E7.4090607@consol.net> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F85B0E2.1070408@consol.net> <4F85B4B1.5080103@powerweb.de> <4F85B9E7.4090607@consol.net> Message-ID: <4F85FF79.6070409@powerweb.de> Chris wrote: > On 04/11/2012 06:43 PM, Frank Gadegast wrote: >>> obviously not true. ripe's core task is number resource coordination, the db is a service, if ripe decided not to provide for it - then there simply wouldn't be one. >>> >> >> Sorry, but the above statement IS true indeed. >> Chris: you are mixing RIPE and RIPE NCC. > > no. it is ripe's and ncc's core task. so talking about ripe as a superset Not a superset, a community. > or at least including ncc this is absolutely correct. > >> The community has a real interest in an up-to-date and working whois db, > > first of all it's not up to you (or any single one else) to decide for the community. I did not "decide" anything (great, if I could), but, as you can see on the list, at the RIPE meetings and other points where anti abuse people meet: people that have to deal with abuse every day want the best systems to direct abuse reports to the responsible people. Even most admins are very thankful, when they receive abuse reports quick as possible to prevent more abuse originating from their own, but abused resources. So: there is an interest in an up-to-date database from the community or at least a part of the community. And there is also a very understandable need to protect private data as well. Currently its all mixed up and Tobias RFC is still not in place, that will finally make it possible to protect private data, whenever the object owner wants it and still publish abuse details. > and it's e.g. my and probably many others' interest that ncc can coordinate to make ip work. Sure. > what you are calling for - no matter what you call it - doesn't affect this coordination task. what you are calling for essentially also isn't a working db (it works, and you are free to talk to people to ask them to change their objects according to your ideas), Thank you that you allow me to present my opinions and ideas here, didnt know, that Im allowed to do that on this list until now ... > but making ripe some sort of police-substitute, Not at all, I dont see RIPE NCC following any specific abuse issues like a detective (well, not yet), they have no call to do this, probably no legal background or whatever what you need to play policemen. But: RIPE NCC has a contract wich forces them to store, maintain and publish this database, as far as I can see. And the NCC is also urged to do this in the best and most accurate way, but they simply dont. The database is mixing private with needed public data, gives access to this or that data in a strangly controlled method (objects owner should be allowed to protect there private data from all access, if they want or need to and should not have to hope on a maximum-of-3000-queries-per-day blacklist-stupid-kind-of-protection and abuse data should be released to the public without any restriction), the database is incomplete, not following the own guidelines and contains a lot, I mean, really a lot of old not updated data. Funny that google can present us the text of all webpages easily and up-to-date including all changes during the last 5 minutes, but the NCC never managed to clean the database up during the last years ? And never tried to. > and forcing everybody to follow your strange ideas which are not ripe-business. Whats strange about a database with correct data ? If there is no mandate to have accurate data in this database, well, then you can shut it down completely (there is nothing worse than old data). > but being an enlightened (errm - i mean that french thing, you know, don't mistake this for hybris, please :) ) netizen, data economy btw is a real interest for me (actually it's the law)... > > maybe sbdy from ncc has an estimate on introducing a refer attribute in inet*num objects. i guess this should effectively lead to a technically less complex, as more streamlined, db. > When is the mandatory abuse-c coming ? And will the NCC check the email addresses at least with some minor technical methods (like checking syntax, MX records, availability of the mailserver). Its law in Germany (and I think common sense in the world), that newsletter owner should only mail to users that double-opt-in, so whats so complicated to test the email addresses with an email including a link, that needs to be clicked ? Doing that NCC would have done, whats technical possible and proudly present a database, they have checked. Whoever wants to hide, still can hide and ignore mail, but the NCC would be save from any blame. Somebody asked me today, if there are whatever entities that could put some pressure on abuse friendly ISPs and I said no. Maybe we should publish the data we collect here (simply to protect our customers from abuse). Do you want to know the provider with the most contacts without any email address ? Or the ISPs with perfect abuse contacts leading to a non-responsive mailserver ? Full mailboxes ? And finally: whats about the amount of abuse reports we had to generate for IPs you are responsible for ? Public available and accessible for everybody ? Maybe we should invent an AS-based ranking, others could use via DNS as blacklist based on the amount of spam we received from any AS ... But we had this discussion already a few month ago, we all know where consol.net stands here ... I dont like to repeat myself. Kind regards, Frank > regards, > > Chris > > -- 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 ====================================================================== From leo.vegoda at icann.org Thu Apr 12 00:38:39 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 11 Apr 2012 15:38:39 -0700 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F85FF79.6070409@powerweb.de> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F85B0E2.1070408@consol.net> <4F85B4B1.5080103@powerweb.de> <4F85B9E7.4090607@consol.net> <4F85FF79.6070409@powerweb.de> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780A3A@EXVPMBX100-1.exc.icann.org> Frank Gadegast wrote: [...] > Funny that google can present us the text of all > webpages easily and up-to-date including all changes > during the last 5 minutes, but the NCC never > managed to clean the database up during the last years ? > And never tried to. This is nonsense. The RIPE NCC does the database clean-ups that there is a consensus for it to do. Look at the RIPE Database WG mailing list archives for recent announcements about recent activity. You really need to develop a consensus in the community first. The RIPE NCC as a secretariat will implement the changes there is a consensus for, not just random ideas people discuss or smart ideas staff have. Regards, Leo From P.Vissers at opta.nl Thu Apr 12 11:59:38 2012 From: P.Vissers at opta.nl (Vissers, Pepijn) Date: Thu, 12 Apr 2012 09:59:38 +0000 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780A3A@EXVPMBX100-1.exc.icann.org> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F85B0E2.1070408@consol.net> <4F85B4B1.5080103@powerweb.de> <4F85B9E7.4090607@consol.net> <4F85FF79.6070409@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780A3A@EXVPMBX100-1.exc.icann.org> Message-ID: [...] > You really need to develop a consensus in the community first [...] The constant fallback on 'consensus' is a) the root cause of RIPE [NCC]s inertia and b) in cases like this sadly one of its most valued principles and thus unchangeable. Catch-22, no action, no change. I consider RIPE, more than anyting, a democracy. Alexis de Tocqueville has written some excellent work on the dangers of democracies. ?In America, the majority draws a formidable circle around thought. Inside those limits, the writer is free; but unhappiness awaits him if he dares to leave them. It is not that he has to fear an auto-da-fe, but he is the butt of moritifications of all kinds of persecutions every day.? QED. Pepijn +++++++++++++++++++++++++++++++++++++++++++++ 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. From rezaf at mindspring.com Thu Apr 12 13:51:54 2012 From: rezaf at mindspring.com (Reza Farzan) Date: Thu, 12 Apr 2012 07:51:54 -0400 Subject: [anti-abuse-wg] Maxis Communications Bhd In-Reply-To: <4F857A40.3050402@ripe.net> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: Hello Laura, Reading most of the comments posted here, I see that most, if not all, want a clear accountability from the networks that provide our link to the Internet. Certainly, the RIPE NCC Report Form is a good start. But as so many have stated the lack of accountability and sheer indifference on behalf of some networks in handling Abuse / Spam reports. A case in point that I like to bring to everyone's attention is Maxis Communications Bhd, in Malaysia. Since 2009, I have traced and reported Abuse violations to Maxis Communications Bhd abuse team [ABUSE at maxis.com.my], but I just discovered that this network had ignored all my previous violations reports, as I just received the following "Not read" and "deleted without being read" confirmation notices in my inbox: To: Mail Abuse For Maxis Communications Bhd; Cc: Federal Trade Commission; junk at brightmail.com; nonregistered at coldrain.net; spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com; abuse at craigslist.org; postmaster at craigslist.org Subject: REPORTING SPAM Sent: Thu, 15 Apr 2010 18:23:44 +0800 was deleted without being read on Thu, 12 Apr 2012 19:03:21 +0800 ++++ To: Mail Abuse For Maxis Communications Bhd; Cc: Malaysian RMP; Federal Trade Commission; junk at brightmail.com; nonregistered at coldrain.net; report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com Subject: Spam: REPORTING SCAM/FRAUD Sent: Tue, 1 Sep 2009 06:47:31 +0800 was deleted without being read on Thu, 12 Apr 2012 19:12:52 +0800 ++++ To: Mail Abuse For Maxis Communications Bhd; Cc: Federal Trade Commission; junk at brightmail.com; nonregistered at coldrain.net; report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com Subject: REPORTING SPAM Sent: Mon, 27 Jul 2009 18:49:27 +0800 was deleted without being read on Thu, 12 Apr 2012 19:15:08 +0800 ++++ To: Mail Abuse For Maxis Communications Bhd Cc: Federal Trade Commission; junk at brightmail.com; nanas at killfile.org; nonregistered at coldrain.net; report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com Subject: REPORTING SPAM Sent: Thu, 23 Apr 2009 19:46:12 +0800 was deleted without being read on Thu, 12 Apr 2012 19:12:51 +0800 ++++ To: Mail Abuse For Maxis Communications Bhd; Cc: Federal Trade Commission; junk at brightmail.com; nanas at killfile.org; nonregistered at coldrain.net; report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com Subject: Spam: REPORTING SCAM/SPAM Sent: Thu, 7 May 2009 08:23:39 +0800 was deleted without being read on Thu, 12 Apr 2012 19:12:51 +0800 ++++ As these confirmations show, a network like Maxis Communications Bhd can simply choose not to respond, and completely ignore network violations reports, and after a few years [yes, YEARS] delete such reports as if nothing had happened. To be fair, I have copied this network's technical contact Muhadzir Abdul Majid [zay at maxis.com.my] as well as their Whois only contact, Chiau Tik Tan [cttan at maxis.net.my] so that they can for themselves what actually happens when someone reports and sends an abuse report to Maxis Communications Bhd. Thank you, Reza Farzan rezaf at mindspring.com From russ at consumer.net Thu Apr 12 14:23:51 2012 From: russ at consumer.net (russ at consumer.net) Date: Thu, 12 Apr 2012 08:23:51 -0400 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> <4F857573.2010904@heanet.ie> <4F85B0E2.1070408@consol.net> <4F85B4B1.5080103@powerweb.de> <4F85B9E7.4090607@consol.net> <4F85FF79.6070409@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780A3A@EXVPMBX100-1.exc.icann.org> Message-ID: <4F86C957.7040000@consumer.net> >I consider RIPE, more than anyting, a democracy. Alexis de Tocqueville has written some excellent work on the dangers of democracies. ?In America, the majority draws a formidable circle around thought. Inside those limits, the writer is free; but unhappiness awaits him if he dares to leave them. It is not that he has to fear an auto-da-fe, but he is the butt of moritifications of all kinds of persecutions every day.? see http://www.williampmeyers.org/republic.html From esa.laitinen at iki.fi Thu Apr 12 14:42:28 2012 From: esa.laitinen at iki.fi (Esa Laitinen) Date: Thu, 12 Apr 2012 14:42:28 +0200 Subject: [anti-abuse-wg] Maxis Communications Bhd In-Reply-To: References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: On Thu, Apr 12, 2012 at 1:51 PM, Reza Farzan wrote: > Since 2009, I have traced and reported Abuse violations to Maxis > Communications Bhd abuse team [ABUSE at maxis.com.my], but I just discovered > that this network had ignored all my previous violations reports, as I just > received the following "Not read" and "deleted without being read" > confirmation notices in my inbox: > > Dear Reza, there is one scenario where you would get those messages in error: they use MS Exchange 2010 SP1 and somebody moves the messages from Inbox to a personal folder. This occurs if you've requested read receipt. http://support.microsoft.com/kb/2471964 -- Mr. Esa Laitinen Tel. +41 76 200 2870 skype/yahoo: reunaesa Blog: http://happiloppuuahistaa.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at blacknight.ie Thu Apr 12 14:51:11 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Thu, 12 Apr 2012 12:51:11 +0000 Subject: [anti-abuse-wg] Maxis Communications Bhd In-Reply-To: References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: It also doesn't mean that "nobody" read the emails They could be going to multiple people. On 12 Apr 2012, at 13:42, Esa Laitinen wrote: > > > On Thu, Apr 12, 2012 at 1:51 PM, Reza Farzan wrote: > Since 2009, I have traced and reported Abuse violations to Maxis > Communications Bhd abuse team [ABUSE at maxis.com.my], but I just discovered > that this network had ignored all my previous violations reports, as I just > received the following "Not read" and "deleted without being read" > confirmation notices in my inbox: > > > Dear Reza, > > there is one scenario where you would get those messages in error: they use MS Exchange 2010 SP1 and somebody moves the messages from Inbox to a personal folder. This occurs if you've requested read receipt. http://support.microsoft.com/kb/2471964 > > > -- > Mr. Esa Laitinen > Tel. +41 76 200 2870 > skype/yahoo: reunaesa > Blog: http://happiloppuuahistaa.blogspot.com 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 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 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 ripe-anti-spam-wg at powerweb.de Thu Apr 12 15:15:19 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 12 Apr 2012 15:15:19 +0200 Subject: [anti-abuse-wg] Maxis Communications Bhd In-Reply-To: References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: <4F86D567.1000502@powerweb.de> Reza Farzan wrote: > Well, only about 8% of our daily reports return a "message read" or "ticket opened" or whatever else positiv message. Its clear that even more lazy network admins will publish accurate, but unattended abuse email contacts, when the abuse-c is mandatory. But at least it can be prooved, that an abuse report WAS delivered correctly more often, what already helps further legal activities (its a big difference in German law, if somebody had knowledge or not). And it helps statistics and the database itself ... And its also clear that abuse reporting reduces abuse, at least here with us. We started to deliver 3000 abuse report daily 3 year ago, we are now down to 800 per day. The RIPE database is also getting better and our methods also, we started with about 12% of reports that could not be delivered at all, simply because the domain of the abuse contact had a domain without MX or A record or the mailserver did not respond at all. This rate is now down to about 4.5% But we still have about 5% witout any abuse email address at all ... BTW: we only had 10 abuse reports this year to @maxis.com.my I know a lot of networks that are worse than that ... Kind regards, Frank > Hello Laura, > > Reading most of the comments posted here, I see that most, if not all, want > a clear accountability from the networks that provide our link to the > Internet. Certainly, the RIPE NCC Report Form is a good start. > > But as so many have stated the lack of accountability and sheer indifference > on behalf of some networks in handling Abuse / Spam reports. A case in point > that I like to bring to everyone's attention is Maxis Communications Bhd, in > Malaysia. > > Since 2009, I have traced and reported Abuse violations to Maxis > Communications Bhd abuse team [ABUSE at maxis.com.my], but I just discovered > that this network had ignored all my previous violations reports, as I just > received the following "Not read" and "deleted without being read" > confirmation notices in my inbox: > > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Federal Trade Commission; junk at brightmail.com; > nonregistered at coldrain.net; spam at mailpolice.com; spam at sendusspam.com; > submitspam at fortinet.com; abuse at craigslist.org; postmaster at craigslist.org > Subject: REPORTING SPAM > Sent: Thu, 15 Apr 2010 18:23:44 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:03:21 +0800 > > ++++ > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Malaysian RMP; Federal Trade Commission; junk at brightmail.com; > nonregistered at coldrain.net; report at dcm.mailprove.com; > spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com > Subject: Spam: REPORTING SCAM/FRAUD > Sent: Tue, 1 Sep 2009 06:47:31 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:12:52 +0800 > > ++++ > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Federal Trade Commission; junk at brightmail.com; > nonregistered at coldrain.net; report at dcm.mailprove.com; > spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com > Subject: REPORTING SPAM > Sent: Mon, 27 Jul 2009 18:49:27 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:15:08 +0800 > > ++++ > > > To: Mail Abuse For Maxis Communications Bhd > Cc: Federal Trade Commission; junk at brightmail.com; > nanas at killfile.org; nonregistered at coldrain.net; > report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; > submitspam at fortinet.com > Subject: REPORTING SPAM > Sent: Thu, 23 Apr 2009 19:46:12 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:12:51 +0800 > > > ++++ > > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Federal Trade Commission; junk at brightmail.com; > nanas at killfile.org; nonregistered at coldrain.net; > report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; > submitspam at fortinet.com > Subject: Spam: REPORTING SCAM/SPAM > Sent: Thu, 7 May 2009 08:23:39 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:12:51 +0800 > > > ++++ > > As these confirmations show, a network like Maxis Communications Bhd can > simply choose not to respond, and completely ignore network violations > reports, and after a few years [yes, YEARS] delete such reports as if > nothing had happened. > > To be fair, I have copied this network's technical contact Muhadzir Abdul > Majid [zay at maxis.com.my] as well as their Whois only contact, Chiau Tik Tan > [cttan at maxis.net.my] so that they can for themselves what actually happens > when someone reports and sends an abuse report to Maxis Communications Bhd. > > Thank you, > > Reza Farzan > rezaf at mindspring.com > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From leo.vegoda at icann.org Thu Apr 12 16:22:28 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 12 Apr 2012 07:22:28 -0700 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <201204120640.q3C6eMKL005937@powerweb.de> References: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780A3A@EXVPMBX100-1.exc.icann.org> <201204120640.q3C6eMKL005937@powerweb.de> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780AF4@EXVPMBX100-1.exc.icann.org> Hi Frank, This message is copied to the list, as requested. Frank Gadegast wrote: [...] > Lets ask me one thing (simply because you have an iconn email address): > is ICANN forcing the RIRs to have a public whois database by CONTRACT > and are the registries forced to have up-to-date and validated data in it ? > > Could you please point that out on the list ? I do not believe there is currently a contract between ICANN and the NRO or individual RIRs. In 2007, ICANN and the NRO agreed an exchange of letters. In ICANN's letter to the NRO it stated that it seeks "to further enhance our relationship for the mutual benefit of our organizations and respective communities. For that matter we wish and will seek to establish an appropriate legal arrangement within one (1) year from the date of this letter." I do not believe that arrangement has been established. You can find the announcement about the exchange of letters on the ICANN web site, here: http://www.icann.org/en/news/announcements/announcement-09nov07-en.htm The letters themselves are published on the correspondence pages but that announcement places them in a single page, which is more convenient to read. I expect the "Review of the ASO" document, which is currently in the second half of the public comment period, will have a fuller description of the relationship between the NRO and ICANN: http://www.icann.org/en/news/public-comment/aso-review-16mar12-en.htm Kind regards, Leo Vegoda From julien at tayon.net Thu Apr 12 16:27:04 2012 From: julien at tayon.net (julien tayon) Date: Thu, 12 Apr 2012 16:27:04 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <4F855702.6080107@consol.net> References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> Message-ID: >> Maintenance of the database documenting who's been allocated/assigned >> space is *core* to RIPE's mission. > > simply wrong. > ripe's core is allocation. that's what they do. your mission is your private error. Well NRO and ICANN may not agree : http://costarica43.icann.org/meetings/sanjose2012/presentation-raa-update-12mar12-en.pdf RIPE is clearly quoted in the organization involved in improving whois accuracy. Well, it is quoted ?RIPE NCC conducts monthly reviews of about 50 Whois records resulting in 500-600 annual so called ?audits?? ... it looks like a pretty more adequate solution than the one of the LACNIC, indeed. 2012/04/12 ... it is not obsolete news I presume ? Cheers, -- Jul From athina.fragkouli at ripe.net Thu Apr 12 16:57:23 2012 From: athina.fragkouli at ripe.net (Athina Fragkouli) Date: Thu, 12 Apr 2012 16:57:23 +0200 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force Message-ID: <4F86ED53.8080504@ripe.net> Dear colleagues, Current rules regarding bulk access to the data held in the RIPE Database were set based on the work of the Data Protection Task Force, which concluded its work in 2011. At that time, the DPTF published a report on it's activities and outcomes, which was published here: https://www.ripe.net/ripe/groups/tf/dp/report-of-the-ripe-data-protection-task-force Recent discussion on this list has suggested that a clear overview of the legal background to the framework and procedures proposed by the DPTF may help foster better community understanding of the RIPE Database rules and the justification behind them. In the interests of transparency and understanding, the RIPE NCC has produced a report that provides the legal analysis and background of all proposals made by the DPTF. This report, which is intended to complement the original DPTF report, is available now at: https://www.ripe.net/data-tools/support/documentation/legal-framework-and-procedures-proposed-by-the-data-protection-task-force Kind regards, Athina Fragkouli Legal Counsel RIPE NCC From kranjbar at ripe.net Thu Apr 12 17:00:30 2012 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Thu, 12 Apr 2012 17:00:30 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: References: <12041008180052_4495@oregon.uoregon.edu> <4F855702.6080107@consol.net> Message-ID: Hello all, Just to clarify some points: - Everything that RIPE NCC Registration Services does for a member is accurately reflected in the RIPE Database. Our registry of allocations made to members and member's organisation information is always in sync with the RIPE Database. In fact, in this case RIPE Database objects are secondary to our core registration files. So, as an example for the resources that are allocated by the RIPE NCC, the data is as accurate as we can contractually expect from our members. Our members are subject to our random audits and our core registry data quality is evaluated regularly. All of this is reflected in the RIPE Database. - The RIPE Database is also a public and open database. For example, sub-assignments made by our members to their customers might be maintained by the customer. This means that there are records in the RIPE Database that are not maintained by the RIPE NCC. Those records are only subject to our automatic data clean-up processes. - The RIPE NCC performs the automatic database clean-ups as they have been agreed by the community. - To emphasise again, the RIPE NCC is the secretariat for the RIPE community, so if the community reaches consensus on a policy -for example, to have automatic technical checks on the validity of email addresses- then we will implement it. - I also observed some technical suggestions about changes to the behavior of the RIPE Database, including the implementation of mechanisms like referrals. I would suggest discussing these subjects on the RIPE Database Working Group mailing list. If consensus is reached on any change, we will implement the change. I hope this clarifies some of the concerns raised on the list. Kind regards, Kaveh. --- Kaveh Ranjbar RIPE NCC Database Group Manager From ops.lists at gmail.com Thu Apr 12 17:43:23 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 12 Apr 2012 21:13:23 +0530 Subject: [anti-abuse-wg] Maxis Communications Bhd In-Reply-To: References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> Message-ID: <956A8A23-4CF9-47BA-9605-AA9D54D9DF98@gmail.com> look, i and others are trying to get ripe ncc to actually fix a rather lackadaisical attitude to ip allocation and whois accuracy what you are doing here seems to be using the list as an abuse desk substitute for reaching an isp with ip space in malaysia, which last i checked was still getting ip space from apnic, not ripe --srs (iPad) On 12-Apr-2012, at 17:21, "Reza Farzan" wrote: > > Hello Laura, > > Reading most of the comments posted here, I see that most, if not all, want > a clear accountability from the networks that provide our link to the > Internet. Certainly, the RIPE NCC Report Form is a good start. > > But as so many have stated the lack of accountability and sheer indifference > on behalf of some networks in handling Abuse / Spam reports. A case in point > that I like to bring to everyone's attention is Maxis Communications Bhd, in > Malaysia. > > Since 2009, I have traced and reported Abuse violations to Maxis > Communications Bhd abuse team [ABUSE at maxis.com.my], but I just discovered > that this network had ignored all my previous violations reports, as I just > received the following "Not read" and "deleted without being read" > confirmation notices in my inbox: > > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Federal Trade Commission; junk at brightmail.com; > nonregistered at coldrain.net; spam at mailpolice.com; spam at sendusspam.com; > submitspam at fortinet.com; abuse at craigslist.org; postmaster at craigslist.org > Subject: REPORTING SPAM > Sent: Thu, 15 Apr 2010 18:23:44 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:03:21 +0800 > > ++++ > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Malaysian RMP; Federal Trade Commission; junk at brightmail.com; > nonregistered at coldrain.net; report at dcm.mailprove.com; > spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com > Subject: Spam: REPORTING SCAM/FRAUD > Sent: Tue, 1 Sep 2009 06:47:31 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:12:52 +0800 > > ++++ > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Federal Trade Commission; junk at brightmail.com; > nonregistered at coldrain.net; report at dcm.mailprove.com; > spam at mailpolice.com; spam at sendusspam.com; submitspam at fortinet.com > Subject: REPORTING SPAM > Sent: Mon, 27 Jul 2009 18:49:27 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:15:08 +0800 > > ++++ > > > To: Mail Abuse For Maxis Communications Bhd > Cc: Federal Trade Commission; junk at brightmail.com; > nanas at killfile.org; nonregistered at coldrain.net; > report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; > submitspam at fortinet.com > Subject: REPORTING SPAM > Sent: Thu, 23 Apr 2009 19:46:12 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:12:51 +0800 > > > ++++ > > > To: Mail Abuse For Maxis Communications Bhd; > Cc: Federal Trade Commission; junk at brightmail.com; > nanas at killfile.org; nonregistered at coldrain.net; > report at dcm.mailprove.com; spam at mailpolice.com; spam at sendusspam.com; > submitspam at fortinet.com > Subject: Spam: REPORTING SCAM/SPAM > Sent: Thu, 7 May 2009 08:23:39 +0800 > > was deleted without being read on Thu, 12 Apr 2012 19:12:51 +0800 > > > ++++ > > As these confirmations show, a network like Maxis Communications Bhd can > simply choose not to respond, and completely ignore network violations > reports, and after a few years [yes, YEARS] delete such reports as if > nothing had happened. > > To be fair, I have copied this network's technical contact Muhadzir Abdul > Majid [zay at maxis.com.my] as well as their Whois only contact, Chiau Tik Tan > [cttan at maxis.net.my] so that they can for themselves what actually happens > when someone reports and sends an abuse report to Maxis Communications Bhd. > > Thank you, > > Reza Farzan > rezaf at mindspring.com > > From russ at consumer.net Thu Apr 12 18:22:55 2012 From: russ at consumer.net (russ at consumer.net) Date: Thu, 12 Apr 2012 12:22:55 -0400 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F86ED53.8080504@ripe.net> References: <4F86ED53.8080504@ripe.net> Message-ID: <4F87015F.1000009@consumer.net> This is not a legitimate legal review as no specific laws are referenced and there is no description of how they went from some unspecified law to the actual practices by RIPE of restricting access to whois. This is confirmation that there has been no legitimate legal review and RIPE staff just makes things up as they go along to please a small number of people who run everything. What a joke. On 4/12/2012 10:57 AM, Athina Fragkouli wrote: > Dear colleagues, > > Current rules regarding bulk access to the data held in the RIPE > Database were set based on the work of the Data Protection Task Force, > which concluded its work in 2011. At that time, the DPTF published a > report on it's activities and outcomes, which was published here: > https://www.ripe.net/ripe/groups/tf/dp/report-of-the-ripe-data-protection-task-force > > > Recent discussion on this list has suggested that a clear overview of > the legal background to the framework and procedures proposed by the > DPTF may help foster better community understanding of the RIPE Database > rules and the justification behind them. > > In the interests of transparency and understanding, the RIPE NCC has > produced a report that provides the legal analysis and background of all > proposals made by the DPTF. This report, which is intended to complement > the original DPTF report, is available now at: > https://www.ripe.net/data-tools/support/documentation/legal-framework-and-procedures-proposed-by-the-data-protection-task-force > > Kind regards, > > Athina Fragkouli > Legal Counsel > RIPE NCC > From lists at help.org Thu Apr 12 19:32:03 2012 From: lists at help.org (lists at help.org) Date: Thu, 12 Apr 2012 13:32:03 -0400 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F8708CA.2030708@help.org> References: <4F870630.1070603@help.org> <4F8708CA.2030708@help.org> Message-ID: <4F871193.20806@help.org> There are companies now that download the various whois databases and repackage and resell the data. One company DomainTools.com has their parent company in the EU in Luxembourg. How is it that they download all this data and resell it apparently without a problem. If it was illegal why they don't get prosecuted? This "legal framework" doesn't address any of that. DomainTool.com has filed a lawsuit in the US federal courts asking them to rule that downloading and selling whois data is illegal. the lawsuit in question involves data from Tucows in Canada so it is unclear how a US court can rule on that. In any case none of this stuff in discussed in the legal framework paper. Are there plans to take legal action against DomainTools.com for selling this data? If not, why not? Why are there restrictions on others if some companies are downloading and selling this data anyway? Just like you can't force people to answer their abuse mailboxes I don't see how you can force people to use (or not to use) data in a certain way after it is made public. http://domainnamewire.com/2012/04/06/domain-tools-files-preemptive-lawsuit/ From lists at help.org Thu Apr 12 18:54:34 2012 From: lists at help.org (lists at help.org) Date: Thu, 12 Apr 2012 12:54:34 -0400 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F870630.1070603@help.org> References: <4F870630.1070603@help.org> Message-ID: <4F8708CA.2030708@help.org> There are companies now that download the various whois databases and repackage and resell the data. One company DomainTools.com has their parent company in the EU in Luxembourg. How is it that they download all this data and resell it apparently without a problem. If it was illegal why they don't get prosecuted? This "legal framework" doesn't address any of that. DomainTool.com has filed a lawsuit in the US federal courts asking them to rule that downloading and selling whois data is illegal. the lawsuit in question involves data from Tucows in Canada so it is unclear how a US court can rule on that. In any case none of this stuff in discussed in the legal framework paper. Are there plans to take legal action against DomainTools.com for selling this data? If not, why not? Why are there restrictions on others if some companies are downloading and selling this data anyway? Just like you can't force people to answer their abuse mailboxes I don't see how you can force people to use (or not to use) data in a certain way after it is made public. http://domainnamewire.com/2012/04/06/domain-tools-files-preemptive-lawsuit/ From Woeber at CC.UniVie.ac.at Thu Apr 12 21:38:02 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 12 Apr 2012 19:38:02 +0000 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F8708CA.2030708@help.org> References: <4F870630.1070603@help.org> <4F8708CA.2030708@help.org> Message-ID: <4F872F1A.5070100@CC.UniVie.ac.at> Instead of trying to grok the text below, I'd suggest to refer to the URL at the end. After reading that page, I still cannot see a direct relevance to the NCC's services or procedures. But it may be within the mandate of the Anti-Abuse WG. Just one comment, as there is a reference to "lawfulness" and *not* quoting a particular law - I presume the north-american legal system is fundamentally different from the approach in other regions. My understnading is that everything is lawful, unless it is forbidden. Then, a reference to a particular law is probably helpful or required. lists at help.org wrote: > There are companies now that download the various whois databases and > repackage and resell the data. One company DomainTools.com has their > parent company in the EU in Luxembourg. How is it that they download > all this data and resell it apparently without a problem. If it was > illegal why they don't get prosecuted? This "legal framework" doesn't > address any of that. > > DomainTool.com has filed a lawsuit in the US federal courts asking them > to rule that downloading and selling whois data is illegal. the lawsuit > in question involves data from Tucows in Canada so it is unclear how a > US court can rule on that. In any case none of this stuff in discussed > in the legal framework paper. Are there plans to take legal action > against DomainTools.com for selling this data? If not, why not? Why > are there restrictions on others if some companies are downloading and > selling this data anyway? Just like you can't force people to answer > their abuse mailboxes I don't see how you can force people to use (or > not to use) data in a certain way after it is made public. > > http://domainnamewire.com/2012/04/06/domain-tools-files-preemptive-lawsuit/ Regards, Wilfried From lists at help.org Thu Apr 12 22:44:58 2012 From: lists at help.org (lists at help.org) Date: Thu, 12 Apr 2012 16:44:58 -0400 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F872F1A.5070100@CC.UniVie.ac.at> References: <4F870630.1070603@help.org> <4F8708CA.2030708@help.org> <4F872F1A.5070100@CC.UniVie.ac.at> Message-ID: <4F873ECA.5030606@help.org> >After reading that page, I still cannot see a direct relevance to the NCC's services or procedures. I believe DomainTools.com also downloads the RIR's whois database and repackages and sells the data along with historical whois data from the domain registrars. Isn't that related to the Data Protection Task Force legal framework? The report says certain procedures and policies were put in place to prevent downloads because it supposedly violates some type of data protection laws. Yet there is a company doing that and they don't seem to be concerned about the law and they seem to be freely selling the data. Do these Data Protection laws actually apply to this situation or are these laws being broken and not enforced? Or maybe some other explanation? It is all unclear to me. From Woeber at CC.UniVie.ac.at Thu Apr 12 23:11:43 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 12 Apr 2012 21:11:43 +0000 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F873ECA.5030606@help.org> References: <4F870630.1070603@help.org> <4F8708CA.2030708@help.org> <4F872F1A.5070100@CC.UniVie.ac.at> <4F873ECA.5030606@help.org> Message-ID: <4F87450F.9090708@CC.UniVie.ac.at> lists at help.org wrote: >>After reading that page, I still cannot see a direct relevance to the > NCC's services or procedures. > > I believe Well, so this may - or may not - be true. > DomainTools.com also downloads the RIR's There are 5 of them, so which one(s)? > whois database and > repackages and sells the data along with historical whois data from the > domain registrars. >From an RIR's point of view, I presume the domain registry stuff is not relevant. Maybe the combining and re-packaging can be used as another argument for violating the AUP(s). > Isn't that related to the Data Protection Task > Force legal framework? I think so, but the linked page didn't include any reference to an IP Resource Registry. I may have missed that though. > The report says certain procedures and policies > were put in place to prevent downloads because it supposedly violates > some type of data protection laws. Indeed, both on the administrative side (AUPs), as well as on the technical plane (query limits, anonymizing data before allowing bulk access,...) But I am pretty sure that you als do know, that almost each and every technical measure can be subverted, given a strong (and/or financial) interest :-) > Yet there is a company doing that > and they don't seem to be concerned about the law and they seem to be > freely selling the data. Again, a pretty week term: "seem", together with "believe", there isn't too much flesh on the bones to get the legal folks involved, isn't it? They would certainly ask for proof or credible leads, before getting their fingers wet and putting their organisation at (at least a financial) risk. > Do these Data Protection laws actually apply > to this situation They probably do in one way or another, details to be worked out on a case by case basis. > or are these laws being broken and not enforced? The (legal) enforcement is potentially an entirely different story again, in an international environment, depending on where the breach happened (which part?=, and where the offender can (potentially) be prosecuted or taken to court. > Or maybe some other explanation? It is all unclear to me. Now, moving a away some distance from "mere" AUP or (C) violations... If you are really interested in getting a handle on "bad stuff" on the Internet, you could try to get involved in the security and incident handling ballpark. (I am to some degeree). Personally, I am convinced that the IP Resource Registry environment is the wrong tree to bark at, in general. There's a whole infrastructure out there (law enforcement, voluntary, commercial, incident response teams, national CERTs,...) that is active with this respect. The RIRs are at the far out periphery of that, at best, although they try to support the "pros" where they can... Hth. Wilfried. Note: I am not representing the NCC with my comments here. But I was a member of the DPTF. And I sometimes get a glance at or information about "funny stuff". From lists at help.org Thu Apr 12 23:31:31 2012 From: lists at help.org (lists at help.org) Date: Thu, 12 Apr 2012 17:31:31 -0400 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F87450F.9090708@CC.UniVie.ac.at> References: <4F870630.1070603@help.org> <4F8708CA.2030708@help.org> <4F872F1A.5070100@CC.UniVie.ac.at> <4F873ECA.5030606@help.org> <4F87450F.9090708@CC.UniVie.ac.at> Message-ID: <4F8749B3.7050205@help.org> >the IP Resource Registry environment is the wrong tree to bark at, I have no idea what points you are trying to make in your replies. You seem to want to nitpick certain words in some sort of incoherent fashion without making any actual point about the issue at hand. Ripe posted a link to a report about putting restrictions on the whois data because they say use is restricted by law. I pointed out that commercial companies are using this data anyway. In the case of DomainTools.com they have been around for many years and anyone who has used the site knows they compile all this data and make reports. They focus on domain data but they also use the IP whois data (which you can easily see if you use their site). I can't tell exactly what the law is and I don't know exactly what commercial companies are doing with the data. Ripe put out the report and I am asking how it relates to the practical situation of what is happening in the real world as there seems to be disconnect. From chrish at consol.net Fri Apr 13 09:35:57 2012 From: chrish at consol.net (Chris) Date: Fri, 13 Apr 2012 09:35:57 +0200 Subject: [anti-abuse-wg] Analysis of the Legal Framework and Procedures Proposed by the Data Protection Task Force In-Reply-To: <4F8749B3.7050205@help.org> References: <4F870630.1070603@help.org> <4F8708CA.2030708@help.org> <4F872F1A.5070100@CC.UniVie.ac.at> <4F873ECA.5030606@help.org> <4F87450F.9090708@CC.UniVie.ac.at> <4F8749B3.7050205@help.org> Message-ID: <4F87D75D.8040703@consol.net> hi! my 2 cent: - it's against the terms of the whois-db as provided by ripe to use this for spam/address-dealing or anything else than ip coordination tasks. from what i see this seems to be undisputed. - if sbdy breaches this, uses the whois-db illegally (i think 'probable cause'), charges should be pressed against the respective party. i.e. i'd expect ripe ncc to get this going (as a default: with their local lea) when they obtain knowledge of such a suspicion which they consider to be taken serious. regards, Chris From pk at DENIC.DE Fri Apr 13 10:06:07 2012 From: pk at DENIC.DE (Peter Koch) Date: Fri, 13 Apr 2012 10:06:07 +0200 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 9 In-Reply-To: References: Message-ID: <20120413080607.GA8966@x27.adm.denic.de> On Wed, Apr 11, 2012 at 05:38:11PM +0200, Wout de Natris wrote: > 1. Primarily RIPE NCC needs or at least should need a proper overview of who its members are for several reasons that all have to do with internal processes like reaching out, billing and maintaining correct records, in short common business practice. yes, but let's please not confuse this with the RIPE database. -Peter From laura at ripe.net Fri Apr 13 12:03:48 2012 From: laura at ripe.net (Laura Cobley) Date: Fri, 13 Apr 2012 12:03:48 +0200 Subject: [anti-abuse-wg] Introducing the RIPE NCC Report Form In-Reply-To: <87iph6xp20.fsf@mid.deneb.enyo.de> References: <4F7B117F.4050505@ripe.net> <87hawwaecm.fsf@mid.deneb.enyo.de> <4F857A40.3050402@ripe.net> <87iph6xp20.fsf@mid.deneb.enyo.de> Message-ID: <4F87FA04.6010201@ripe.net> Dear Florian, On 4/11/12 5:31 PM, Florian Weimer wrote: > * Laura Cobley: > >> We ask you to include information such as mail delivery failure notices >> and copies of emails with headers, which clearly show the problem and >> the subsequent difficulties you are having. These help to substantiate >> the report. Our aim is to work together with you to further improve the >> quality of the data in the Internet number resource registry. > > Laura, I'm afraid you haven't answered my question. Let's suppose > I've experienced a reproducible email delivery issue which affects a > role object. I have reported this to related role and person objects > by *email*, but after a reasonable time period, the situation has not > been addressed. I have not sent letters to the postal addresses of > those objects, or have tried the phone and fax numbers. Can I still > use the report form? The different pieces of contact information are all potential ways to get in touch with the Internet number resource holder. If you have difficulties reaching them via any of those details, you can report this to us. I would recommend making a reasonable attempt to contact them first though, for example by giving them a phone call if you find that their email addresses are no longer working. I hope this answers your question. Best regards, Laura Cobley RIPE NCC > > Sorry if this comes across as obnoxious, but among WHOIS operators, > there is a whole spectrum of policies regarding incorrect contact > information, ranging from "we care about a single incorrect email > address" to "we need proof that mail cannot be delivered to that > postal address *and* that no one by that name lives or does business > at that place". I'm just curious where RIPE NCC is located on this > spectrum. > From kjz at gmx.net Sat Apr 14 14:29:08 2012 From: kjz at gmx.net (Karl-Josef Ziegler) Date: Sat, 14 Apr 2012 14:29:08 +0200 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 19 In-Reply-To: References: Message-ID: <4F896D94.9080502@gmx.net> Hello! > The different pieces of contact information are all potential ways to > get in touch with the Internet number resource holder. If you have > difficulties reaching them via any of those details, you can report this > to us. I would recommend making a reasonable attempt to contact them > first though, for example by giving them a phone call if you find that > their email addresses are no longer working. My experience: I've used the form because the email contacts from a provider in Romania were invalid. The phone contact given in the RIPE database was only a mobile phone number in Romania. I searched for this number in the web and only get a few results which all directed to the entry in the RIPE database. So it seems that this (prepaid?) phone was only used to register this IP space with RIPE. My claim was denied because I didn't made an attempt to contact the provider on mobile phone in Romania. I didn't contact them because I don't speak Romanian and I feared retaliation from possible criminals in Romania. So for an individual it may be very difficult to fulfill all the external requirements which are made by RIPE NCC. And, of course, RIPE may be in a better position to repel retaliations. RIPE NCC wrote back that they don't have the staff to check if the entries in the database are correct. So if RIPE will guarantee the validity of the database today they seem not to have the personal capacity for research. Best regards, - Karl-Josef Ziegler From ops.lists at gmail.com Sat Apr 14 14:50:57 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 14 Apr 2012 18:20:57 +0530 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 8, Issue 19 In-Reply-To: <4F896D94.9080502@gmx.net> References: <4F896D94.9080502@gmx.net> Message-ID: in which case we are wasting time and effort having this discussion, and regulatory compliance is probably the only thing that will produce a viable course of action --srs (iPad) On 14-Apr-2012, at 17:59, Karl-Josef Ziegler wrote: > Hello! > >> The different pieces of contact information are all potential ways to >> get in touch with the Internet number resource holder. If you have >> difficulties reaching them via any of those details, you can report this >> to us. I would recommend making a reasonable attempt to contact them >> first though, for example by giving them a phone call if you find that >> their email addresses are no longer working. > > My experience: I've used the form because the email contacts from a > provider in Romania were invalid. The phone contact given in the RIPE > database was only a mobile phone number in Romania. I searched for this > number in the web and only get a few results which all directed to the > entry in the RIPE database. So it seems that this (prepaid?) phone was > only used to register this IP space with RIPE. > > My claim was denied because I didn't made an attempt to contact the > provider on mobile phone in Romania. I didn't contact them because I > don't speak Romanian and I feared retaliation from possible criminals in > Romania. So for an individual it may be very difficult to fulfill all > the external requirements which are made by RIPE NCC. And, of course, > RIPE may be in a better position to repel retaliations. > > RIPE NCC wrote back that they don't have the staff to check if the > entries in the database are correct. So if RIPE will guarantee the > validity of the database today they seem not to have the personal > capacity for research. > > Best regards, > > - Karl-Josef Ziegler > > > From peter at hk.ipsec.se Sat Apr 14 15:27:13 2012 From: peter at hk.ipsec.se (peter h) Date: Sat, 14 Apr 2012 15:27:13 +0200 Subject: [anti-abuse-wg] current business practices In-Reply-To: <4F8580CD.4000502@powerweb.de> References: <4F7B117F.4050505@ripe.net> <4F857A40.3050402@ripe.net> <4F8580CD.4000502@powerweb.de> Message-ID: <201204141527.14398.peter@hk.ipsec.se> On Wednesday 11 April 2012 15.02, Frank Gadegast wrote: > Laura Cobley wrote: > > Dear Florian and all, > > Hi, > > (some details from our current experiences with RIPE NCC and accuracy > of the RIPE objects) > > we currently have one case where a really big German cablenet ISP > is having exacly one abuse-eMail address for their tech-c, abuse-mailbox > and admin-c, for all their objects. > > And this one email has a domain, what does not belong to the ISP > anymore, since November 2011, its currently owned by a domain grabber, > because the ISP deleted the domain on purpose (on behalf of a > change in the company name years ago). > There is no other working contact information (phone lets you end up at > their hotline where they have absolutly no idea about abuse), snail mail > is no option, fax number is not supplied. Why holding back the name of the ISP ? It will only protect the guilty and in addition it will cast shadows over those that does have valid whois info and in addition is taking abuse seruously. Tell us : who is the big ISP that abuses Internet resources ?? > > We tried mailing there peering contact, their normal customer email > from their website, filled their online feedback form and then > opened a normal ticket at RIPE NCC, were just told > to open another ticket at RIPE NCC and invested about 5 hours > already describing the problem at RIPE NCC. > Simply no chance, RIPE NCC is responding to tickets on a daily basis, > even during business hours (jesus, we will respond in about 5 minutes > if something serious like that will happen to our networks). > The interest at the RIPE NCC to fix database problems does not seem > > *snip* > > > > -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From ripe-anti-spam-wg at powerweb.de Sat Apr 14 16:07:19 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sat, 14 Apr 2012 16:07:19 +0200 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: References: <4F896D94.9080502@gmx.net> Message-ID: <4F898497.8000306@powerweb.de> Suresh Ramasubramanian wrote: > in which case we are wasting time not at all. its true that RIPE NCC neither has the staff nor the mandate to validate objects. RIPE NCC will always tell the complainant to try contacting the abuser and will never do anything else, simply because they dont have to (thats why all those forms are pretty useless). SO the question is, if the community wants the NCC to make more. There are little things the NCC could do and wont need extra staff, simple checks could be programmed and automated, like: (ordered from very simple to more complicated) - check if there is any email address for every object (my preferred ISP is surely telecomitalia.it or all those lovely ERX allocations we constantly get spam from, the only email address you can find is the one in the changed-by field) - validate the syntax of the abuse email address (like: abuse at ti.ru.only I always fall over) - check the domain, MX or A record of the domain (like the ones from online.kz, lovely :o) - check the availablity of those mailservers (my favorite is currently airtel.in, wich have severe internal problems, but thats not RIPE, ok) this will: - make the ISPs more aware of the problem - make them check their objects more regulary - kick out the entries that are really stupid I would call these basic validation checks, there are simple to implementent and do not cost anything. So: does the community want that to be implemented ? And: what could be done to fix those ? RIPE NCC has internal email addresses to contact there members, so a request to fix objects could be mail to those ... Furthermore the NCC could - send testmails to the email address and evaluate the return mails - send emails including a link to click More complicated, will probably cost something and will stress all members. So: does the community want those two to be implemented ? Kind regards, Frank > and effort having this discussion, and regulatory compliance is probably the only thing that will produce a viable course of action > > --srs (iPad) > > On 14-Apr-2012, at 17:59, Karl-Josef Ziegler wrote: > >> Hello! >> >>> The different pieces of contact information are all potential ways to >>> get in touch with the Internet number resource holder. If you have >>> difficulties reaching them via any of those details, you can report this >>> to us. I would recommend making a reasonable attempt to contact them >>> first though, for example by giving them a phone call if you find that >>> their email addresses are no longer working. >> >> My experience: I've used the form because the email contacts from a >> provider in Romania were invalid. The phone contact given in the RIPE >> database was only a mobile phone number in Romania. I searched for this >> number in the web and only get a few results which all directed to the >> entry in the RIPE database. So it seems that this (prepaid?) phone was >> only used to register this IP space with RIPE. >> >> My claim was denied because I didn't made an attempt to contact the >> provider on mobile phone in Romania. I didn't contact them because I >> don't speak Romanian and I feared retaliation from possible criminals in >> Romania. So for an individual it may be very difficult to fulfill all >> the external requirements which are made by RIPE NCC. And, of course, >> RIPE may be in a better position to repel retaliations. >> >> RIPE NCC wrote back that they don't have the staff to check if the >> entries in the database are correct. So if RIPE will guarantee the >> validity of the database today they seem not to have the personal >> capacity for research. >> >> Best regards, >> >> - Karl-Josef Ziegler >> >> >> > > > -- 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 ====================================================================== From ops.lists at gmail.com Sat Apr 14 17:12:06 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 14 Apr 2012 20:42:06 +0530 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: <4F898497.8000306@powerweb.de> References: <4F896D94.9080502@gmx.net> <4F898497.8000306@powerweb.de> Message-ID: <1983E042-45CA-496F-A39E-0E13DAC3FA4E@gmail.com> so we can address the dumb and careless type of isp this way, but there are usually multiple different channels to reach out to those the truly criminal netblock owners are a far greater problem dont you think? --srs (iPad) On 14-Apr-2012, at 19:37, Frank Gadegast wrote: > Suresh Ramasubramanian wrote: >> in which case we are wasting time > > not at all. > > its true that RIPE NCC neither has the staff nor the mandate > to validate objects. RIPE NCC will always tell the complainant > to try contacting the abuser and will never do anything else, > simply because they dont have to (thats why all those forms > are pretty useless). > > SO the question is, if the community wants the NCC to make more. > > There are little things the NCC could do and wont need extra staff, > simple checks could be programmed and automated, like: > (ordered from very simple to more complicated) > > - check if there is any email address for every object > (my preferred ISP is surely telecomitalia.it or > all those lovely ERX allocations we constantly get spam > from, the only email address you can find is the one > in the changed-by field) > - validate the syntax of the abuse email address > (like: abuse at ti.ru.only I always fall over) > - check the domain, MX or A record of the domain > (like the ones from online.kz, lovely :o) > - check the availablity of those mailservers > (my favorite is currently airtel.in, wich have > severe internal problems, but thats not RIPE, ok) > > this will: > - make the ISPs more aware of the problem > - make them check their objects more regulary > - kick out the entries that are really stupid > > I would call these basic validation checks, there > are simple to implementent and do not cost anything. > > So: does the community want that to be implemented ? > And: what could be done to fix those ? > RIPE NCC has internal email addresses to contact > there members, so a request to fix objects > could be mail to those ... > > Furthermore the NCC could > - send testmails to the email address and > evaluate the return mails > - send emails including a link to click > > More complicated, will probably cost something and > will stress all members. > > So: does the community want those two to be implemented ? > > > Kind regards, Frank > > > and effort having this discussion, and regulatory compliance is probably the only thing that will produce a viable course of action >> >> --srs (iPad) >> >> On 14-Apr-2012, at 17:59, Karl-Josef Ziegler wrote: >> >>> Hello! >>> >>>> The different pieces of contact information are all potential ways to >>>> get in touch with the Internet number resource holder. If you have >>>> difficulties reaching them via any of those details, you can report this >>>> to us. I would recommend making a reasonable attempt to contact them >>>> first though, for example by giving them a phone call if you find that >>>> their email addresses are no longer working. >>> >>> My experience: I've used the form because the email contacts from a >>> provider in Romania were invalid. The phone contact given in the RIPE >>> database was only a mobile phone number in Romania. I searched for this >>> number in the web and only get a few results which all directed to the >>> entry in the RIPE database. So it seems that this (prepaid?) phone was >>> only used to register this IP space with RIPE. >>> >>> My claim was denied because I didn't made an attempt to contact the >>> provider on mobile phone in Romania. I didn't contact them because I >>> don't speak Romanian and I feared retaliation from possible criminals in >>> Romania. So for an individual it may be very difficult to fulfill all >>> the external requirements which are made by RIPE NCC. And, of course, >>> RIPE may be in a better position to repel retaliations. >>> >>> RIPE NCC wrote back that they don't have the staff to check if the >>> entries in the database are correct. So if RIPE will guarantee the >>> validity of the database today they seem not to have the personal >>> capacity for research. >>> >>> Best regards, >>> >>> - Karl-Josef Ziegler >>> >>> >>> >> >> >> > > > -- > > 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 > ====================================================================== > From jorgen at hovland.cx Sat Apr 14 19:32:10 2012 From: jorgen at hovland.cx (Jørgen Hovland) Date: 14 Apr 2012 17:32:10 +0000 (GMT) Subject: [anti-abuse-wg] abuse email address validation - VOTE Message-ID: <4f89b49a368d81391700ded7263.jorgen@hovland.cx> An HTML attachment was scrubbed... URL: From shane at time-travellers.org Sat Apr 14 22:23:32 2012 From: shane at time-travellers.org (Shane Kerr) Date: Sat, 14 Apr 2012 22:23:32 +0200 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: <4F898497.8000306@powerweb.de> References: <4F896D94.9080502@gmx.net> <4F898497.8000306@powerweb.de> Message-ID: <20120414222332.0f63436b@shane-eeepc.home.time-travellers.org> Frank, On Saturday, 2012-04-14 16:07:19 +0200, Frank Gadegast wrote: > Suresh Ramasubramanian wrote: > > in which case we are wasting time > > not at all. > > its true that RIPE NCC neither has the staff nor the mandate > to validate objects. RIPE NCC will always tell the complainant > to try contacting the abuser and will never do anything else, > simply because they dont have to (thats why all those forms > are pretty useless). > > SO the question is, if the community wants the NCC to make more. > > There are little things the NCC could do and wont need extra staff, It's not inconceivable that the RIPE NCC could implement manual checks. (I think APNIC actually already has staff that follow up to correct contact information.) If these were done only when a problem is reported it could be hundreds of checks per year, not thousands; probably an extra 2 or 3 staff, so only increasing the RIPE NCC's operating budget by a few percent. Such a policy wouldn't satisfy people concerned with intentional abuse, but it is a necessary step. Personally I support both automated methods of checking contact information (like you propose) and manual methods of checking and updating contact information. I'm not sure how easy it would be to get consensus though. :) -- Shane From ripe-anti-spam-wg at powerweb.de Sat Apr 14 22:34:53 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sat, 14 Apr 2012 22:34:53 +0200 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: <1983E042-45CA-496F-A39E-0E13DAC3FA4E@gmail.com> References: <4F896D94.9080502@gmx.net> <4F898497.8000306@powerweb.de> <1983E042-45CA-496F-A39E-0E13DAC3FA4E@gmail.com> Message-ID: <4F89DF6D.6060404@powerweb.de> Suresh Ramasubramanian wrote: > so we can address the dumb and careless type of isp this way, but there are usually multiple different channels to reach out to those > > the truly criminal netblock owners are a far greater problem dont you think? Absolutly true, this will not get the bad guys, but NCC could easily eliminate mistakes that were done by accident. Or do you think, that Kabeldeutschland (AS31334) is using a domain for his abuse email address, that they owned once, but dont own anymore and that they did not correct this on purpose ? I think its a good and easy and cheap start for a validation, so why not correting whats possible ? I still like to have more votes. Kind regards, Frank > > --srs (iPad) > > On 14-Apr-2012, at 19:37, Frank Gadegast wrote: > >> Suresh Ramasubramanian wrote: >>> in which case we are wasting time >> >> not at all. >> >> its true that RIPE NCC neither has the staff nor the mandate >> to validate objects. RIPE NCC will always tell the complainant >> to try contacting the abuser and will never do anything else, >> simply because they dont have to (thats why all those forms >> are pretty useless). >> >> SO the question is, if the community wants the NCC to make more. >> >> There are little things the NCC could do and wont need extra staff, >> simple checks could be programmed and automated, like: >> (ordered from very simple to more complicated) >> >> - check if there is any email address for every object >> (my preferred ISP is surely telecomitalia.it or >> all those lovely ERX allocations we constantly get spam >> from, the only email address you can find is the one >> in the changed-by field) >> - validate the syntax of the abuse email address >> (like: abuse at ti.ru.only I always fall over) >> - check the domain, MX or A record of the domain >> (like the ones from online.kz, lovely :o) >> - check the availablity of those mailservers >> (my favorite is currently airtel.in, wich have >> severe internal problems, but thats not RIPE, ok) >> >> this will: >> - make the ISPs more aware of the problem >> - make them check their objects more regulary >> - kick out the entries that are really stupid >> >> I would call these basic validation checks, there >> are simple to implementent and do not cost anything. >> >> So: does the community want that to be implemented ? >> And: what could be done to fix those ? >> RIPE NCC has internal email addresses to contact >> there members, so a request to fix objects >> could be mail to those ... >> >> Furthermore the NCC could >> - send testmails to the email address and >> evaluate the return mails >> - send emails including a link to click >> >> More complicated, will probably cost something and >> will stress all members. >> >> So: does the community want those two to be implemented ? >> >> >> Kind regards, Frank >> >>> and effort having this discussion, and regulatory compliance is probably the only thing that will produce a viable course of action >>> >>> --srs (iPad) >>> >>> On 14-Apr-2012, at 17:59, Karl-Josef Ziegler wrote: >>> >>>> Hello! >>>> >>>>> The different pieces of contact information are all potential ways to >>>>> get in touch with the Internet number resource holder. If you have >>>>> difficulties reaching them via any of those details, you can report this >>>>> to us. I would recommend making a reasonable attempt to contact them >>>>> first though, for example by giving them a phone call if you find that >>>>> their email addresses are no longer working. >>>> >>>> My experience: I've used the form because the email contacts from a >>>> provider in Romania were invalid. The phone contact given in the RIPE >>>> database was only a mobile phone number in Romania. I searched for this >>>> number in the web and only get a few results which all directed to the >>>> entry in the RIPE database. So it seems that this (prepaid?) phone was >>>> only used to register this IP space with RIPE. >>>> >>>> My claim was denied because I didn't made an attempt to contact the >>>> provider on mobile phone in Romania. I didn't contact them because I >>>> don't speak Romanian and I feared retaliation from possible criminals in >>>> Romania. So for an individual it may be very difficult to fulfill all >>>> the external requirements which are made by RIPE NCC. And, of course, >>>> RIPE may be in a better position to repel retaliations. >>>> >>>> RIPE NCC wrote back that they don't have the staff to check if the >>>> entries in the database are correct. So if RIPE will guarantee the >>>> validity of the database today they seem not to have the personal >>>> capacity for research. >>>> >>>> Best regards, >>>> >>>> - Karl-Josef Ziegler >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> >> 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 >> ====================================================================== >> > > -- 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 ====================================================================== From ripe-anti-spam-wg at powerweb.de Sat Apr 14 22:46:53 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sat, 14 Apr 2012 22:46:53 +0200 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: <20120414222332.0f63436b@shane-eeepc.home.time-travellers.org> References: <4F896D94.9080502@gmx.net> <4F898497.8000306@powerweb.de> <20120414222332.0f63436b@shane-eeepc.home.time-travellers.org> Message-ID: <4F89E23D.7090600@powerweb.de> Shane Kerr wrote: > Frank, > > > It's not inconceivable that the RIPE NCC could implement manual checks. > (I think APNIC actually already has staff that follow up to correct > contact information.) If these were done only when a problem is > reported it could be hundreds of checks per year, not thousands; > probably an extra 2 or 3 staff, so only increasing the RIPE NCC's > operating budget by a few percent. Im not talking about manual checks, those are automatic checks. All checks I described are automatic checks, the last once are only a bit more complicated to implement. You can start with the oldest objects and run these tests in a couple of days over the whole db. If a automatic test fails, simply mail the customer email address (that is known only by the NCC) and the mantainer (if there is one) and the address in the changed-by field (well there IS one) and wait ... the NCC could send a reminder a week later and if nothing happens, a big notice could be shown, when the LIR logs into the LIR portal next time. > Such a policy wouldn't satisfy people concerned with intentional abuse, > but it is a necessary step. Thats what I mean, start with the easy things. > Personally I support both automated methods of checking contact So thats a +1 ? > information (like you propose) and manual methods of checking and > updating contact information. I'm not sure how easy it would be to get > consensus though. :) Well, there is no harm to the members, its just reminders. I would love to know, if one of my objects has a not working email address. Kind regards, Frank > > -- > Shane > > -- 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 ====================================================================== From mschmidt at ripe.net Mon Apr 16 15:24:51 2012 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 16 Apr 2012 15:24:51 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) Message-ID: Dear colleagues, The text of RIPE Policy Proposal 2011-06, "Abuse Contact Management in the RIPE NCC Database", has been revised based on community feedback received on the mailing list. We published the new version (version 2.0) today, 16 April. As a result, a new Discussion Phase is set for the proposal. Changes in version 2.0 include: - Overall rewording - Description of the use of "abuse-c:" and "abuse-mailbox:" on differing RIPE Database objects - Removal of references to a transition period You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-06 We encourage you to review this RIPE Policy Proposal and send your comments to by 7 May 2012. Regards Marco Schmidt on behalf of the Policy Development Office RIPE NCC From ripe-anti-spam-wg at powerweb.de Mon Apr 16 15:57:52 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 16 Apr 2012 15:57:52 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <201204161334.q3GDXx2K011061@powerweb.de> References: <201204161334.q3GDXx2K011061@powerweb.de> Message-ID: <4F8C2560.2000805@powerweb.de> Marco Schmidt wrote: > Dear colleagues, Hello, I like to recommend the following change, from "The "abuse-mailbox:" attribute must be available in an unrestricted way via whois, APIs and future techniques." to "The "abuse-mailbox:" attribute for a given object must be available in an unrestricted way via whois, APIs and future techniques with a single request". because its not clear how the right abuse-mailbox field could be found for example via whois. It will be no help, if there is a first request needed to find the abuse-c and a second request to read the abuse-mailbox field. This could lead to reach limits, if either the access to the abuse-c field is limited or if there is no other method (like a new whois flag) to directly request the abuse-mailbox field from the abuse-c Somebody at the RIPE NCC told me last week, that they intend to integrate the abuse-finder-tool (wich will surely return the abuse-mailbox-field from the abuse-c in a preferred manner) into whois with a new option, if the proposal gets through, but it should be clearer in the proposal, that its intention is, to receive the value of the abuse-mailbox field with simply one request. Kind regards, Frank > > The text of RIPE Policy Proposal 2011-06, "Abuse Contact Management in > the RIPE NCC Database", has been revised based on community feedback > received on the mailing list. > > We published the new version (version 2.0) today, 16 April. As a result, > a new Discussion Phase is set for the proposal. > > Changes in version 2.0 include: > > - Overall rewording > - Description of the use of "abuse-c:" and "abuse-mailbox:" on differing > RIPE Database objects > - Removal of references to a transition period > > You can find the full proposal at: > https://www.ripe.net/ripe/policies/proposals/2011-06 > > We encourage you to review this RIPE Policy Proposal and send your > comments to by 7 May 2012. > > Regards > > Marco Schmidt > on behalf of the Policy Development Office > RIPE NCC > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From leo.vegoda at icann.org Mon Apr 16 19:24:14 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 16 Apr 2012 10:24:14 -0700 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> Hi, Marco Schmidt wrote: [...] > Changes in version 2.0 include: > > - Overall rewording > - Description of the use of "abuse-c:" and "abuse-mailbox:" on differing > RIPE Database objects > - Removal of references to a transition period It is disappointing that this new proposal is still focused on a one-time process of adding additional contact information and does not address ongoing management of the published information. Until there is a policy requiring contact information to be regularly maintained, proposal 2011-06 is of limited value. Regards, Leo Vegoda From ripe-anti-spam-wg at powerweb.de Mon Apr 16 20:52:16 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 16 Apr 2012 20:52:16 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> Message-ID: <4F8C6A60.3060005@powerweb.de> Leo Vegoda wrote: > Hi, Hi, > Marco Schmidt wrote: > > [...] > >> Changes in version 2.0 include: >> >> - Overall rewording >> - Description of the use of "abuse-c:" and "abuse-mailbox:" on differing >> RIPE Database objects >> - Removal of references to a transition period > > It is disappointing that this new proposal is still focused on a one-time process of adding additional contact information and does not address ongoing management of the published information. Until there is a policy requiring contact information to be regularly maintained, proposal 2011-06 is of limited value. > Not at all, its good to seperate definitions and other procedures like management or validation of abuse contacts, if you remember how hard it is to achive consensus. Lets starts simple and lets add other parts later. I will be happy to prepare a validation draft, if the community wants it. Kind regards, Frank > Regards, > > Leo Vegoda > > > -- 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 ====================================================================== From leo.vegoda at icann.org Mon Apr 16 21:13:04 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 16 Apr 2012 12:13:04 -0700 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8C6A60.3060005@powerweb.de> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> Hi Frank, Frank wrote: > Leo Vegoda wrote: > > Marco Schmidt wrote: [...] > > It is disappointing that this new proposal is still focused on a one-time > > process of adding additional contact information and does not address > > ongoing management of the published information. Until there is a policy > > requiring contact information to be regularly maintained, proposal > > 2011-06 is of limited value. > > > Not at all, its good to seperate definitions and other procedures like > management or validation of abuse contacts, if you remember how hard > it is to achive consensus. > > Lets starts simple and lets add other parts later. > > I will be happy to prepare a validation draft, if the community > wants it. My issue is mainly with the way the proposals are ordered. Creating new requirements for types of contact data to be published before agreeing on a contact data management policy risks creating a situation where a new layer of contact information of questionable quality is added as a one-time only event. Unless you have a pre-existing contact data management policy you are just making the problem bigger and putting off the day when the mess has to be cleared up. Agreeing a way to manage contact data should be a prerequisite to the creation of new contact types. Regards, Leo Vegoda From michele at blacknight.ie Mon Apr 16 22:28:35 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Mon, 16 Apr 2012 20:28:35 +0000 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de>, <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> Message-ID: <4F2538C315ACAC42AD334C533C247C4726419139@bkexchmbx01.blacknight.local> If the policy does not include an obligation to maintain the abuse-c and keep it current then I can't see what purpose this serves and the problem that needs to be addressed will remain a problem. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From denis at ripe.net Mon Apr 16 23:12:54 2012 From: denis at ripe.net (Denis Walker) Date: Mon, 16 Apr 2012 23:12:54 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> Message-ID: <4F8C8B56.3080305@ripe.net> Hi Leo If you remember back to an earlier RIPE Meeting (some time ago) three policies were proposed including where to put the abuse data and how to validate it. These were withdrawn to allow a Task Force to look at the issues. The first policy from the Task Force is to have a single location in the RIPE Database to store abuse contact details. You can debate which should come first, a place to store the details or a means of validating/enforcing accuracy of the data. But what you have right now in the RIPE Database for abuse contacts is a mess. Many details are still stored in remarks. When we wrote the Abuse Finder tool we could not even find these contacts by scripting. The best we could offer is a pointer to where you might find something useful. If you can't reliably find the data you have little chance of validating it. The whole point of this proposal is to fix the abuse contact details in one easy to find place in the database, by humans and scripting. Far from putting off the day when the mess has to be cleared up, this is the first step in cleaning up the already existing mess. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 16/04/12:17 9:13 PM, Leo Vegoda wrote: > Hi Frank, > > Frank wrote: >> Leo Vegoda wrote: >>> Marco Schmidt wrote: > > [...] > >>> It is disappointing that this new proposal is still focused on a one-time >>> process of adding additional contact information and does not address >>> ongoing management of the published information. Until there is a policy >>> requiring contact information to be regularly maintained, proposal >>> 2011-06 is of limited value. >>> >> Not at all, its good to seperate definitions and other procedures like >> management or validation of abuse contacts, if you remember how hard >> it is to achive consensus. >> >> Lets starts simple and lets add other parts later. >> >> I will be happy to prepare a validation draft, if the community >> wants it. > > My issue is mainly with the way the proposals are ordered. Creating new requirements for types of contact data to be published before agreeing on a contact data management policy risks creating a situation where a new layer of contact information of questionable quality is added as a one-time only event. Unless you have a pre-existing contact data management policy you are just making the problem bigger and putting off the day when the mess has to be cleared up. > > Agreeing a way to manage contact data should be a prerequisite to the creation of new contact types. > > Regards, > > Leo Vegoda > > From leo.vegoda at icann.org Mon Apr 16 23:19:02 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 16 Apr 2012 14:19:02 -0700 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8C8B56.3080305@ripe.net> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> Hi Denis, I don't think I've seen anyone suggest that improving the structure is a bad thing to do. However, adding new structure before anyone has even had an opportunity to look at the proposals for maintaining the mandatory new data seems at least less than ideal. If this is part of a grand plan, it would be nice if the grand plan could be shared. Is there a reason for not sharing the big picture? Regards, Leo -----Original Message----- From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Denis Walker Sent: Monday 16 Apr 12 2:13 pm To: anti-abuse-wg at ripe.net Subject: Re: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) Hi Leo If you remember back to an earlier RIPE Meeting (some time ago) three policies were proposed including where to put the abuse data and how to validate it. These were withdrawn to allow a Task Force to look at the issues. The first policy from the Task Force is to have a single location in the RIPE Database to store abuse contact details. You can debate which should come first, a place to store the details or a means of validating/enforcing accuracy of the data. But what you have right now in the RIPE Database for abuse contacts is a mess. Many details are still stored in remarks. When we wrote the Abuse Finder tool we could not even find these contacts by scripting. The best we could offer is a pointer to where you might find something useful. If you can't reliably find the data you have little chance of validating it. The whole point of this proposal is to fix the abuse contact details in one easy to find place in the database, by humans and scripting. Far from putting off the day when the mess has to be cleared up, this is the first step in cleaning up the already existing mess. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 16/04/12:17 9:13 PM, Leo Vegoda wrote: > Hi Frank, > > Frank wrote: >> Leo Vegoda wrote: >>> Marco Schmidt wrote: > > [...] > >>> It is disappointing that this new proposal is still focused on a one-time >>> process of adding additional contact information and does not address >>> ongoing management of the published information. Until there is a policy >>> requiring contact information to be regularly maintained, proposal >>> 2011-06 is of limited value. >>> >> Not at all, its good to seperate definitions and other procedures like >> management or validation of abuse contacts, if you remember how hard >> it is to achive consensus. >> >> Lets starts simple and lets add other parts later. >> >> I will be happy to prepare a validation draft, if the community >> wants it. > > My issue is mainly with the way the proposals are ordered. Creating new requirements for types of contact data to be published before agreeing on a contact data management policy risks creating a situation where a new layer of contact information of questionable quality is added as a one-time only event. Unless you have a pre-existing contact data management policy you are just making the problem bigger and putting off the day when the mess has to be cleared up. > > Agreeing a way to manage contact data should be a prerequisite to the creation of new contact types. > > Regards, > > Leo Vegoda > > From denis at ripe.net Mon Apr 16 23:32:35 2012 From: denis at ripe.net (Denis Walker) Date: Mon, 16 Apr 2012 23:32:35 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> Message-ID: <4F8C8FF3.9000309@ripe.net> Hi Leo I am not aware of any formal big picture, but I follow the mailing list as closely as I am sure you and many others do. As you will know many of these issues invoke much discussion on the list. It might not be a bad idea to improve the structure and start working on cleaning up the existing mess. This cleanup in itself is going to take quite some time. During that time I am sure there will be much discussion on the next step(s) to further improve any bigger picture. Regards, Denis On 16/04/12:17 11:19 PM, Leo Vegoda wrote: > Hi Denis, > > I don't think I've seen anyone suggest that improving the structure is a bad thing to do. However, adding new structure before anyone has even had an opportunity to look at the proposals for maintaining the mandatory new data seems at least less than ideal. > > If this is part of a grand plan, it would be nice if the grand plan could be shared. > > Is there a reason for not sharing the big picture? > > Regards, > > Leo > > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Denis Walker > Sent: Monday 16 Apr 12 2:13 pm > To: anti-abuse-wg at ripe.net > Subject: Re: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) > > Hi Leo > > If you remember back to an earlier RIPE Meeting (some time ago) three > policies were proposed including where to put the abuse data and how to > validate it. These were withdrawn to allow a Task Force to look at the > issues. The first policy from the Task Force is to have a single > location in the RIPE Database to store abuse contact details. > > You can debate which should come first, a place to store the details or > a means of validating/enforcing accuracy of the data. But what you have > right now in the RIPE Database for abuse contacts is a mess. Many > details are still stored in remarks. When we wrote the Abuse Finder tool > we could not even find these contacts by scripting. The best we could > offer is a pointer to where you might find something useful. > > If you can't reliably find the data you have little chance of validating > it. The whole point of this proposal is to fix the abuse contact details > in one easy to find place in the database, by humans and scripting. Far > from putting off the day when the mess has to be cleared up, this is the > first step in cleaning up the already existing mess. > > Regards, > Denis Walker > Business Analyst > RIPE NCC Database Group > > On 16/04/12:17 9:13 PM, Leo Vegoda wrote: >> Hi Frank, >> >> Frank wrote: >>> Leo Vegoda wrote: >>>> Marco Schmidt wrote: >> >> [...] >> >>>> It is disappointing that this new proposal is still focused on a one-time >>>> process of adding additional contact information and does not address >>>> ongoing management of the published information. Until there is a policy >>>> requiring contact information to be regularly maintained, proposal >>>> 2011-06 is of limited value. >>>> >>> Not at all, its good to seperate definitions and other procedures like >>> management or validation of abuse contacts, if you remember how hard >>> it is to achive consensus. >>> >>> Lets starts simple and lets add other parts later. >>> >>> I will be happy to prepare a validation draft, if the community >>> wants it. >> >> My issue is mainly with the way the proposals are ordered. Creating new requirements for types of contact data to be published before agreeing on a contact data management policy risks creating a situation where a new layer of contact information of questionable quality is added as a one-time only event. Unless you have a pre-existing contact data management policy you are just making the problem bigger and putting off the day when the mess has to be cleared up. >> >> Agreeing a way to manage contact data should be a prerequisite to the creation of new contact types. >> >> Regards, >> >> Leo Vegoda >> >> > > > From leo.vegoda at icann.org Tue Apr 17 01:22:09 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 16 Apr 2012 16:22:09 -0700 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8C8FF3.9000309@ripe.net> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> Message-ID: Hi Denis, On Apr 16, 2012, at 2:32 pm, Denis Walker wrote: > I am not aware of any formal big picture, but I follow the mailing list > as closely as I am sure you and many others do. As you will know many of > these issues invoke much discussion on the list. I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary. Regards, Leo From ripe-anti-spam-wg at powerweb.de Tue Apr 17 08:04:32 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 17 Apr 2012 08:04:32 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> Message-ID: <4F8D07F0.9050901@powerweb.de> Leo Vegoda wrote: > Hi Denis, > > On Apr 16, 2012, at 2:32 pm, Denis Walker wrote: > >> I am not aware of any formal big picture, but I follow the mailing list >> as closely as I am sure you and many others do. As you will know many of >> these issues invoke much discussion on the list. > > I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary. > Remembering the discussions on various lists and infos I got from the NCC I would summarize the big picture like this (but maybe Tobias or Brian could do this much better): - introduction of the abuse-c - outlining a time schedule when the abuse-c HAS to be there (what would lead to an automatic cleanup of other fields and removal of remarks by the maintainers) - tools could be introduced for an easier migration (e.g. a function in the LIR portal, that could "remove all occurrences of my abuse-mailbox field with the value foo at bar.com with the abuse-c FOO-RIPE", another function could be "show me all my objects that include an email address in the remarks") - integration of the abuse finder tool into whois and other APIs (what would make other places unneeded and unused) - automatic technical validation (syntax, domain checks, MX and A record checks, check of mailserver availability either when the abuse-c is updated or repeating or both) with automatic reminders being sent to the maintainer - repeating validation via feedback links or similar - maybe a kind of automatic deletion of other places or fields Kind regards, Frank > Regards, > > 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 ====================================================================== From shane at time-travellers.org Tue Apr 17 09:39:21 2012 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 17 Apr 2012 09:39:21 +0200 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: <4F89E23D.7090600@powerweb.de> References: <4F896D94.9080502@gmx.net> <4F898497.8000306@powerweb.de> <20120414222332.0f63436b@shane-eeepc.home.time-travellers.org> <4F89E23D.7090600@powerweb.de> Message-ID: <20120417093921.350e52cb@shane-eeepc.home.time-travellers.org> Frank, On Saturday, 2012-04-14 22:46:53 +0200, Frank Gadegast wrote: > Im not talking about manual checks, those are automatic checks. > All checks I described are automatic checks, the last once > are only a bit more complicated to implement. Sure, I'm just saying that even manual checks are pretty cheap. But of course automated checks are really, really cheap. :) > > Personally I support both automated methods of checking contact > > So thats a +1 ? Yes, +1 to your proposal! -- Shane From P.Vissers at opta.nl Tue Apr 17 10:01:50 2012 From: P.Vissers at opta.nl (Vissers, Pepijn) Date: Tue, 17 Apr 2012 08:01:50 +0000 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: <20120417093921.350e52cb@shane-eeepc.home.time-travellers.org> References: <4F896D94.9080502@gmx.net> <4F898497.8000306@powerweb.de> <20120414222332.0f63436b@shane-eeepc.home.time-travellers.org> <4F89E23D.7090600@powerweb.de> <20120417093921.350e52cb@shane-eeepc.home.time-travellers.org> Message-ID: > > So thats a +1 ? > > Yes, +1 to your proposal! +1 added from me. Pepijn +++++++++++++++++++++++++++++++++++++++++++++ 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. From gilles.massen at restena.lu Tue Apr 17 09:53:53 2012 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 17 Apr 2012 09:53:53 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20120416133351.1300C294BDF@smtpgate1.restena.lu> References: <20120416133351.1300C294BDF@smtpgate1.restena.lu> Message-ID: <4F8D2191.6080003@restena.lu> Hello, > Changes in version 2.0 include: > > - Overall rewording > - Description of the use of "abuse-c:" and "abuse-mailbox:" on differing > RIPE Database objects > - Removal of references to a transition period What I still miss is a clear positioning of the IRT object vs. abuse-c. While these may not overlap completely, they certainly would to a large extend for a lot of CERTs, thus creating redundant data. So I'd join Leo on his comments that the use of the object should be clearer before creating it. If not the worst case might be that we end up with another randomly used object. Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From brian.nisbet at heanet.ie Tue Apr 17 10:09:52 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 17 Apr 2012 09:09:52 +0100 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> Message-ID: <4F8D2550.9010206@heanet.ie> Leo, Leo Vegoda wrote, On 17/04/2012 00:22: > Hi Denis, > > On Apr 16, 2012, at 2:32 pm, Denis Walker wrote: > >> I am not aware of any formal big picture, but I follow the mailing list >> as closely as I am sure you and many others do. As you will know many of >> these issues invoke much discussion on the list. > > I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary. While I think that Frank has given a good outline, what is "this" to your mind? Is it abuse contact management, is it data verification? Part of the problem that we hit with the ACM-TF is that data verification is a very big thing and people have a lot of reactions to it. This lead to a decision to try to get the abuse-c nailed down and integrated, before, should the community or TF decide, looking at data verification, and indeed the scope of that. I'll be honest, I don't see the 2011-06 and any data verification proposal as being that tightly integrated, but I'll accept not everyone shares my view of the world, so if you could expand on your fears, or why you feel it is so vital, that would be great. Thanks, Brian. From chrish at consol.net Tue Apr 17 10:35:57 2012 From: chrish at consol.net (chrish at consol.net) Date: Tue, 17 Apr 2012 10:35:57 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <201204161333.q3GDXskI028789@gw1.consol.de> References: <201204161333.q3GDXskI028789@gw1.consol.de> Message-ID: <4F8D2B6D.7010609@consol.net> hi! On 04/16/2012 03:24 PM, Marco Schmidt wrote: > We encourage you to review this RIPE Policy Proposal and send your > comments to by 7 May 2012. -1, unchanged. it's essentially unchanged, so the reasons as discussed on this ml are unchanged (doesn't simplify, doesn't help, just complicates, with foreseeable consecutive problems - it's a step backwards). regards, Chris From ops.lists at gmail.com Tue Apr 17 10:36:25 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 17 Apr 2012 14:06:25 +0530 Subject: [anti-abuse-wg] abuse email address validation - VOTE In-Reply-To: References: <4F896D94.9080502@gmx.net> <4F898497.8000306@powerweb.de> <20120414222332.0f63436b@shane-eeepc.home.time-travellers.org> <4F89E23D.7090600@powerweb.de> <20120417093921.350e52cb@shane-eeepc.home.time-travellers.org> Message-ID: +1 On Tue, Apr 17, 2012 at 1:31 PM, Vissers, Pepijn wrote: >> > So thats a +1 ? >> >> Yes, +1 to your proposal! > > +1 added from me. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ripe-anti-spam-wg at powerweb.de Tue Apr 17 10:48:22 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 17 Apr 2012 10:48:22 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D2550.9010206@heanet.ie> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> Message-ID: <4F8D2E56.5050002@powerweb.de> Brian Nisbet wrote: > Leo, Hi Brian, > Is it abuse contact management, is it data verification? Part of the > problem that we hit with the ACM-TF is that data verification is a very > big thing Well, technical is very easy, implementation of the test took only about 1 hours here, and you can test the email addresses from all objects at RIPE in (estimated) one day, so a weekly check is no problem at all. Does not even take high resources. > and people have a lot of reactions to it. Could you explain what problems you see here with reactions ? We did the following two days ago: - we checked all email addresses from inetnum objects from the RIPE region we did send an abuse report to during 2011/12 for syntax, domain, MX and A record and mailserver availability - about 50.000 different email addresses - took about 8 hours - nearly no extra CPU load on a quite old server that does at lot of other things - found 6% to be not valid (mostly because they simply changed) - re-read the inetnum objects via whois - validated them again The tests left us with about 1,5% of technical wrong contact addresses. This is NOT counting objects that have no email address at all (thats a different task, but surely will disappear when the abuse-c is in place). Do you think that the LIRs would complain, if the NCC asks the maintainer with an automatic email to updated his or her objects ? Cannot imagine it, because they DID supply an email address, its simply wrong (old, forgotten or typing mistake or deliberatly wrong). Well, we surely found some that are deliberatly wrong (funny things like xxx at xxx.xx), what just reminds me, that another test should be, if the TLD is valid ;o) Kind regards, Frank > > Thanks, > > Brian. > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From denis at ripe.net Tue Apr 17 11:00:23 2012 From: denis at ripe.net (Denis Walker) Date: Tue, 17 Apr 2012 11:00:23 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D2E56.5050002@powerweb.de> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de> Message-ID: <4F8D3127.1040104@ripe.net> On 17/04/12:17 10:48 AM, Frank Gadegast wrote: > > Do you think that the LIRs would complain, if the NCC asks > the maintainer with an automatic email to updated his or her objects ? > Cannot imagine it, because they DID supply an email address, > its simply wrong (old, forgotten or typing mistake or > deliberatly wrong). > > Here in lays another problem....you are assuming now that all maintainers email addresses are valid. We will present some stats on these in the DB WG presentation later this week. Here we are talking much more than 1.5% problems. I think this is one of the points Brian means. The issue of user data accuracy is wider than just for abuse reporting. regards Denis Walker Business Analyst RIPE NCC Database Group From ripe-anti-spam-wg at powerweb.de Tue Apr 17 11:04:14 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 17 Apr 2012 11:04:14 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D2B6D.7010609@consol.net> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> Message-ID: <4F8D320E.8060502@powerweb.de> chrish at consol.net wrote: > hi! > > On 04/16/2012 03:24 PM, Marco Schmidt wrote: >> We encourage you to review this RIPE Policy Proposal and send your >> comments to by 7 May 2012. > > -1, unchanged. it's essentially unchanged, so the reasons as discussed on this ml are unchanged ( > doesn't simplify - the abuse-c will remove all other appearances of abuse contact information - whois will return this one email address without any query limits - makes the maintenance of objects more easy, because you have to maintain only one contact instead of editing all your objects remark fields I would call this simplification. > doesn't help, - it helps every one to find the right contact more easily manually and even helps people to find it for automatic reporting I would call it very helpfull. > just complicates, A double negation of an argument is no new argument ;o) > with foreseeable consecutive problems Wich ones do you see ? Could you please summarize your doubts ? The abuse-c will even raise the data quality because it can be validated in future checks. It will also raise the quality because it will remind the LIRs to update their objects, when things are changing. Kind regards, Frank > - it's a step backwards). > > regards, > > Chris -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From michele at blacknight.ie Tue Apr 17 11:04:57 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Tue, 17 Apr 2012 09:04:57 +0000 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D3127.1040104@ripe.net> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de>,<4F8D3127.1040104@ripe.net> Message-ID: <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> Denis I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received? Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ops.lists at gmail.com Tue Apr 17 11:07:34 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 17 Apr 2012 14:37:34 +0530 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de> <4F8D3127.1040104@ripe.net> <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> Message-ID: On Tue, Apr 17, 2012 at 2:34 PM, Michele Neylon :: Blacknight wrote: > I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received? Or does it work the way it does in webhosting abuse? Use a prepaid card and register an AS and its /15 as "mickey mouse, care of euro disney"? [or better still, as j random llc, care of a maildrop at a tobacconist in paddington] -- Suresh Ramasubramanian (ops.lists at gmail.com) From michele at blacknight.ie Tue Apr 17 11:09:43 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Tue, 17 Apr 2012 09:09:43 +0000 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D2550.9010206@heanet.ie> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> Message-ID: <0474CACB-E950-4BCD-9FFC-1F97BE2CE3E9@blacknight.ie> Brian One of my fears is that if you introduce an abuse-c without any obligation to maintain then RIPE will be the target for a lot of criticism Regards Michele On 17 Apr 2012, at 09:09, Brian Nisbet wrote: > Leo, > > Leo Vegoda wrote, On 17/04/2012 00:22: >> Hi Denis, >> >> On Apr 16, 2012, at 2:32 pm, Denis Walker wrote: >> >>> I am not aware of any formal big picture, but I follow the mailing list >>> as closely as I am sure you and many others do. As you will know many of >>> these issues invoke much discussion on the list. >> >> I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary. > > While I think that Frank has given a good outline, what is "this" to your mind? > > Is it abuse contact management, is it data verification? Part of the problem that we hit with the ACM-TF is that data verification is a very big thing and people have a lot of reactions to it. This lead to a decision to try to get the abuse-c nailed down and integrated, before, should the community or TF decide, looking at data verification, and indeed the scope of that. > > I'll be honest, I don't see the 2011-06 and any data verification proposal as being that tightly integrated, but I'll accept not everyone shares my view of the world, so if you could expand on your fears, or why you feel it is so vital, that would be great. > > Thanks, > > Brian. > 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 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 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 ripe-anti-spam-wg at powerweb.de Tue Apr 17 11:13:54 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 17 Apr 2012 11:13:54 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de>, <4F8D3127.1040104@ripe.net> <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> Message-ID: <4F8D3452.5040100@powerweb.de> Michele Neylon :: Blacknight wrote: > Denis > Hi, > I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received? RIPE NCC told me, that they have other (more contract related) email address on file that have nothing todo with email addresses from objects. Real internal data ... So, if the maintainer email address isnt valid or bounces, use those ... Kind regards, Frank > > Regards > > Michele > -- > Mr Michele Neylon > Blacknight Solutions > Hosting& Colocation, Brand Protection > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://mneylon.tel/ > Intl. +353 (0) 59 9183072 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From brian.nisbet at heanet.ie Tue Apr 17 11:20:42 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 17 Apr 2012 10:20:42 +0100 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <0474CACB-E950-4BCD-9FFC-1F97BE2CE3E9@blacknight.ie> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <0474CACB-E950-4BCD-9FFC-1F97BE2CE3E9@blacknight.ie> Message-ID: <4F8D35EA.4010704@heanet.ie> Michele Neylon :: Blacknight wrote, On 17/04/2012 10:09: > Brian > > One of my fears is that if you introduce an abuse-c without any obligation to maintain then RIPE will be the target for a lot of criticism To clarify, the abuse-c as proposed will be mandatory for all aut-nums. If this proposal moves forward, the RIPE NCC will undertake an impact analysis and that will facilitate a conversation around transition. Also, the NCC do audit LIRs, although not every LIR is audited each year. So this proposal does not introduce abuse-c without obligation. It does not introduce further data verification requirements (for abuse or anything else) over and above what is currently in place for the database. I do believe that this proposal will help and I think that not attempting to improve abuse contact data until a full data verification infrastructure is in place, will mean that we won't solve a lot of the problems that this proposal hopes to address for a very long time. It's quite possible there isn't a perfect order of how to do these things, but I think it would be a shame if this proposal was defeated because it didn't do everything or because the environment wasn't perfect. Other opinions may differ. Brian. From michele at blacknight.ie Tue Apr 17 11:21:04 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Tue, 17 Apr 2012 09:21:04 +0000 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de> <4F8D3127.1040104@ripe.net> <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> Message-ID: Suresh I'm not sure what your last email is about. Are you trying to be amusing? Or are you trying to take potshots at me or at RIPE? In either case I don't see it as being particularly helpful for anyone Regards Michele On 17 Apr 2012, at 10:07, Suresh Ramasubramanian wrote: > On Tue, Apr 17, 2012 at 2:34 PM, Michele Neylon :: Blacknight > wrote: >> I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received? > > Or does it work the way it does in webhosting abuse? Use a prepaid > card and register an AS and its /15 as "mickey mouse, care of euro > disney"? > > [or better still, as j random llc, care of a maildrop at a tobacconist > in paddington] > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) 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 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 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 ops.lists at gmail.com Tue Apr 17 11:27:05 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 17 Apr 2012 14:57:05 +0530 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de> <4F8D3127.1040104@ripe.net> <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> Message-ID: Not at all. Trying to find a vector through which this can be abused. If you thought that was an insult or a potshot, please be assured that's not my intent. On Tue, Apr 17, 2012 at 2:51 PM, Michele Neylon :: Blacknight wrote: > Suresh > > I'm not sure what your last email is about. > > Are you trying to be amusing? Or are you trying to take potshots at me or at RIPE? > > In either case I don't see it as being particularly helpful for anyone > > Regards > > Michele > > > On 17 Apr 2012, at 10:07, Suresh Ramasubramanian wrote: > >> On Tue, Apr 17, 2012 at 2:34 PM, Michele Neylon :: Blacknight >> wrote: >>> I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received? >> >> Or does it work the way it does in webhosting abuse? ?Use a prepaid >> card and register an AS and its /15 as "mickey mouse, care of euro >> disney"? >> >> [or better still, as j random llc, care of a maildrop at a tobacconist >> in paddington] >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) > > 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 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > 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 > -- Suresh Ramasubramanian (ops.lists at gmail.com) From chrish at consol.net Tue Apr 17 11:33:36 2012 From: chrish at consol.net (Chris) Date: Tue, 17 Apr 2012 11:33:36 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D320E.8060502@powerweb.de> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> Message-ID: <4F8D38F0.9020203@consol.net> On 04/17/2012 11:04 AM, Frank Gadegast wrote: > - the abuse-c will remove all other appearances of abuse contact nah, won't. but we had that (you can find it in the ml archive if you lost it) regards, Chris From denis at ripe.net Tue Apr 17 11:42:42 2012 From: denis at ripe.net (Denis Walker) Date: Tue, 17 Apr 2012 11:42:42 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de>, <4F8D3127.1040104@ripe.net> <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> Message-ID: <4F8D3B12.9040806@ripe.net> On 17/04/12:17 11:04 AM, Michele Neylon :: Blacknight wrote: > Denis > > I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received? You are assuming that all data in the RIPE Database is either maintained by the RIPE NCC (registry data) or by members. This is not the case. A member can, for example, make a sub-allocation to another organisation that the RIPE NCC has no contract with and probably no direct email contact with. That sub-allocation can be further sub-allocated and then there may be assignments made where the assignment holder has the mnt-by authority over the assignment. However many layers, there is of course a chain of authority leading back to the LIR who has responsibility for their allocated address space. But it is not always as simple as the RIPE NCC emails a member and asks them to 'fix it'. Regards Denis Walker Business Analyst RIPE NCC Database Group > > Regards > > Michele > -- > Mr Michele Neylon > Blacknight Solutions > Hosting & Colocation, Brand Protection > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://mneylon.tel/ > Intl. +353 (0) 59 9183072 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > 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 Tue Apr 17 11:46:51 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 17 Apr 2012 11:46:51 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D38F0.9020203@consol.net> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D38F0.9020203@consol.net> Message-ID: <4F8D3C0B.10706@abusix.com> On 17.04.12 11:33, Chris wrote: > On 04/17/2012 11:04 AM, Frank Gadegast wrote: >> - the abuse-c will remove all other appearances of abuse contact > > nah, won't. > > but we had that (you can find it in the ml archive if you lost it) It will remove redundant information from the whois and abuse finder output. It will not remove remarks and other free text abuse information from the database, but it will make it obsolete. The cleanup process will probably not work in a short term, but it can be fastened by a following data accuracy proposal. But that is another piece. Is there any other concerns or any ideas from your side? 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 gilles.massen at restena.lu Tue Apr 17 11:55:34 2012 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 17 Apr 2012 11:55:34 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D320E.8060502@powerweb.de> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> Message-ID: <4F8D3E16.1050007@restena.lu> On 04/17/2012 11:04 AM, Frank Gadegast wrote: > - the abuse-c will remove all other appearances of abuse contact > information If that is true, then please have it say so in the proposal. Currently I worry about the IRT object which is my view more valuable (as in 'complete') than the abuse-c. And the requirement could well be 'have either one (XOR preferred over OR for data consistency) for each inetnum'. But it really needs to be defined (and/or discussed) beforehand. Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From chrish at consol.net Tue Apr 17 11:57:12 2012 From: chrish at consol.net (Chris) Date: Tue, 17 Apr 2012 11:57:12 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D3C0B.10706@abusix.com> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D38F0.9020203@consol.net> <4F8D3C0B.10706@abusix.com> Message-ID: <4F8D3E78.20402@consol.net> On 04/17/2012 11:46 AM, Tobias Knecht wrote: [...] folks, just read what i already wrote. as i said, essentially nothing has changed. there's no point in going thru all this again. it's all there already. if you lost it, there's the archive (hint: 20111207). follow-ups welcome (i.e. questions that haven't already been answered). regards, Chris From shane at time-travellers.org Tue Apr 17 12:03:04 2012 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 17 Apr 2012 12:03:04 +0200 Subject: [anti-abuse-wg] Some (old) numbers about the quality of contact information, was 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D3127.1040104@ripe.net> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de> <4F8D3127.1040104@ripe.net> Message-ID: <20120417120304.6e8911ad@shane-eeepc.home.time-travellers.org> All, On Tuesday, 2012-04-17 11:00:23 +0200, Denis Walker wrote: > > On 17/04/12:17 10:48 AM, Frank Gadegast wrote: > > > > Do you think that the LIRs would complain, if the NCC asks > > the maintainer with an automatic email to updated his or her > > objects ? Cannot imagine it, because they DID supply an email > > address, its simply wrong (old, forgotten or typing mistake or > > deliberatly wrong). > > > > > Here in lays another problem....you are assuming now that all > maintainers email addresses are valid. We will present some stats on > these in the DB WG presentation later this week. Here we are talking > much more than 1.5% problems. For historical context, here's a presentation I did in a while ago: http://meetings.ripe.net/ripe-45/presentations/ripe45-db-contact-data.ppt I have no idea if quality of contact data has gotten better or worse in the last 9 years. :) -- Shane -- Shane From ripe-anti-spam-wg at powerweb.de Tue Apr 17 12:03:55 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 17 Apr 2012 12:03:55 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D3E78.20402@consol.net> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D38F0.9020203@consol.net> <4F8D3C0B.10706@abusix.com> <4F8D3E78.20402@consol.net> Message-ID: <4F8D400B.8020302@powerweb.de> Chris wrote: > On 04/17/2012 11:46 AM, Tobias Knecht wrote: > [...] > > folks, just read what i already wrote. > as i said, essentially nothing has changed. there's no point in going thru all this again. it's all there already. if you lost it, there's the archive (hint: 20111207). > follow-ups welcome (i.e. questions that haven't already been answered). Read through it again and still think: you are wrong (as explained again in a private mail to you). Its as simple as Tobias just sayd, but maybe it would be nice to outline this in the proposal a bit more ... > regards, > > Chris -- Kind regards, Frank -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From tk at abusix.com Tue Apr 17 14:42:33 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 17 Apr 2012 14:42:33 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D3E78.20402@consol.net> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D38F0.9020203@consol.net> <4F8D3C0B.10706@abusix.com> <4F8D3E78.20402@consol.net> Message-ID: <4F8D6539.6050902@abusix.com> On 17.04.12 11:57, Chris wrote: > On 04/17/2012 11:46 AM, Tobias Knecht wrote: [...] > > folks, just read what i already wrote. as i said, essentially nothing > has changed. there's no point in going thru all this again. it's all > there already. if you lost it, there's the archive (hint: 20111207). > follow-ups welcome (i.e. questions that haven't already been > answered). As far as I can see you had 3 main issues with the proposal that time. First was the implementation, which we left out completely this time to concentrate on the main issue of "one" specific abuse contact. As stated in the proposal the implementation will be discussed later after RIPE NCC has done an implementation plan. Second was, that you haven't seen a positive effect because you say that things will stay in the database and we just add another object that makes things more complex. That is in fact only partly true. There is no automatic way of deleting remark fields with abuse contact (freeform in a DB is nearly always a mess). From that perspective we have to wait until maintainers are changing their information. But the remark fields will get obsolete, because there will be an abuse-c in place. So there is already a point that get's less complex and this will be the way people can find abuse contact information. And not only people, RIPE NCCs Abuse Findertool will be able to parse them as well, what is not possible at the moment. The other side, when we are talking about abuse-mailbox attributes. We will not get rid of them, but this proposal will led into a situation where the abuse-mailbox attribute is only shown on whois and other outputs if it is related to an abuse-c. That makes the output again less complex, because there is only "one" abuse-mailbox attribute in a whois output and not 3 with different addresses. In addition to that we have a clear differentiation between personal data and role accounts, which can be communicated by the RIPE NCC when the object will be published. So I can not see any increase of complexity as I couldn't see it in December 2011. The third issue you had, was bulk spamming. I can see it and I can understand this issue. Nevertheless I have to say, that there are already techniques that can solve this problem and would also solve the problem you have at the moment with bulk spamming. So this is not a new problem at all, it is already a problem that needs to be fixed. Besides the implementation, which will come from RIPE NCC and can be discussed further in a later step I see less complexity and operational overhead for resource holders as well. I haven't seen most of your points in late 2011 and I do not see all of them now. Maybe I'm just coming from another corner. Since Community agreed on setting up a Task Force and work on this issue and try to fix the mess in the Database which is as well recognized by RIPE NCC staff with this word "mess" there must be something true about it. Even if it is only something little. So the question is not only what you do not like about the proposal, it's more about how can we fix it. And you haven't come up with ideas about a solution in December. So maybe you have ideas know and want to share them. 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 tk at abusix.com Tue Apr 17 15:25:15 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 17 Apr 2012 15:25:15 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D3B12.9040806@ripe.net> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de>, <4F8D3127.1040104@ripe.net> <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> <4F8D3B12.9040806@ripe.net> Message-ID: <4F8D6F3B.5030005@abusix.com> On 17.04.12 11:42, Denis Walker wrote: > On 17/04/12:17 11:04 AM, Michele Neylon :: Blacknight wrote: >> Denis >> >> I assume RIPE is able to get paid by all members, so it must have >> some valid contact details or no bills would be sent or money >> received? > > You are assuming that all data in the RIPE Database is either > maintained by the RIPE NCC (registry data) or by members. This is not > the case. A member can, for example, make a sub-allocation to another > organisation that the RIPE NCC has no contract with and probably no > direct email contact with. That sub-allocation can be further > sub-allocated and then there may be assignments made where the > assignment holder has the mnt-by authority over the assignment. > However many layers, there is of course a chain of authority leading > back to the LIR who has responsibility for their allocated address > space. But it is not always as simple as the RIPE NCC emails a member > and asks them to 'fix it'. I think we should look for a solution that covers the chain of authority. Maybe a first step can be to cover the maintainers email addresses and go from there. As soon as we have the maintainers we could cover everything beyond and notify maintainers if something is going wrong within their reliability. This should also cover the mechanisms that will be used for checking. For example I think it is absolutely okay to send verification mails to the maintainers, but I'm not sure we should use a verification process on all the email addresses. This could first of all lead into legal issues and end up in accusing RIPE NCC as spammers when people with no direct legal connection to RIPE NCC receiving "spam" and need to verify their email address. 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 ripe-anti-spam-wg at powerweb.de Tue Apr 17 15:50:56 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 17 Apr 2012 15:50:56 +0200 Subject: [anti-abuse-wg] abuse email address validation In-Reply-To: <4F8D6F3B.5030005@abusix.com> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> <4F8D2550.9010206@heanet.ie> <4F8D2E56.5050002@powerweb.de>, <4F8D3127.1040104@ripe.net> <4F2538C315ACAC42AD334C533C247C472641B0A3@bkexchmbx01.blacknight.local> <4F8D3B12.9040806@ripe.net> <4F8D6F3B.5030005@abusix.com> Message-ID: <4F8D7540.8090706@powerweb.de> Tobias Knecht wrote: > > I think we should look for a solution that covers the chain of > authority. Maybe a first step can be to cover the maintainers email > addresses and go from there. As soon as we have the maintainers we could > cover everything beyond and notify maintainers if something is going > wrong within their reliability. RIPE NCC has even other addresses they could use, not only the maintainer. > This should also cover the mechanisms that will be used for checking. > For example I think it is absolutely okay to send verification mails to > the maintainers, Right. The LIR will have a problem, if they do not work, and even if they do not work, the NCC could mail the (internally known) customer email address and tell them, that the maintainer does not work. > but I'm not sure we should use a verification process > on all the email addresses. This could first of all lead into legal > issues and end up in accusing RIPE NCC as spammers when people with no You cannot spam an email address, that is not working ;o) Remember: Im currently not talking about regular email checks, first there should be syntax, TLD, domain, MX or A record and availability of the mailserver checked, these could by easily reported to the maintainer or if that fails to the LIR. But thats interesting. Does anybody think, that an object maintainer will interpret an email coming from the NCC as spam, when it tells him, that his object is wrong ? If thats true, RIPE should really only mail the LIR directly. On the other hand: Could somebody please point out, if there is any contractual rule between RIPE and the LIR pushing the LIR to insert only correct data in the database ? If there is such a paragraph somewhere, it must be true, that the LIR has the same rule with his own customers and the chain should go down to every maintainer and even the last email address, "spam" should be no problem then. > direct legal connection to RIPE NCC receiving "spam" and need to verify > their email address. Verification should be discussed later, after its clear what the community thinks about validation. Kind regards, Frank > > Thanks, > > Tobias > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From leo.vegoda at icann.org Tue Apr 17 16:59:43 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 17 Apr 2012 07:59:43 -0700 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D2550.9010206@heanet.ie> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780E25@EXVPMBX100-1.exc.icann.org> <4F8C8FF3.9000309@ripe.net> , <4F8D2550.9010206@heanet.ie> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184AD779BD32@EXVPMBX100-1.exc.icann.org> Hi Brian, all, Brian Nisbet wrote: > Leo Vegoda wrote, On 17/04/2012 00:22: > > Hi Denis, > > > > On Apr 16, 2012, at 2:32 pm, Denis Walker wrote: > > > >> I am not aware of any formal big picture, but I follow the mailing list > >> as closely as I am sure you and many others do. As you will know many of > >> these issues invoke much discussion on the list. > > > > I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary. > > While I think that Frank has given a good outline, what is "this" to > your mind? > > Is it abuse contact management, is it data verification? Part of the > problem that we hit with the ACM-TF is that data verification is a very > big thing and people have a lot of reactions to it. This lead to a > decision to try to get the abuse-c nailed down and integrated, before, > should the community or TF decide, looking at data verification, and > indeed the scope of that. I think my concerns are that if we have a large problem and solve it in pieces, because the work is done in pieces they might not tessellate well and leave us with something that is a bit broken. In particular, I am concerned that if a proposal for a new abuse-c object is approved but no contact data management policy is approved we just have a new layer of stale data. In general, I think more stale data is worse than less stale data. On the other hand, I can see that discussing multiple policy proposals simultaneously is difficult. I think my concerns would be allayed if the resulting policies (once approved) were implemented as part of a single, coherent programme of work and not as individual projects. That way, I think we could be fairly sure all the pieces fit well together. Regards, Leo From caldcv at gmail.com Wed Apr 18 21:54:54 2012 From: caldcv at gmail.com (Chris) Date: Wed, 18 Apr 2012 15:54:54 -0400 Subject: [anti-abuse-wg] Lack of contact from ORG-LA16-RIPE regarding spam / 46.109.195.227 Message-ID: 46.109.195.227 is a well known, abusive IP address that is likely an open proxy used to send out spam messages on Wordpress. I have contacted abuse at lattelecom.lv numerous times and this IP address continues to be abusive. Nameservers for the domain are from Hostkey - RIPE-ERX-141 / AS49335 Domain is xrumerservice.org, which should not be difficult to find online. Anyone care to instruct me how RIPE handles abuse differently than ARIN because this guy is getting pretty annoying when I have 50+ blogs getting 5 messages each from him and if you think Akismet / anti spam plugins are the solution, it has made the problem this much worse and encourages "fast flux" use of IP address, such as with cloud hosting services, to temporarily abuse an IP address and dump it before it gets traditionally blacklisted. -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From brian.nisbet at heanet.ie Thu Apr 19 09:08:46 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 19 Apr 2012 08:08:46 +0100 Subject: [anti-abuse-wg] Lack of contact from ORG-LA16-RIPE regarding spam / 46.109.195.227 In-Reply-To: References: Message-ID: <4F8FB9FE.3050405@heanet.ie> Chris, Chris wrote, On 18/04/2012 20:54: > > Anyone care to instruct me how RIPE handles abuse differently than > ARIN because this guy is getting pretty annoying when I have 50+ blogs > getting 5 messages each from him and if you think Akismet / anti spam > plugins are the solution, it has made the problem this much worse and > encourages "fast flux" use of IP address, such as with cloud hosting > services, to temporarily abuse an IP address and dump it before it > gets traditionally blacklisted. The information on how to deal with alleged abusive behaviour by RIPE NCC members or resources in the RIPE DB is here: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming and here: http://www.ripe.net/contact/reporting-procedure Hopefully this helps? Brian. Although From james.davis at ja.net Thu Apr 19 10:44:01 2012 From: james.davis at ja.net (James Davis) Date: Thu, 19 Apr 2012 09:44:01 +0100 Subject: [anti-abuse-wg] Lack of contact from ORG-LA16-RIPE regarding spam / 46.109.195.227 In-Reply-To: References: Message-ID: <4F8FD051.20604@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18/04/2012 20:54, Chris wrote: > 46.109.195.227 is a well known, abusive IP address that is likely > an open proxy used to send out spam messages on Wordpress. I have > contacted abuse at lattelecom.lv numerous times and this IP address > continues to be abusive. Have you tried to contact CERT.LV? about this? I've not actually passed any incidents their way before but have met with them on several occasions and I understand that they have close links with telecoms providers within Latvia. Please feel free to let me know if there's something I can do to help or introduce you to them. Regards, 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/ iF4EAREIAAYFAk+P0FEACgkQjsS2Y6D6yLyxCwEAkqybZdlx2oJ/MwzJkW+T1MiV UCX3vo56XP7PIspEE+IBAOO18zkAsKZEHSmoKx32uNtuU04msSj1/WwIVEc7CxJ+ =ayC8 -----END PGP SIGNATURE----- Janet 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 Apr 19 15:04:32 2012 From: tk at abusix.com (Tobias Knecht) Date: Thu, 19 Apr 2012 15:04:32 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8D3E16.1050007@restena.lu> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D3E16.1050007@restena.lu> Message-ID: <4F900D60.8080101@abusix.com> On 17.04.12 11:55, Gilles Massen wrote: > > > On 04/17/2012 11:04 AM, Frank Gadegast wrote: > >> - the abuse-c will remove all other appearances of abuse contact >> information > > If that is true, then please have it say so in the proposal. Currently I > worry about the IRT object which is my view more valuable (as in > 'complete') than the abuse-c. And the requirement could well be 'have > either one (XOR preferred over OR for data consistency) for each inetnum'. > > But it really needs to be defined (and/or discussed) beforehand. First of all thanks for your input and sorry for my delayed answer. I wanted to check with some people here at RIPE 64 about this. I would not tackle the IRT Object in any way with this policy proposal, because imho the IRT object is more used by Certs and not really used by Abuse Departments. The first version of this proposal was going into your direction and was suggesting to use the IRT Object as place for the abuse contact information as well, but in the Task Force we decided that this might be not the right place, for the mentioned reasons. There might be the idea of renaming the mnt-irt into irt-c just to make it more clear, that it is a contact, but this is something we can come up in the RIPE NCC impact analysis. I think we should wait and see how the IRT Object will be handled after this proposal is in place and may be there can be a decision about keeping the IRT Object in place or not, or maybe even changing it to it's origin idea. But I would not like to have this decision in this proposal since it is a different discussion. Hope that helps and thanks again for your input. 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 ripe-wg-antiabuse at kyubu.de Thu Apr 19 17:37:59 2012 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 19 Apr 2012 15:37:59 +0000 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F900D60.8080101@abusix.com> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D3E16.1050007@restena.lu> <4F900D60.8080101@abusix.com> Message-ID: <20120419153759.GA21199@core.kyubu.de> On Thu, Apr 19, 2012 at 03:04:32PM +0200, Tobias Knecht wrote: Tobias, > I think we should wait and see how the IRT Object will be handled after > this proposal is in place and may be there can be a decision about > keeping the IRT Object in place or not, or maybe even changing it to > it's origin idea. Are the folks using IRT Objects at a larger scale (e.G. TI) included in this discussion? Cheers, Adrian From james.davis at ja.net Thu Apr 19 17:45:47 2012 From: james.davis at ja.net (James Davis) Date: Thu, 19 Apr 2012 16:45:47 +0100 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20120419153759.GA21199@core.kyubu.de> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D3E16.1050007@restena.lu> <4F900D60.8080101@abusix.com> <20120419153759.GA21199@core.kyubu.de> Message-ID: <4F90332B.3080400@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 19/04/2012 16:37, Adrian wrote: > Are the folks using IRT Objects at a larger scale (e.G. TI) > included in this discussion? I've never seen an IRT object that wasn't created through the TI community. I'll send TI an e-mail to make them aware of this thread. 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/ iF4EAREIAAYFAk+QMysACgkQjsS2Y6D6yLyhxAD+Ozqv9fJSlwQuOTpoEHKSj/m+ yA0fePy292Rtcr1ScmwBAIQnFto9DmgEL7LptNlVVeuHXJApAs0R7elGizzvJ+sS =HMkn -----END PGP SIGNATURE----- Janet 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 Apr 19 17:58:52 2012 From: tk at abusix.com (Tobias Knecht) Date: Thu, 19 Apr 2012 17:58:52 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20120419153759.GA21199@core.kyubu.de> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D3E16.1050007@restena.lu> <4F900D60.8080101@abusix.com> <20120419153759.GA21199@core.kyubu.de> Message-ID: <4F90363C.6010600@abusix.com> On 19.04.12 17:37, Adrian wrote: > On Thu, Apr 19, 2012 at 03:04:32PM +0200, Tobias Knecht wrote: > > Tobias, > >> I think we should wait and see how the IRT Object will be handled after >> this proposal is in place and may be there can be a decision about >> keeping the IRT Object in place or not, or maybe even changing it to >> it's origin idea. > > Are the folks using IRT Objects at a larger scale (e.G. TI) included in this discussion? They are not directly included by us into the discussion, but they are of course welcome to take part in this discussion. But please keep in mind that 2011-06 is not about the IRT Object. The things I mentioned can and will be part of another discussion, maybe another proposal. And the renaming of the mnt-irt into irt-c is not essential for this proposal. I was just mentioning it, because this was talked about in the Task Force and could show up in the RIPE NCC implementation suggestion. 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 tk at abusix.com Thu Apr 19 18:01:12 2012 From: tk at abusix.com (Tobias Knecht) Date: Thu, 19 Apr 2012 18:01:12 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F90332B.3080400@ja.net> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D3E16.1050007@restena.lu> <4F900D60.8080101@abusix.com> <20120419153759.GA21199@core.kyubu.de> <4F90332B.3080400@ja.net> Message-ID: <4F9036C8.2060700@abusix.com> On 19.04.12 17:45, James Davis wrote: > On 19/04/2012 16:37, Adrian wrote: > >> Are the folks using IRT Objects at a larger scale (e.G. TI) >> included in this discussion? > > I've never seen an IRT object that wasn't created through the TI > community. I'll send TI an e-mail to make them aware of this thread. Yes please. I will try to figure out how many IRT Objects are in the database and how much percent of the IP space they cover, just to get an idea about what numbers we are talking. 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 fw at deneb.enyo.de Thu Apr 19 21:25:42 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 19 Apr 2012 21:25:42 +0200 Subject: [anti-abuse-wg] Lack of contact from ORG-LA16-RIPE regarding spam / 46.109.195.227 In-Reply-To: (Chris's message of "Wed, 18 Apr 2012 15:54:54 -0400") References: Message-ID: <878vhrr0ax.fsf@mid.deneb.enyo.de> * Chris: > 46.109.195.227 is a well known, abusive IP address that is likely an > open proxy used to send out spam messages on Wordpress. I have > contacted abuse at lattelecom.lv numerous times and this IP address > continues to be abusive. Isn't this a case for the IPRAs? 46.109.195.227 lies with an unassigned range, it's only allocated. From caldcv at gmail.com Sat Apr 21 01:03:14 2012 From: caldcv at gmail.com (Chris) Date: Fri, 20 Apr 2012 19:03:14 -0400 Subject: [anti-abuse-wg] Lack of contact from ORG-LA16-RIPE regarding spam / 46.109.195.227 In-Reply-To: <878vhrr0ax.fsf@mid.deneb.enyo.de> References: <878vhrr0ax.fsf@mid.deneb.enyo.de> Message-ID: Thanks for all the replies. I have contacted CERT. As for blocking IP addresses, not a wise solution and blacklisting/blocking has got us to where we are right now. From tk at abusix.com Sun Apr 22 14:51:59 2012 From: tk at abusix.com (Tobias Knecht) Date: Sun, 22 Apr 2012 14:51:59 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F90332B.3080400@ja.net> References: <201204161333.q3GDXskI028789@gw1.consol.de> <4F8D2B6D.7010609@consol.net> <4F8D320E.8060502@powerweb.de> <4F8D3E16.1050007@restena.lu> <4F900D60.8080101@abusix.com> <20120419153759.GA21199@core.kyubu.de> <4F90332B.3080400@ja.net> Message-ID: <4F93FEEF.4060503@abusix.com> Hello, as promised I asked RIPE NCC staff to provide some stats on IRTs. Thanks for answering that fast. I got the following stats. At the moment there 276 IRT Objects in the DB. The address space covered by these IRT Objects in not trivial to calculate so I do not have numbers on that. But we have stats that are about 4 years old, which tell us that there have been 121 IRT Objects in the DB. These 121 IRT Objects covered 1,7% of the address space that time. That means we have an increase of IRT Objects of approximately 40 per year over the last 4 years. If the coverage factor is still the same we should end up at approximately 3,8 or let's say 4 or even 5% of the address space. Knowing these numbers makes it in my opinion even more clear, that the IRT Object is not a widely used object and there is a lot of space for improvement. How ever this improvement looks like. That's why I would like to wait for an implementation of the abuse-c if we find consensus on that and look at the numbers of the IRT Objects again and start making decisions on what should happen with it. From my perspective at the moment there is everything possible. Discontinuing, changing it or letting it as it is. But that will be a community discussion and decision at that time. Thanks, Tobias On 19.04.12 17:45, James Davis wrote: > On 19/04/2012 16:37, Adrian wrote: > >> Are the folks using IRT Objects at a larger scale (e.G. TI) >> included in this discussion? > > I've never seen an IRT object that wasn't created through the TI > community. I'll send TI an e-mail to make them aware of this thread. > > James > > > Janet 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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ops.lists at gmail.com Sun Apr 22 17:24:53 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 22 Apr 2012 20:54:53 +0530 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first Message-ID: Like this for example - yes, not a formally defined abuse contact field, but they are so insistent that they should only receive spam reports at abuse at chello.pl Unfortunately - that address doesn't exist. If someone from Chello could please contact me about nigerians who keep abusing what is likely an open proxy at 89.70.30.128 I'd be obliged --srs (postmaster at lotuslive.com / AS27477 IBM Lotuslive) abuse at chello.pl SMTP error from remote mail server after RCPT TO:: host smtp.upcpoczta.pl [213.46.255.2]: 550 5.1.1 unknown recipient rejected route: 89.70.0.0/16 descr: UPC.pl origin: AS9141 remarks: Any abuse activities including, but not limited to spamming, remarks: hacking and intrusion attempts coming from chello.pl address remarks: space shall be reported ONLY to: remarks: remarks: abuse at chello.pl remarks: remarks: Any reports sent to any other e-mail addresses may be treated remarks: as SPAM itself and followed by legal actions remarks: against originator mnt-by: AS6830-MNT source: RIPE # Filtered -- Suresh Ramasubramanian (ops.lists at gmail.com) From ripe-anti-spam-wg at powerweb.de Sun Apr 22 18:14:50 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sun, 22 Apr 2012 18:14:50 +0200 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: Message-ID: <4F942E7A.2070407@powerweb.de> Suresh Ramasubramanian wrote: Hi Suresh, in fact chello is one of the biggest ISPs in the RIPE region that deliberately have no working abuse contacts. We have about 15 reports daily to them, here some proof that they are ALL not working. Apr 19 21:04:36 service sendmail[13239]: q3JJ3Z0P013224: to=, ctladdr= (0/0), delay=00:01:01, xdelay=00:01:00, mailer=esmtp, pri=30606, relay=smtp.chello.pl. [213.46.255.2], dsn=4.0.0, stat=Deferred: Connection timed out with smtp.chello.pl. Apr 21 14:31:26 service sendmail[19644]: q3LCVQ0O019644: to=, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=32566, relay=mgate.chello.at. [213.46.255.2], dsn=5.1.1, stat=User unknown Apr 9 17:23:55 service sendmail[20651]: q39FNr0P020643: to=, ctladdr= (0/0), delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=30603, relay=chello.ie, dsn=5.1.2, stat=Host unknown (Name server: chello.ie: no data known) Apr 11 19:24:28 service sendmail[28775]: q3BHNQ0P028733: to=, ctladdr= (0/0), delay=00:01:01, xdelay=00:01:00, mailer=esmtp, pri=30607, relay=chello.fr. [216.8.179.25], dsn=4.0.0, stat=Deferred: Connection timed out with chello.fr. Apr 4 22:03:49 service sendmail[7941]: q34K3l0P007914: to=, ctladdr= (0/0), delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=30605, relay=mail.chello.sk. [213.46.255.2], dsn=5.1.1, stat=User unknown BTW: asking the maintainer did surely never help ... Kind regards, Frank > Like this for example - yes, not a formally defined abuse contact > field, but they are so insistent that they should only receive spam > reports at abuse at chello.pl > > Unfortunately - that address doesn't exist. If someone from Chello > could please contact me about nigerians who keep abusing what is > likely an open proxy at 89.70.30.128 I'd be obliged > > --srs (postmaster at lotuslive.com / AS27477 IBM Lotuslive) > > abuse at chello.pl > SMTP error from remote mail server after RCPT TO:: > host smtp.upcpoczta.pl [213.46.255.2]: 550 5.1.1 > unknown recipient rejected > > > route: 89.70.0.0/16 > descr: UPC.pl > origin: AS9141 > remarks: Any abuse activities including, but not limited to spamming, > remarks: hacking and intrusion attempts coming from chello.pl address > remarks: space shall be reported ONLY to: > remarks: > remarks: abuse at chello.pl > remarks: > remarks: Any reports sent to any other e-mail addresses may be treated > remarks: as SPAM itself and followed by legal actions > remarks: against originator > mnt-by: AS6830-MNT > source: RIPE # Filtered > > > > -- 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 ====================================================================== From rezaf at mindspring.com Sun Apr 22 18:23:18 2012 From: rezaf at mindspring.com (Reza Farzan) Date: Sun, 22 Apr 2012 12:23:18 -0400 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: Message-ID: Hi Suresh, As you know, the domain "chello.pl" is owned by UPC Broadband Operations B.V. Since their abuse address does not work, you may want to contact their main contact: hostmaster at chello.at And if that address fails, try contacting EPAG Domainservices GmbH "support at epag.de" which hosts "chello.pl" domain. Interestingly, the domain "chello.pl" would lead you to "upc.pl" which is registered by NASK in Poland. ul. Wawozowa 18 02-796 Warszawa Polska/Poland +48.22 3808300 info at dns.pl -------- To deal with Nigerians spammers, please send a copy of the Spam to these addresses as well: - vdventera at saps.org.za - hq.commercial at saps.org.za - 419scam at saps.org.za ++++ Thank you, Reza Farzan rezaf at mindspring.com > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net > [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Suresh > Ramasubramanian > Sent: Sunday, April 22, 2012 11:25 AM > To: anti-abuse-wg at ripe.net > Subject: [anti-abuse-wg] abuse-contact is not going to fly > unless we get all the legitimate players adopting it first > > Like this for example - yes, not a formally defined abuse > contact field, but they are so insistent that they should > only receive spam reports at abuse at chello.pl > > Unfortunately - that address doesn't exist. If someone from > Chello could please contact me about Nigerians who keep > abusing what is likely an open proxy at 89.70.30.128 I'd be obliged > > --srs (postmaster at lotuslive.com / AS27477 IBM Lotuslive) > > abuse at chello.pl > SMTP error from remote mail server after RCPT > TO:: > host smtp.upcpoczta.pl [213.46.255.2]: 550 5.1.1 > unknown recipient rejected > > > route: 89.70.0.0/16 > descr: UPC.pl > origin: AS9141 > remarks: Any abuse activities including, but not > limited to spamming, > remarks: hacking and intrusion attempts coming from > chello.pl address > remarks: space shall be reported ONLY to: > remarks: > remarks: abuse at chello.pl > remarks: > remarks: Any reports sent to any other e-mail > addresses may be treated > remarks: as SPAM itself and followed by legal actions > remarks: against originator > mnt-by: AS6830-MNT > source: RIPE # Filtered > > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 9.0.0.888, Virus/Spyware Database: 6.19610) > http://www.pctools.com/ > ======= > From ops.lists at gmail.com Sun Apr 22 18:34:07 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 22 Apr 2012 22:04:07 +0530 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: Message-ID: Of course. But as they are careful enough to inform people through their whois that they will reject reports going to these other addresses .. On Sun, Apr 22, 2012 at 9:53 PM, Reza Farzan wrote: > > As you know, the domain "chello.pl" is owned by UPC Broadband Operations > B.V. > > Since their abuse address does not work, you may want to contact their main > contact: hostmaster at chello.at > > And if that address fails, try contacting EPAG Domainservices GmbH > "support at epag.de" which hosts "chello.pl" domain. > > Interestingly, the domain "chello.pl" would lead you to "upc.pl" which is > registered by NASK in Poland. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Wed Apr 25 04:23:45 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Apr 2012 07:53:45 +0530 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: Message-ID: On Sun, Apr 22, 2012 at 10:04 PM, Suresh Ramasubramanian wrote: > Of course. But as they are careful enough to inform people through > their whois that they will reject reports going to these other > addresses .. This is amazing. So reza had cc'd hostmaster at chello.at in his email - and I hit reply all. Now - it seems they don't seem to accept email at their hostmaster address either. [cc to chello.at removed] Your message was not delivered within 2 days and 0 hours. Host surf0n.vienna.chello.at is not responding. The following recipients did not receive this message: Please reply to if you feel this message to be in error. Original-Recipient: RFC822; Final-Recipient: RFC822; Action: failed Status: 4.4.7 Remote-MTA: dns; surf0n.vienna.chello.at X-Actual-Recipient: RFC822; -- Suresh Ramasubramanian (ops.lists at gmail.com) From Piotr.Strzyzewski at polsl.pl Wed Apr 25 08:06:32 2012 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 25 Apr 2012 08:06:32 +0200 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: Message-ID: <20120425060632.GA4432@hydra.ck.polsl.pl> On Wed, Apr 25, 2012 at 07:53:45AM +0530, Suresh Ramasubramanian wrote: > On Sun, Apr 22, 2012 at 10:04 PM, Suresh Ramasubramanian > wrote: > > Of course. But as they are careful enough to inform people through > > their whois that they will reject reports going to these other > > addresses .. > > This is amazing. So reza had cc'd hostmaster at chello.at in his email - > and I hit reply all. Now - it seems they don't seem to accept email > at their hostmaster address either. > > [cc to chello.at removed] Have you tried abuse at upc.com.pl? Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From ops.lists at gmail.com Wed Apr 25 08:29:45 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Apr 2012 11:59:45 +0530 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: <20120425060632.GA4432@hydra.ck.polsl.pl> References: <20120425060632.GA4432@hydra.ck.polsl.pl> Message-ID: On Wed, Apr 25, 2012 at 11:36 AM, Piotr Strzyzewski wrote: >> [cc to chello.at removed] > > Have you tried abuse at upc.com.pl? The polish UPC for abuse issues at their austrian division? Does that work? -- Suresh Ramasubramanian (ops.lists at gmail.com) From Piotr.Strzyzewski at polsl.pl Wed Apr 25 08:36:48 2012 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 25 Apr 2012 08:36:48 +0200 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: <20120425060632.GA4432@hydra.ck.polsl.pl> Message-ID: <20120425063648.GB4432@hydra.ck.polsl.pl> On Wed, Apr 25, 2012 at 11:59:45AM +0530, Suresh Ramasubramanian wrote: > On Wed, Apr 25, 2012 at 11:36 AM, Piotr Strzyzewski > wrote: > >> [cc to chello.at removed] > > > > Have you tried abuse at upc.com.pl? > > The polish UPC for abuse issues at their austrian division? Does that work? I have no idea. I have found this in less specific inetnum object: inetnum: 89.67.0.0 - 89.74.255.255 netname: UPC-PL descr: UPC Polska Sp. z o.o. descr: CPE Customers PL country: PL admin-c: UP94-RIPE tech-c: HMCB1-RIPE status: ASSIGNED PA remarks: Contact abuse at upc.com.pl concerning criminal remarks: activities like spam, hacks, portscans mnt-by: CHELLO-MNT changed: hostmaster at chello.at 20110124 changed: hostmaster at chello.at 20110330 source: RIPE Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From ops.lists at gmail.com Wed Apr 25 09:11:49 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Apr 2012 12:41:49 +0530 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: <20120425063648.GB4432@hydra.ck.polsl.pl> References: <20120425060632.GA4432@hydra.ck.polsl.pl> <20120425063648.GB4432@hydra.ck.polsl.pl> Message-ID: Given that frank gadegast posted something about like 15 of their abuse addresses not working .. thank you but no thanks, I'll take a raincheck :) On Wed, Apr 25, 2012 at 12:06 PM, Piotr Strzyzewski wrote: > > I have no idea. I have found this in less specific inetnum object: > > inetnum: ? ? ? ? 89.67.0.0 - 89.74.255.255 > netname: ? ? ? ? UPC-PL > descr: ? ? ? ? ? UPC Polska Sp. z o.o. -- Suresh Ramasubramanian (ops.lists at gmail.com) From thor.kottelin at turvasana.com Wed Apr 25 10:03:12 2012 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Wed, 25 Apr 2012 11:03:12 +0300 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first 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 Suresh Ramasubramanian > Sent: Wednesday, April 25, 2012 5:24 AM > To: rezaf at mindspring.com > Cc: anti-abuse-wg at ripe.net > On Sun, Apr 22, 2012 at 10:04 PM, Suresh Ramasubramanian > wrote: > > Of course. But as they are careful enough to inform people > through > > their whois that they will reject reports going to these other > > addresses .. > > This is amazing. So reza had cc'd hostmaster at chello.at in his email > - > and I hit reply all. Now - it seems they don't seem to accept > email > at their hostmaster address either. > Original-Recipient: RFC822; > Final-Recipient: RFC822; > Action: failed > Status: 4.4.7 > Remote-MTA: dns; surf0n.vienna.chello.at > X-Actual-Recipient: RFC822; Having a working abuse address is but a technicality. All mail sent to the address could still be handled by Mr Null. Another possible approach is this one: Final-Recipient: RFC822; abuse at romtelecom.ro Action: failed Status: 5.0.0 Remote-MTA: DNS; it11.romtelecom.ro Diagnostic-Code: SMTP; 554 rejected due to spam content Last-Attempt-Date: Mon, 23 Apr 2012 18:07:50 +0300 Even if the RIPE NCC would check abuse addresses by sending some kind of challenges, those messages might not trigger the spam filter of the Romanians, instead returning an OK result. Black hat providers will always ignore abuse reports (or use them to improve their spam lists), so having an abuse address that works on the SMTP level is just a beginning, useless on its own. -- Thor Kottelin http://www.anta.net/ From ripe-anti-spam-wg at powerweb.de Wed Apr 25 10:19:38 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 25 Apr 2012 10:19:38 +0200 Subject: [anti-abuse-wg] whats wrong in Kazakhstan ? Message-ID: <4F97B39A.4040802@powerweb.de> Hi all, this might not be really related to this group, but maybe has an impact on a mandatory abuse field. We realized at lot of spam and other abuse coming from KZ networks lately and found no email address nor abuse-mailbox-field in those networks at all. Find their whois records below (its only the networks we received abuse from during the last 4 days). Is there any kind of law that prohibits publishing of emails in Kazakhstan ? Or is this only one big ISP with a lazy admin ? A weird coincident ? Is there anybody from Kazakhstan on this list, that can explain this situation ? Kind regards, Frank P.S.: we also checked most of these records with -B manually, still no email address -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '176.222.130.0 - 176.222.131.255' inetnum: 176.222.130.0 - 176.222.131.255 netname: KZ-TNSPLUS-FTTB descr: FTTB_Taraz country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT remarks: INFRA-AW source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '176.222.130.0/23AS21299' route: 176.222.130.0/23 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '176.222.146.0 - 176.222.147.255' inetnum: 176.222.146.0 - 176.222.147.255 netname: KZ-TNSPLUS-FTTB descr: FTTB_Taraz country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT remarks: INFRA-AW source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '176.222.146.0/23AS21299' route: 176.222.146.0/23 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '176.222.148.0 - 176.222.151.255' inetnum: 176.222.148.0 - 176.222.151.255 netname: KZ-TNSPLUS-FTTB descr: FTTB_Almaty country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT remarks: INFRA-AW source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '176.222.148.0/22AS21299' route: 176.222.148.0/22 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '176.222.157.0 - 176.222.157.255' inetnum: 176.222.157.0 - 176.222.157.255 netname: KZ-TNSPLUS-FTTB descr: FTTB_Temirtau country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '176.222.157.0/24AS21299' route: 176.222.157.0/24 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '176.222.168.0 - 176.222.175.255' inetnum: 176.222.168.0 - 176.222.175.255 netname: KZ-TNSPLUS-FTTB descr: FTTB_Almaty country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT remarks: INFRA-AW source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '176.222.168.0/21AS21299' route: 176.222.168.0/21 descr: TNS Plus origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '176.222.188.0 - 176.222.189.255' inetnum: 176.222.188.0 - 176.222.189.255 netname: KZ-TNSPLUS-FTTB descr: FTTB_Semey country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '176.222.128.0/18AS21299' route: 176.222.128.0/18 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.88.224.0 - 178.88.239.255' inetnum: 178.88.224.0 - 178.88.239.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '178.88.224.0/20AS9198' route: 178.88.224.0/20 descr: DIS origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.88.80.0 - 178.88.95.255' inetnum: 178.88.80.0 - 178.88.95.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '178.88.80.0/21AS9198' route: 178.88.80.0/21 descr: DIS origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.136.0 - 178.89.143.255' inetnum: 178.89.136.0 - 178.89.143.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.136.0/21AS9198' route: 178.89.136.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.144.0 - 178.89.151.255' inetnum: 178.89.144.0 - 178.89.151.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.144.0/21AS9198' route: 178.89.144.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.144.0 - 178.89.151.255' inetnum: 178.89.144.0 - 178.89.151.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.144.0/21AS9198' route: 178.89.144.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.152.0 - 178.89.155.255' inetnum: 178.89.152.0 - 178.89.155.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.152.0/22AS9198' route: 178.89.152.0/22 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.152.0 - 178.89.155.255' inetnum: 178.89.152.0 - 178.89.155.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.152.0/22AS9198' route: 178.89.152.0/22 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.160.0 - 178.89.167.255' inetnum: 178.89.160.0 - 178.89.167.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.160.0/21AS9198' route: 178.89.160.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.168.0 - 178.89.175.255' inetnum: 178.89.168.0 - 178.89.175.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.168.0/21AS9198' route: 178.89.168.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.89.192.0 - 178.89.207.255' inetnum: 178.89.192.0 - 178.89.207.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '178.89.192.0/20AS9198' route: 178.89.192.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.91.31.0 - 178.91.31.31' inetnum: 178.91.31.0 - 178.91.31.31 netname: KAZRENA descr: in Shuchink country: KZ admin-c: SA2985-RIPE tech-c: SA2985-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Satekov Aibek address: Almaty, Satpaev street,22 address: KZ phone: +7 727 2926741 nic-hdl: SA2985-RIPE source: RIPE # Filtered % Information related to '178.91.0.0/19AS9198' route: 178.91.0.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '212.154.182.0 - 212.154.182.3' inetnum: 212.154.182.0 - 212.154.182.3 netname: Nomad_Insurance descr: Nomad Insurance descr: in Aktobe country: KZ admin-c: PS9080-RIPE tech-c: PS9080-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Prasolov Sergei address: Almaty, Timiryazev str, 15 address: KZ phone: +7 727 3212121 nic-hdl: PS9080-RIPE source: RIPE # Filtered % Information related to '212.154.180.0/22AS50482' route: 212.154.180.0/22 descr: Kazakhtelecom Data Network Administration origin: AS50482 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '212.154.236.0 - 212.154.236.3' inetnum: 212.154.236.0 - 212.154.236.3 netname: ALSI descr: TOO ALSI descr: in Kostanaiskaya obl, Borovskoe country: KZ admin-c: TR2652-RIPE tech-c: TR2652-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Tatyana Redkina address: Almaty, Dostyk, 91/1 address: KZ phone: +7 727 25030340 nic-hdl: TR2652-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '212.154.236.0/22as50482' route: 212.154.236.0/22 descr: Kazakhtelecom Data Network Administration origin: as50482 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2.132.0.0 - 2.132.15.255' inetnum: 2.132.0.0 - 2.132.15.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '2.132.0.0/20AS9198' route: 2.132.0.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2.132.128.0 - 2.132.143.255' inetnum: 2.132.128.0 - 2.132.143.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '2.132.128.0/20AS9198' route: 2.132.128.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2.132.144.0 - 2.132.159.255' inetnum: 2.132.144.0 - 2.132.159.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '2.132.144.0/20AS9198' route: 2.132.144.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2.132.16.0 - 2.132.31.255' inetnum: 2.132.16.0 - 2.132.31.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '2.132.16.0/20AS9198' route: 2.132.16.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.1.0 - 37.99.1.255' inetnum: 37.99.1.0 - 37.99.1.255 netname: KZ-TNSPLUS-20120207 descr: FTTB_Uralsk country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.1.0/24AS21299' route: 37.99.1.0/24 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.112.0 - 37.99.115.255' inetnum: 37.99.112.0 - 37.99.115.255 netname: KZ-TNSPLUS-20120118 descr: FTTB_Kokshetau country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT remarks: INFRA-AW source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.112.0/22AS21299' route: 37.99.112.0/22 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.116.0 - 37.99.117.255' inetnum: 37.99.116.0 - 37.99.117.255 netname: KZ-TNSPLUS-20120118 descr: FTTB_Semey country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT remarks: INFRA-AW source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.116.0/23AS21299' route: 37.99.116.0/23 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.24.0 - 37.99.31.255' inetnum: 37.99.24.0 - 37.99.31.255 netname: KZ-TNSPLUS-20120118 descr: FTTB_Karaganda country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.24.0/21AS21299' route: 37.99.24.0/21 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.48.0 - 37.99.63.255' inetnum: 37.99.48.0 - 37.99.63.255 netname: KZ-TNSPLUS-20120118 descr: FTTB_Almaty country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.48.0/20AS21299' route: 37.99.48.0/20 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.80.0 - 37.99.87.255' inetnum: 37.99.80.0 - 37.99.87.255 netname: KZ-TNSPLUS-20120118 descr: FTTB_Almaty country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.80.0/21AS21299' route: 37.99.80.0/21 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.88.0 - 37.99.89.255' inetnum: 37.99.88.0 - 37.99.89.255 netname: KZ-TNSPLUS-20120118 descr: FTTB_Uralsk country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.88.0/23AS21299' route: 37.99.88.0/23 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '37.99.96.0 - 37.99.97.255' inetnum: 37.99.96.0 - 37.99.97.255 netname: KZ-TNSPLUS-20120118 descr: FTTB_Oskemen country: KZ admin-c: DG5853-RIPE tech-c: DG5853-RIPE status: ASSIGNED PA mnt-by: TNSPLUS-MNT source: RIPE # Filtered person: Dmitriy Gromov address: 38 Dostik str., Almaty, Kazakhstan phone: +7 705 833-55-55 nic-hdl: DG5853-RIPE mnt-by: TNSPLUS-MNT source: RIPE # Filtered % Information related to '37.99.96.0/23AS21299' route: 37.99.96.0/23 descr: 2DAY Telecom LLP origin: AS21299 mnt-by: TNSPLUS-MNT mnt-routes: SATELCOM-MNT mnt-routes: ORBITA-PLUS-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '82.200.137.0 - 82.200.137.31' inetnum: 82.200.137.0 - 82.200.137.31 netname: KTOWREALT descr: LLP K_TOWERS REALTY descr: in Almaty country: KZ admin-c: BR2515-RIPE tech-c: BR2515-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Boribaev Realty address: 050000 Almaty, Dostyk,180 phone: +7 727 23909050 nic-hdl: BR2515-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '82.200.128.0/19AS9198' route: 82.200.128.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '82.200.224.0 - 82.200.224.127' inetnum: 82.200.224.0 - 82.200.224.127 netname: AKIMJ_POD descr: GU "Apparat akima Zhambylskoi obl" country: KZ admin-c: KW170-RIPE tech-c: KW170-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Kalashnikov Wladimir address: Taraz, st. Abaj, d.125 , Republic of Kazakhstan phone: +7 7262 454688 nic-hdl: KW170-RIPE source: RIPE # Filtered % Information related to '82.200.224.0/23AS9198' route: 82.200.224.0/23 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '88.204.136.0 - 88.204.136.31' inetnum: 88.204.136.0 - 88.204.136.31 netname: KABLAN descr: KABLAN LLP descr: Almaty, str ABAI 26 a country: KZ admin-c: AG6698-RIPE tech-c: AG6698-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: ACHMEDIAROVA GULNARA address: Almaty, str ABAI 26 a address: KZ phone: +7 3272 599392 nic-hdl: AG6698-RIPE source: RIPE # Filtered % Information related to '88.204.128.0/20AS9198' route: 88.204.128.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '88.204.158.0 - 88.204.158.63' inetnum: 88.204.158.0 - 88.204.158.63 netname: O2DISIGN descr: o2Design country: KZ admin-c: KO566-RIPE tech-c: KO566-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Kopanica Olga address: microdistrict ? 6, 25 office 14 address: Almaty phone: +7 3272 508383 nic-hdl: KO566-RIPE source: RIPE # Filtered % Information related to '88.204.128.0/19AS9198' route: 88.204.128.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '88.204.170.0 - 88.204.170.3' inetnum: 88.204.170.0 - 88.204.170.3 netname: IPPERCENTRE descr: Kalymkulov Elnar Alievitch ip. country: KZ admin-c: EK1920-RIPE tech-c: EK1920-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Elnar Kalymkulov address: 473000 Astana, Manas st.36 phone: +7 7172 527971 nic-hdl: EK1920-RIPE source: RIPE # Filtered % Information related to '88.204.168.0/21AS9198' route: 88.204.168.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.122.0 - 89.218.122.3' inetnum: 89.218.122.0 - 89.218.122.3 netname: KEREMET descr: KEREMET SAUDA LTD country: KZ admin-c: KA3141-RIPE tech-c: KA3141-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: KIMBAEV ALMAS address: Chimbay Str. 107 address: city KyzylOrda phone: +7 72422 224086 nic-hdl: KA3141-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.120.0/22AS9198' route: 89.218.120.0/22 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.212.0 - 89.218.212.3' inetnum: 89.218.212.0 - 89.218.212.3 netname: ARMAN descr: ARMAN descr: in Aktau, Building 39B, microdistrict 8 country: KZ admin-c: IN426-RIPE tech-c: IN426-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Ibrashev Nurlan address: Aktau, Building 39B, microdistrict 8 address: KZ phone: +7 7292 300366 phone: +7 701 5319663 nic-hdl: IN426-RIPE source: RIPE # Filtered % Information related to '89.218.208.0/21AS9198' route: 89.218.208.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.255.0 - 89.218.255.3' inetnum: 89.218.255.0 - 89.218.255.3 netname: ALMA_ODT descr: JSC Kazakhtelecom, Almaty Affiliate descr: For the service purposes, for joining the equipment country: KZ admin-c: EY229-RIPE tech-c: EY229-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Erasilov Yalihan address: 39A, Shaikovskogo., Almaty, Republic of Kazakhstan address: KZ phone: +7 728 2 21 16 21 nic-hdl: EY229-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.248.0/21AS9198' route: 89.218.248.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.38.0 - 89.218.38.7' inetnum: 89.218.38.0 - 89.218.38.7 netname: ALLER descr: LTD Shaller Kazahstan descr: in Almaty country: KZ admin-c: LO1217-RIPE tech-c: LO1217-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Lyadmila Ostankina address: : 050043 Almaty, Samal-2.77 phone: +7 727 22642663 nic-hdl: LO1217-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.32.0/20AS9198' route: 89.218.32.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.39.0 - 89.218.39.63' inetnum: 89.218.39.0 - 89.218.39.63 netname: KAZINTERCOM descr: LTD KAZINTERCOM descr: in Almaty country: KZ admin-c: PV4983-RIPE tech-c: PV4983-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Ponamorev Vitaliy address: 050043 Almaty, Manas str.,50/V phone: +7 727 2576689 nic-hdl: PV4983-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.39.0/24AS9198' route: 89.218.39.0/24 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.50.0 - 89.218.50.3' inetnum: 89.218.50.0 - 89.218.50.3 netname: NCAGIP descr: Nauchnyi centr akusherstva,gynecologii i perinatologii descr: in Almaty country: KZ admin-c: BA3892-RIPE tech-c: BA3892-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Belych Artem address: 050000Almaty, Dostik 125 address: KZ phone: +7 727 3004566 nic-hdl: BA3892-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.48.0/21AS9198' route: 89.218.48.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.52.0 - 89.218.52.15' inetnum: 89.218.52.0 - 89.218.52.15 netname: KOMTEL descr: " KOMTEL" LLC descr: Almaty country: KZ admin-c: DV1669-RIPE tech-c: DV1669-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Doncov Vadim address: 4, Tinibaeva st., Shymkent, Republic of Kazakhstan phone: +7 701 7269544 nic-hdl: DV1669-RIPE source: RIPE # Filtered % Information related to '89.218.48.0/21AS9198' route: 89.218.48.0/21 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.61.0 - 89.218.61.3' inetnum: 89.218.61.0 - 89.218.61.3 netname: SOFDC descr: LLP SOFTDECO descr: in Almaty country: KZ admin-c: MO4341-RIPE tech-c: MO4341-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Mamarkova Olga address: Almaty, Abaya, 153.of 33 address: KZ phone: +7 727 2952515 nic-hdl: MO4341-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.61.0/24AS9198' route: 89.218.61.0/24 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.94.0 - 89.218.94.3' inetnum: 89.218.94.0 - 89.218.94.3 netname: SALONSVYAZISULPAK descr: Salon svyasi Sulpak ltd descr: Astana mkr.2A dom.3 country: KZ admin-c: TE868-RIPE tech-c: TE868-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Talgarov Erzhan address: 473000 Astana, mkr.2A dom.3 phone: +7 3172 341009 nic-hdl: TE868-RIPE source: RIPE # Filtered % Information related to '89.218.64.0/19AS9198' route: 89.218.64.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.95.0 - 89.218.95.7' inetnum: 89.218.95.0 - 89.218.95.7 netname: ASTANATELECOM_GCT descr: JSC Kazakhtelecom, Astana Affiliate descr: For the removed access descr: Astana country: KZ remarks: INFRA-AW admin-c: GK1323-RIPE tech-c: GK1323-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Gulhan Karmanova address: 473000 Astana, Abaya 78 phone: +7 3172 330403 nic-hdl: GK1323-RIPE source: RIPE # Filtered % Information related to '89.218.64.0/19AS9198' route: 89.218.64.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.10.0 - 92.46.11.255' inetnum: 92.46.10.0 - 92.46.11.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '92.46.10.0/23AS9198' route: 92.46.10.0/23 descr: Megaline Almaty origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.126.0 - 92.46.126.31' inetnum: 92.46.126.0 - 92.46.126.31 netname: TOOELITCOM descr: TOOELITCOM country: KZ admin-c: AS4033-RIPE tech-c: AS4033-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Ainabekova Sayle address: Astana, Potanina st. 3 phone: +7 7172 177247 nic-hdl: AS4033-RIPE source: RIPE # Filtered % Information related to '92.46.64.0/18AS9198' route: 92.46.64.0/18 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.128.0 - 92.46.129.255' inetnum: 92.46.128.0 - 92.46.129.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.46.128.0/19AS9198' route: 92.46.128.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.132.0 - 92.46.133.255' inetnum: 92.46.132.0 - 92.46.133.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.46.133.0/24AS9198' route: 92.46.133.0/24 descr: Kazakhtelecom Megaline Karaganda Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.134.0 - 92.46.135.255' inetnum: 92.46.134.0 - 92.46.135.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.46.134.0/24AS9198' route: 92.46.134.0/24 descr: Kazakhtelecom Megaline Karaganda Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.136.0 - 92.46.137.255' inetnum: 92.46.136.0 - 92.46.137.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.46.136.0/24AS9198' route: 92.46.136.0/24 descr: Kazakhtelecom Megaline Karaganda Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.144.0 - 92.46.153.255' inetnum: 92.46.144.0 - 92.46.153.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.46.148.0/24AS9198' route: 92.46.148.0/24 descr: Kazakhtelecom Megaline Karaganda Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.14.0 - 92.46.15.255' inetnum: 92.46.14.0 - 92.46.15.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '92.46.14.0/23AS9198' route: 92.46.14.0/23 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.154.0 - 92.46.161.255' inetnum: 92.46.154.0 - 92.46.161.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.46.156.0/22AS9198' route: 92.46.156.0/22 descr: Kazakhtelecom Megaline Karaganda Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.162.0 - 92.46.173.255' inetnum: 92.46.162.0 - 92.46.173.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.46.164.0/22AS9198' route: 92.46.164.0/22 descr: Kazakhtelecom Megaline Karaganda Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.20.0 - 92.46.21.255' inetnum: 92.46.20.0 - 92.46.21.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '92.46.20.0/23AS9198' route: 92.46.20.0/23 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.22.0 - 92.46.23.255' inetnum: 92.46.22.0 - 92.46.23.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '92.46.22.0/23AS9198' route: 92.46.22.0/23 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.26.0 - 92.46.30.255' inetnum: 92.46.26.0 - 92.46.30.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '92.46.26.0/24AS9198' route: 92.46.26.0/24 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.35.0 - 92.46.35.31' inetnum: 92.46.35.0 - 92.46.35.31 netname: SAGIMBEKOVA descr: SAGIMBEKOVA descr: in Almaty country: KZ admin-c: SN2324-RIPE tech-c: SN2324-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: SAGIMBEKOVA NURBIBA address: 050000 Almaty, Kiz Gibek str 2/176 phone: +7 7272 2558989 nic-hdl: SN2324-RIPE source: RIPE # Filtered % Information related to '92.46.0.0/18AS9198' route: 92.46.0.0/18 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.49.0 - 92.46.49.3' inetnum: 92.46.49.0 - 92.46.49.3 netname: Bairashew descr: in Almaty country: KZ admin-c: BA2916-RIPE tech-c: BA2916-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Bairashew Akibek address: 050000 Almaty, Zetisu 2-37-16 phone: +7 7272 2566768 nic-hdl: BA2916-RIPE source: RIPE # Filtered % Information related to '92.46.0.0/18AS9198' route: 92.46.0.0/18 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.51.0 - 92.46.51.15' inetnum: 92.46.51.0 - 92.46.51.15 netname: ENOTROC descr: LLP T-ONE CORPORATION descr: 1 Novay astr., Amlatinskaya oblast descr: in Almaty country: KZ admin-c: IV1069-RIPE tech-c: IV1069-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Ivaschenko Vitaliy address: Almaty, Al-Farabi, 93 address: KZ phone: +7 727 3905063 nic-hdl: IV1069-RIPE mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '92.46.0.0/18AS9198' route: 92.46.0.0/18 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.58.0 - 92.46.58.7' inetnum: 92.46.58.0 - 92.46.58.7 netname: BETUKAZ descr: "Kaz-Turk Beton", Almaty country: KZ admin-c: SA2276-RIPE tech-c: SA2276-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Shurabaeva Asel address: Burundaiskaya, 93ZH address: Almaty phone: +7 7272 346171 fax-no: +7 7272 346171 nic-hdl: SA2276-RIPE source: RIPE # Filtered % Information related to '92.46.0.0/18AS9198' route: 92.46.0.0/18 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.6.0 - 92.46.7.255' inetnum: 92.46.6.0 - 92.46.7.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ remarks: INFRA-AW admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '92.46.6.0/23AS9198' route: 92.46.6.0/23 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.46.8.0 - 92.46.9.255' inetnum: 92.46.8.0 - 92.46.9.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '92.46.8.0/23AS9198' route: 92.46.8.0/23 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.47.110.0 - 92.47.110.3' inetnum: 92.47.110.0 - 92.47.110.3 netname: Bostan descr: TOO "Bostan", Taraz country: KZ admin-c: TLY1-RIPE tech-c: TLY1-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Tolochkova Lidija Yakovlevna address: Zhambylskaja obl, g. Taraz, ul. Kazybek bi 142 a, Republic of Kazakhstan phone: +7 7262 457525 nic-hdl: TLY1-RIPE source: RIPE # Filtered % Information related to '92.47.96.0/20AS9198' route: 92.47.96.0/20 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.47.163.0 - 92.47.163.63' inetnum: 92.47.163.0 - 92.47.163.63 netname: Business_Telecom descr: Business Telecom LLP descr: in Almaty, Bogenbay. str. 150 country: KZ admin-c: AS349-RIPE tech-c: AS349-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Azamat Syzdykov address: Almaty, Bogenbay. str. 150 address: KZ phone: +7 727 3150050 fax-no: +7 727 3150050 nic-hdl: AS349-RIPE source: RIPE # Filtered % Information related to '92.46.0.0/15AS9198' route: 92.46.0.0/15 descr: Kazakhtelecom origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.47.164.0 - 92.47.171.255' inetnum: 92.47.164.0 - 92.47.171.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '92.47.164.0/22AS9198' route: 92.47.164.0/22 descr: Kazakhtelecom Megaline Karaganda Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.47.64.0 - 92.47.65.255' inetnum: 92.47.64.0 - 92.47.65.255 netname: AKTAMETRO descr: JSC Kazakhtelecom, Aktau Affiliate descr: Metro Ethernet Network country: KZ remarks: INFRA-AW admin-c: MA8421-RIPE tech-c: MA8421-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Murat Aitmagametov address: JSC Kazakhtelecom, Mangystau Affiliate address: 14 microdistrict, Dom svyazi address: Aktau, 130000 address: Kazakhstan phone: +7 7292 316705 phone: +7 701 7603523 nic-hdl: MA8421-RIPE source: RIPE # Filtered % Information related to '92.47.64.0/24AS9198' route: 92.47.64.0/24 descr: Kazakhtelecom Megaline Aktau Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '92.47.69.0 - 92.47.71.255' inetnum: 92.47.69.0 - 92.47.71.255 netname: AKTAMETRO descr: JSC Kazakhtelecom, Aktau Affiliate descr: Metro Ethernet Network country: KZ remarks: INFRA-AW admin-c: MA8421-RIPE tech-c: MA8421-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Murat Aitmagametov address: JSC Kazakhtelecom, Mangystau Affiliate address: 14 microdistrict, Dom svyazi address: Aktau, 130000 address: Kazakhstan phone: +7 7292 316705 phone: +7 701 7603523 nic-hdl: MA8421-RIPE source: RIPE # Filtered % Information related to '92.47.71.0/24AS9198' route: 92.47.71.0/24 descr: Kazakhtelecom Megaline Aktau Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.56.245.0 - 95.56.245.255' inetnum: 95.56.245.0 - 95.56.245.255 netname: FTI descr: INSTITUTE OF PHYSICS AND TECHNOLOGY LLC descr: in Almaty country: KZ admin-c: NV4722-RIPE tech-c: NV4722-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Nazarenko Vladimir address: 050014 Almaty, Ibragimova,11 phone: +7 7273 865513 nic-hdl: NV4722-RIPE source: RIPE # Filtered % Information related to '95.56.245.0/24AS9198' route: 95.56.245.0/24 descr: Megaline Almaty origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.0.0 - 95.57.7.255' inetnum: 95.57.0.0 - 95.57.7.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ remarks: INFRA-AW admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.0.0/21AS9198' route: 95.57.0.0/21 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.10.0 - 95.57.25.255' inetnum: 95.57.10.0 - 95.57.25.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.10.0/23AS9198' route: 95.57.10.0/23 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.107.0 - 95.57.107.255' inetnum: 95.57.107.0 - 95.57.107.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.107.0/24AS9198' route: 95.57.107.0/24 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.108.0 - 95.57.111.255' inetnum: 95.57.108.0 - 95.57.111.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.108.0/22AS9198' route: 95.57.108.0/22 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS1) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.108.0 - 95.57.111.255' inetnum: 95.57.108.0 - 95.57.111.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.108.0/22AS9198' route: 95.57.108.0/22 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.112.0 - 95.57.115.255' inetnum: 95.57.112.0 - 95.57.115.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.112.0/22AS9198' route: 95.57.112.0/22 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.116.0 - 95.57.117.255' inetnum: 95.57.116.0 - 95.57.117.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.116.0/23AS9198' route: 95.57.116.0/23 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.216.0 - 95.57.216.3' inetnum: 95.57.216.0 - 95.57.216.3 netname: AELITA descr: AELITA descr: in Aktobe country: KZ admin-c: KN1063-RIPE tech-c: KN1063-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Kuchugura Nadezhda address: 030000, Aktobe, Gaziza Zhubanovs st, 46 phone: +7 7132 514599 nic-hdl: KN1063-RIPE source: RIPE # Filtered % Information related to '95.57.192.0/19AS9198' route: 95.57.192.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.26.0 - 95.57.41.255' inetnum: 95.57.26.0 - 95.57.41.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.28.0/22AS9198' route: 95.57.28.0/22 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.0.0 - 95.57.7.255' inetnum: 95.57.0.0 - 95.57.7.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ remarks: INFRA-AW admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.0.0/21AS9198' route: 95.57.0.0/21 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.0.0 - 95.57.7.255' inetnum: 95.57.0.0 - 95.57.7.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ remarks: INFRA-AW admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.0.0/21AS9198' route: 95.57.0.0/21 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.59.0 - 95.57.74.255' inetnum: 95.57.59.0 - 95.57.74.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.60.0/22AS9198' route: 95.57.60.0/22 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.75.0 - 95.57.82.255' inetnum: 95.57.75.0 - 95.57.82.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.76.0/22AS9198' route: 95.57.76.0/22 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.57.91.0 - 95.57.106.255' inetnum: 95.57.91.0 - 95.57.106.255 netname: KRGMETRO descr: JSC Kazakhtelecom, Karaganda Affiliate descr: Metro Ethernet Network country: KZ admin-c: SF3380-RIPE tech-c: SF3380-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Sergey Fainitskiy address: JSC Kazakhtelecom, Karaganda Affiliate address: 31 Ermekova Str., Karaganda, 100000 address: Kazakhstan phone: +7 7212 433916 nic-hdl: SF3380-RIPE source: RIPE # Filtered % Information related to '95.57.92.0/23AS9198' route: 95.57.92.0/23 descr: Megaline Karaganda origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.58.190.0 - 95.58.191.255' inetnum: 95.58.190.0 - 95.58.191.255 netname: EKZ_ODT descr: JSC Kazakhtelecom, East Kazakhstan Affiliate descr: Dynamic dial-up pool descr: Ust-Kamenogorsk country: KZ remarks: INFRA-AW admin-c: KVY19-RIPE tech-c: KVY19-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Kubyshkin Vitaliy Yuryevich address: 67, str. Kazakhstan, Ust-Kamenogorsk phone: +7 7232 267345 nic-hdl: KVY19-RIPE source: RIPE # Filtered % Information related to '95.58.191.0/24AS9198' route: 95.58.191.0/24 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.58.28.0 - 95.58.28.3' inetnum: 95.58.28.0 - 95.58.28.3 netname: UNISCREDIT descr: UNISCREDIT in Almaty country: KZ admin-c: BD2309-RIPE tech-c: BD2309-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Burkitbaev Daniyar address: Almaty, Rozybakiev str, home 70 Kazakhstan phone: +7 727 3794584 fax-no: +7 727 3794632 nic-hdl: BD2309-RIPE source: RIPE # Filtered % Information related to '95.58.28.0/24AS9198' route: 95.58.28.0/24 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS4) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.58.40.0 - 95.58.41.255' inetnum: 95.58.40.0 - 95.58.41.255 netname: AKTAMETRO descr: JSC Kazakhtelecom, Mangystau Affiliate descr: Metro Ethernet Network country: KZ admin-c: MA8421-RIPE tech-c: MA8421-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Murat Aitmagametov address: JSC Kazakhtelecom, Mangystau Affiliate address: 14 microdistrict, Dom svyazi address: Aktau, 130000 address: Kazakhstan phone: +7 7292 316705 phone: +7 701 7603523 nic-hdl: MA8421-RIPE source: RIPE # Filtered % Information related to '95.58.40.0/23AS9198' route: 95.58.40.0/23 descr: Megaline Aktau origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.58.42.0 - 95.58.49.255' inetnum: 95.58.42.0 - 95.58.49.255 netname: AKTAMETRO descr: JSC Kazakhtelecom, Mangystau Affiliate descr: Metro Ethernet Network country: KZ admin-c: MA8421-RIPE tech-c: MA8421-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Murat Aitmagametov address: JSC Kazakhtelecom, Mangystau Affiliate address: 14 microdistrict, Dom svyazi address: Aktau, 130000 address: Kazakhstan phone: +7 7292 316705 phone: +7 701 7603523 nic-hdl: MA8421-RIPE source: RIPE # Filtered % Information related to '95.58.42.0/23AS9198' route: 95.58.42.0/23 descr: Megaline Aktau origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.58.50.0 - 95.58.50.255' inetnum: 95.58.50.0 - 95.58.50.255 netname: AKTAMETRO descr: JSC Kazakhtelecom, Mangystau Affiliate descr: Metro Ethernet Network country: KZ admin-c: MA8421-RIPE tech-c: MA8421-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Murat Aitmagametov address: JSC Kazakhtelecom, Mangystau Affiliate address: 14 microdistrict, Dom svyazi address: Aktau, 130000 address: Kazakhstan phone: +7 7292 316705 phone: +7 701 7603523 nic-hdl: MA8421-RIPE source: RIPE # Filtered % Information related to '95.58.50.0/24AS9198' route: 95.58.50.0/24 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.58.51.0 - 95.58.54.255' inetnum: 95.58.51.0 - 95.58.54.255 netname: AKTAMETRO descr: JSC Kazakhtelecom, Mangystau Affiliate descr: Metro Ethernet Network country: KZ admin-c: MA8421-RIPE tech-c: MA8421-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Murat Aitmagametov address: JSC Kazakhtelecom, Mangystau Affiliate address: 14 microdistrict, Dom svyazi address: Aktau, 130000 address: Kazakhstan phone: +7 7292 316705 phone: +7 701 7603523 nic-hdl: MA8421-RIPE source: RIPE # Filtered % Information related to '95.58.54.0/24AS9198' route: 95.58.54.0/24 descr: Megaline Ustkamenogorsk origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS2) % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '95.58.57.0 - 95.58.62.255' inetnum: 95.58.57.0 - 95.58.62.255 netname: AKTAMETRO descr: JSC Kazakhtelecom, Mangystau Affiliate descr: Metro Ethernet Network country: KZ admin-c: MA8421-RIPE tech-c: MA8421-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Murat Aitmagametov address: JSC Kazakhtelecom, Mangystau Affiliate address: 14 microdistrict, Dom svyazi address: Aktau, 130000 address: Kazakhstan phone: +7 7292 316705 phone: +7 701 7603523 nic-hdl: MA8421-RIPE source: RIPE # Filtered % Information related to '95.58.57.0/24AS9198' route: 95.58.57.0/24 descr: Megaline Aktau origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.6.12 (WHOIS3) From ripe-anti-spam-wg at powerweb.de Wed Apr 25 10:33:08 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 25 Apr 2012 10:33:08 +0200 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: Message-ID: <4F97B6C4.2010904@powerweb.de> Thor Kottelin wrote: > > Having a working abuse address is but a technicality. All mail sent to the > address could still be handled by Mr Null. Another possible approach is this > one: Again, technical validation is no cure against ISPs that do not want to receive abuse reports, its a cure against contacts that are forgotten and wrong by accident or even mailservers with problems that are unrecognized by the ISP. Surely you cannot force any member to work against abuse, but we can improve the accuracy of the contacts of those, that do like it. BTW: we had this problem with Kabeldeutschland lately, they updated their contacts now and receive reports again and really do something against abuse again. This was just an mistake of the ISP (they did not recognized by weeks). The manual work to get in contact with Kabeldeutschland was really complicated and intense, it would be helpful, if RIPE NCC would have a technical validation, simply because they have better ways to contact their members, and their members probably listen to RIPE NCC quicker than to any complainant. Kind regards, Frank > > Final-Recipient: RFC822; abuse at romtelecom.ro > Action: failed > Status: 5.0.0 > Remote-MTA: DNS; it11.romtelecom.ro > Diagnostic-Code: SMTP; 554 rejected due to spam content > Last-Attempt-Date: Mon, 23 Apr 2012 18:07:50 +0300 > > Even if the RIPE NCC would check abuse addresses by sending some kind of > challenges, those messages might not trigger the spam filter of the > Romanians, instead returning an OK result. > > Black hat providers will always ignore abuse reports (or use them to improve > their spam lists), so having an abuse address that works on the SMTP level > is just a beginning, useless on its own. > -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From chrish at consol.net Wed Apr 25 10:59:50 2012 From: chrish at consol.net (Chris) Date: Wed, 25 Apr 2012 10:59:50 +0200 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: <4F97B6C4.2010904@powerweb.de> References: <4F97B6C4.2010904@powerweb.de> Message-ID: <4F97BD06.2030202@consol.net> hi! On 04/25/2012 10:33 AM, Frank Gadegast wrote: > Surely you cannot force any member to work against abuse, but > we can improve the accuracy of the contacts of those, that > do like it. [...] > was really complicated and intense, it would be helpful, > if RIPE NCC would have a technical validation, simply > because they have better ways to contact their members, > and their members probably listen to RIPE NCC quicker > than to any complainant. i sense some dissonance here. anyway. if you wish to check objects for a form you don't like (like 'no optional email attribute') and subsequently inform the responsible person of what you think about your findings - i don't see what stops you. if you just walk up to me and tell me i have to do it for you - well: no, you can do that yourself. regards, Chris From ripe-anti-spam-wg at powerweb.de Wed Apr 25 11:13:56 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 25 Apr 2012 11:13:56 +0200 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: <4F97BD06.2030202@consol.net> References: <4F97B6C4.2010904@powerweb.de> <4F97BD06.2030202@consol.net> Message-ID: <4F97C054.1010600@powerweb.de> Chris wrote: > hi! Oh Chris ... > On 04/25/2012 10:33 AM, Frank Gadegast wrote: >> Surely you cannot force any member to work against abuse, but >> we can improve the accuracy of the contacts of those, that >> do like it. > [...] >> was really complicated and intense, it would be helpful, >> if RIPE NCC would have a technical validation, simply >> because they have better ways to contact their members, >> and their members probably listen to RIPE NCC quicker >> than to any complainant. > > i sense some dissonance here. Sure, because their mistake made it nearly impossible to reach them (remember: they finally DID update it, so they WANTED a working contact) anmd RIPE NCC and the new form were simply NO help at all. We accived the final contact of a peering contact we had (so: from a different source !) The current quality of the DB seems to depend on the abused ones instead of the publisher or the maintainer of the DB. I call this bananaware (getting ripe at the customer) ... The majority of the members DO like correct abuse contacts (at least to our expirience) and DO something against abuse from their networks, but surely make mistakes. Do you not think, that they would appriciate a system to raise the quality of their objects ? Well, I do. > anyway. > > if you wish to check objects for a form you don't like (like 'no optional email attribute') and subsequently inform the responsible person of what you think about your findings - i don't see what stops you. > if you just walk up to me and tell me i have to do it for you - well: no, you can do that yourself. Just in your case: I will fix your records to our needs, simply send me your maintainer password ;o) Kind regards, Frank > > regards, > > Chris > > > > > > -- > This message has been scanned by Kaspersky Anti-Virus. > For more information about data security please visit > http://www.kaspersky.com and http://www.viruslist.com -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ====================================================================== From ripe-wg-antiabuse at kyubu.de Wed Apr 25 13:17:15 2012 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Wed, 25 Apr 2012 11:17:15 +0000 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: Message-ID: <20120425111715.GA7448@core.kyubu.de> On Sun, Apr 22, 2012 at 12:23:18PM -0400, Reza Farzan wrote: All, > Interestingly, the domain "chello.pl" would lead you to "upc.pl" which is > registered by NASK in Poland. In case no contact could be established here, did anyone try to contact NASK-CERT (cert.pl) on this? Bye, Adrian From ops.lists at gmail.com Wed Apr 25 13:30:54 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Apr 2012 17:00:54 +0530 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: <20120425111715.GA7448@core.kyubu.de> References: <20120425111715.GA7448@core.kyubu.de> Message-ID: The fun part here is - that disclaimer in the whois says "any email sent to contacts other than abuse@ will be treated as spam and may expose the sender to legal action" They just said the magic words where I, as an employee, must then step back and NOT do that - because, remote though the chance is that they're going to sue IBM because I reported spam to another address as their abuse address is non functional, I cannot and will not run the risk of exposing my employer to any litigation. --srs On Wed, Apr 25, 2012 at 4:47 PM, Adrian wrote: > >> Interestingly, the domain "chello.pl" would lead you to "upc.pl" which is >> registered by NASK in Poland. > > In case no contact could be established here, did anyone try to contact NASK-CERT (cert.pl) on this? -- Suresh Ramasubramanian (ops.lists at gmail.com) From fw at deneb.enyo.de Wed Apr 25 13:41:23 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 25 Apr 2012 13:41:23 +0200 Subject: [anti-abuse-wg] whats wrong in Kazakhstan ? In-Reply-To: <4F97B39A.4040802@powerweb.de> (Frank Gadegast's message of "Wed, 25 Apr 2012 10:19:38 +0200") References: <4F97B39A.4040802@powerweb.de> Message-ID: <877gx4ujh8.fsf@mid.deneb.enyo.de> * Frank Gadegast: > P.S.: we also checked most of these records with -B manually, > still no email address For the first address block, -B -L gave me as an email address for the relevant LIR. I haven't checked the other blocks. This perception of missing email addresses really starts looking like a tool issue to me. From ripe-wg-antiabuse at kyubu.de Wed Apr 25 13:43:34 2012 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Wed, 25 Apr 2012 11:43:34 +0000 Subject: [anti-abuse-wg] abuse-contact is not going to fly unless we get all the legitimate players adopting it first In-Reply-To: References: <20120425111715.GA7448@core.kyubu.de> Message-ID: <20120425114334.GB7448@core.kyubu.de> On Wed, Apr 25, 2012 at 05:00:54PM +0530, Suresh Ramasubramanian wrote: Suresh, > The fun part here is - that disclaimer in the whois says "any email > sent to contacts other than abuse@ will be treated as spam and may > expose the sender to legal action" > > They just said the magic words where I, as an employee, must then step > back and NOT do that - because, remote though the chance is that > they're going to sue IBM because I reported spam to another address as > their abuse address is non functional, I cannot and will not run the > risk of exposing my employer to any litigation. There is no need to contact chello.pl. :) Adrian From joe at oregon.uoregon.edu Wed Apr 25 15:37:59 2012 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Wed, 25 Apr 2012 06:37:59 -0700 (PDT) Subject: [anti-abuse-wg] whats wrong in Kazakhstan ? Message-ID: <12042506375933_5358@oregon.uoregon.edu> Frank commented: #We realized at lot of spam and other abuse coming from KZ networks #lately and found no email address nor abuse-mailbox-field in those #networks at all. Find their whois records below (its only the #networks we received abuse from during the last 4 days). Whenever I want to understand what's happening with a given country and spam, I often find the CBL to be terrifically helpful. For example, KZ is currently a top-ten botted country according to the CBL http://cbl.abuseat.org/country.html mentioning 172,239 entries Breaking that down by domain, http://cbl.abuseat.org/domain.html shows: -- 139,032 listings for online.kz -- 13,989 listings for nursat.net -- 9,686 listings for caravan.kz [there may be other kz domains that are also relevant, but at a level that's too low to show up on that by-domain summary] All three of the listed domains have domain whois with POC information for those who may want to reach out (I don't know if those doing so will need to speak Kazakh, or if Russian or English perhaps might be sufficient). Regards, Joe From pk at DENIC.DE Wed Apr 25 19:23:15 2012 From: pk at DENIC.DE (Peter Koch) Date: Wed, 25 Apr 2012 19:23:15 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4F8C8B56.3080305@ripe.net> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> Message-ID: <20120425172315.GA22404@x27.adm.denic.de> On Mon, Apr 16, 2012 at 11:12:54PM +0200, Denis Walker wrote: > If you can't reliably find the data you have little chance of validating > it. The whole point of this proposal is to fix the abuse contact details > in one easy to find place in the database, by humans and scripting. Far > from putting off the day when the mess has to be cleared up, this is the > first step in cleaning up the already existing mess. this is actually what I thought where and why we started all this (except that i'd not qualify the situation as a "mess"). Now, the policy proposal in its version 2.0 - and even more so the discussion around it - conflate a number of issues. That added to the ambiguities of the proposal really make it hard to support it. The 'arguments supporting the porposal' lists two, maybe three, major advantages: 1) a single attribute added to a number of object types that enables maintainers of that object (maybe acting on behalf of the resource holder) to publish an abuse contact 1b) on the receiving end, framed expectations where to look for said information 2) also on the receiving end, "unlimited" access to abuse contact information I agree that an "abuse-c" attribute pointing to some other object is much more in line with the overall design of the RIPE DB than an "abuse-mailbox" that would not provide another level of indirection. To that extent the proposal is worthwile. However, most everything else needs clarification (or a less mandatory attitude). Therefore, I do not support 2011-06 in its current form. Accepting the assumption it was hard for resource holders/maintainers to find the right attribute/object type to publish abuse contact information, this can be well achieved with abuse-c. But the various examples provided in this and other threads suggest that more differentiation is needed for the communication channels. An abuse-c target object should inherit most of its attributes from the role: object and should offer different ways of reporting: manual (email), automated (email) and, maybe, web forms and the likes. Note, the idea was to help resource holders communicate their preferred way of contact establishment, _not_ to dictate or discriminate against their abuse handling procedures. And again, still assuming the idea is to help resource holders publish their data, there is no need to make "abuse-c" mandatory -- simply because the idea is so crisp and brilliant that they will adopt quickly. On item (1b) above, the proposal is unclear about the target audience for the "abuse-c" object on the receiving side. Is it the end user who - regularly or occasional - sends some report? These folk can use the abuse finder tool today and they should really not be exposed to the raw database output anyway. Whatever change is applied, it will need a tool with additional explanation and guidance. Is it for inter-operator incident handling? In this case, the relation to the IRT object needs to be clarified. That aside, people would probably expect manual or semi-automated (as in: ticketing system) handling of the incident report. Still, the current abuse-finder tool can already be of significant help. Is it for high volume automated report dissemination (trap or sensor initiated identification of "activity")? For this to work it needs automated handling on the receiving side and it should be clearly opt-in, so that the receiving entity can prepare for proper processing. To summarize: who is the target audience and what mode of operation are resource holders going to subscribe to by publishing an "abuse-c" reference? Item (2) above, no rate limiting on the responses, is also tricky. This is much more about the actual access mechanism than the object type and its attributes and the policy text (cf 'arguments opposing this proposal') already states that a proposal with the devil in the details and the details not laid out doesn't really make sense. And quite frankly, postponing this to the result of the NCC impact analysis is putting the cart before the horse. Details,please - and that also covers the proposed inheritance function. Then, finally, why should the "abuse-c" object, or the references to it, respectively, be mandatory (noting that version 2 claims it's mandatory for aut-nums only, again without giving deeper insight)? People won't use it otherwise? Well, that condradicts the initial assumption that the current plethora of mechanisms actually prevents people from choosing the right publication path. If they see a benefit, they will make use of it. Until then, there will be a phase of co-existence. However, I have read between the lines (or maybe even explicit) that some are dreaming of creating compliance cases at high volume, probably to get address space eventually revoked. I am unconvinced that this reflects the community cooperation that we celebrated happening the last 2+ decades. In any event, if that's the end goal, the proposal should be honest about this, but I think it's the wrong way to go. -Peter From tk at abusix.com Thu Apr 26 19:36:22 2012 From: tk at abusix.com (Tobias Knecht) Date: Thu, 26 Apr 2012 19:36:22 +0200 Subject: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <20120425172315.GA22404@x27.adm.denic.de> References: <201204161334.q3GDXsb8025643@pechora2.lax.icann.org> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DAC@EXVPMBX100-1.exc.icann.org> <4F8C6A60.3060005@powerweb.de> <41F6C547EA49EC46B4EE1EB2BC2F34184AD7780DEC@EXVPMBX100-1.exc.icann.org> <4F8C8B56.3080305@ripe.net> <20120425172315.GA22404@x27.adm.denic.de> Message-ID: <4F998796.8000306@abusix.com> Hi everybody, > Accepting the assumption it was hard for resource holders/maintainers to find the > right attribute/object type to publish abuse contact information, this can > be well achieved with abuse-c. But the various examples provided in this and other > threads suggest that more differentiation is needed for the communication channels. > An abuse-c target object should inherit most of its attributes from the role: > object and should offer different ways of reporting: manual (email), > automated (email) and, maybe, web forms and the likes. Note, the idea was to > help resource holders communicate their preferred way of contact establishment, > _not_ to dictate or discriminate against their abuse handling procedures. Sounds like a good suggestion. Imho the Best Practice for reporting abuse issues is e-mail for several good reasons. That's why I decided to stay with e-mail in this proposal. If there is any other Best Practice out there that tells us to add an attribute for webforms please let me know and I will add it to the proposal as an optional field in addition to e-mail and abuse-mailbox attributes. > And again, still assuming the idea is to help resource holders publish their > data, there is no need to make "abuse-c" mandatory -- simply because the idea > is so crisp and brilliant that they will adopt quickly. Even if I fully agree with your statement about the crisp and brilliant proposal ;-) I do not agree with your other statement. I think the abuse-c should be mandatory for several good reasons I already brought up on this list. I also agree that there are several reasons for not making it mandatory, but the brilliance of this proposal is probably not one of them. > On item (1b) above, the proposal is unclear about the target audience for the > "abuse-c" object on the receiving side. It is all of the following. > Is it the end user who - regularly or occasional - sends some report? > These folk can use the abuse finder tool today and they should really not be > exposed to the raw database output anyway. Whatever change is applied, > it will need a tool with additional explanation and guidance. Absolutely agree with the additional explanation and guidance. The Abuse Finder Tool is the Tool to use for this audience. Never the less to come back to the "mess" the Abuse Finder can not find all entries in the Database just because there is no way to parse free text in an 100% correct way. And to be honest needing up to 150 queries to get one email address is far away from not being a "mess". Please recognize, that I have not put this specific issue in the proposal, because it has nothing to do with the idea of the proposal itself. Never the less it shows that this proposal would also be a huge improvement when it comes to maintenance and development for RIPE NCC and the functionality and reliability of the Database which should be and hopefully is the most important issue. > Is it for inter-operator incident handling? > In this case, the relation to the IRT object needs to be clarified. > That aside, people would probably expect manual or semi-automated (as in: ticketing > system) handling of the incident report. Still, the current abuse-finder tool > can already be of significant help. As already stated in another mail on this mailinglist the IRT Object is another Object that has not direct connection to the abuse-c. Of course there will be maintainers that feel, that the abuse-c is a copy of the IRT and makes data redundant. Since we have seen numbers of IRT Object published there is absolutely no doubt about, that the future of the IRT Object has to be discussed. Whether if it will be removed, stays like it is or will be pushed more with documentation and "IRT Object Marketing". But this is and will not be part of this discussion. > Is it for high volume automated report dissemination (trap or sensor initiated > identification of "activity")? > For this to work it needs automated handling on the receiving side and it should > be clearly opt-in, so that the receiving entity can prepare for proper processing. Disagree from my experience in the anti-abuse industry. First of all reporting must be easy and receiving reports must be easy as well. That's why opt-in is a bad idea, which can bee seen at feedbackloops. Second, if you do not want to receive reports from one party, block them or directly delete them. That is best practice and widely adopted and really not complicated to do. Not even talking about the huge amount of work and maintenance that is needed to keep up a opt-in infrastructure and to find the right data sources. > To summarize: who is the target audience and what mode of operation are resource > holders going to subscribe to by publishing an "abuse-c" reference? The target audience is the reporter and the receiver. The reporter will find the responsible address more easy and the receiver can publish his information more easy. By publishing the abuse-c the receiver subscribes to his already existing duty to keep his network clean and avoid abusive behavior. I hope all people here agree to this. > Item (2) above, no rate limiting on the responses, is also tricky. This is much more > about the actual access mechanism than the object type and its attributes and the > policy text (cf 'arguments opposing this proposal') already states that a proposal > with the devil in the details and the details not laid out doesn't really make sense. It is about the possibility to access the abuse-c without query restrictions. As a policy proposer I do not care about the implementation, I care about functionality. And if this functionality is not possible in the RIPE DB, RIPE NCC will mention this in the impact analysis. If it is possible they will probably implement it as soon as this proposal reached consensus. > And quite frankly, postponing this to the result of the NCC impact analysis is putting > the cart before the horse. Details,please - and that also covers the proposed > inheritance function. Same here. We are talking about the goal and not the way at the moment. If we decide that we have the same goal we can talk with RIPE NCC about the way to get there and find a way that suits (mostly) all parties. > Then, finally, why should the "abuse-c" object, or the references to it, respectively, > be mandatory (noting that version 2 claims it's mandatory for aut-nums only, again > without giving deeper insight)? It will be mandatory for aut-nums, inetnums and inet6nums. I have seen that there is something missing in the proposal text and I'm sorry for that. It will be mandatory for aut-nums, inetnums and inet6nums. I will try to get it fixed in this version or at least in the next version. Thanks for pointing this out. > However, I have read between the lines (or maybe even explicit) that some are dreaming of creating compliance > cases at high volume, probably to get address space eventually revoked. I am unconvinced > that this reflects the community cooperation that we celebrated happening the last 2+ > decades. In any event, if that's the end goal, the proposal should be honest about this, > but I think it's the wrong way to go. I was reading the hole proposal, which was written by me, again a few seconds ago just to make sure I fully understood it. I have not seen anything about revoking address space and a possibility that high volumes lead to any kind of punishment. Not explicitly and not between the lines. Honestly (as honest as the proposal itself) reading between the lines and to fan fear are imho not good arguments against this proposal. Sorry. However the idea of revoking ip space based on high level complaint rates may be dreamed by some people, but there would be still a policy proposal necessary to go down this road and I think if this proposal shows up we can disagree there. I hope I was able to clear some stuff up and make it more clear what this proposal is about and about which parts we should discuss now. 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 vesely at tana.it Fri Apr 27 09:39:26 2012 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 27 Apr 2012 09:39:26 +0200 Subject: [anti-abuse-wg] OT: SPF deployment survey Message-ID: <4F9A4D2E.1080006@tana.it> All, please excuse this slightly off-topic post. I know there are many mail operators here, and reviewing the SPF protocol /is/ related to anti-abuse, as SPF may help determining the recipients of abuse reports. The IETF working group that is going to write SPFBIS has nearly completed the evaluation of the current deployment. But, thus far, only the analysis of published SPF records was considered --not how SPF results are used. Please contribute to a better understanding by completing the following survey: https://www.surveymonkey.com/s/SPF-deployment-survey It will only take three minutes (ten questions on a single page). Please help reaching all mail admins by forwarding this prompt to specialized mailing lists and mail admins you are in touch with, worldwide. Thank you in advance!