<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 16, 2010, at 11:21 AM, Tobias Knecht wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite">Another request by members was that there should be the possibility to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">add some kind of object that contains 2 email addresses. One for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">personal interaction and one for automatic abuse reports. My idea was to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ask for a abuse-mailbox attribute within the IRT Object. So that would<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">fix that request.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">In ARIN, you can have zero or more abuse-c contacts per object.<br></blockquote><blockquote type="cite">I don't see why that couldn't work here.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Frankly, however, I don't think that will work as well as some people hope<br></blockquote><blockquote type="cite">because I have limited faith in the automated reporting systems following<br></blockquote><blockquote type="cite">the requested convention. Someone will think that the personal response<br></blockquote><blockquote type="cite">box is more responsive than the automatic reporting box and decide that<br></blockquote><blockquote type="cite">their need for response to automated reports outweighs the providers<br></blockquote><blockquote type="cite">need to sort things into different boxes. Others will simply report to both.<br></blockquote><br>This is not a problem of this proposal. This is a problem of the over<br>all situation at RIRs. We are having the problem of not having dedicated<br>abuse mailboxes, we are having the problem of data accuracy, we are<br>having the problem of complicated ways of parsing and finding abuse<br>contacts.<br><br></div></blockquote>No, this is a problem of human nature, education, and experience.</div><div><br></div><div>Human nature is that rather than follow the proper prescribed process</div><div>and sending automatic abuse reports to automated-abuse-c and sending</div><div>personal reports to personal-abuse-c, what usually happens instead is</div><div>that both forms of abuse reports go to:</div><div><br></div><div>admin-c</div><div>tech-c</div><div>every-other-c</div><div>abuse-c</div><div>parent-admin-c</div><div>parent-tech-c</div><div>parent-abuse-c</div><div>parent-every-other-c</div><div>parents-parent-admin-c</div><div>etc.</div><div><br></div><div>The education problem comes in the form of the majority of the people</div><div>that exhibit the above behavior do so out of ignorance because they</div><div>have not been taught and do not bother to educate themselves on</div><div>the proper way to go about reporting abuse.</div><div><br></div><div>The experience problem comes from the fact that less than stellar</div><div>behavior from some providers in response to proper abuse reporting</div><div>has created anecdotal evidence and experience-based perception</div><div>that it is more effective to shotgun everyone with your abuse report.</div><div><br><blockquote type="cite"><div>These are all self made problems.<br><br></div></blockquote>To some extent, perhaps. However, to a much larger extent, these</div><div>are problems collectively made by the systemic application of</div><div>human nature to imperfect systems built by humans.</div><div><br></div><div><blockquote type="cite"><div>This is not the last proposal you will see from us, because we want to<br>change something.<br><br></div></blockquote>I have no doubt of that.</div><div><br><blockquote type="cite"><div>The problem you described would not exist, if RIRs would have mandatory<br>abuse contacts in their whois, offering these in an easy to use DNS<br>based service, where everybody could ask for the right contact<br>information and shutting restricting queries more and more, so only real<br>messages will be sent to the personal accounts of the abuse desks.<br><br></div></blockquote>On this we will probably need to agree to disagree completely and vigorously.</div><div>I don't see any way in which mandatory abuse contacts in whois will change</div><div>the human nature problem, the educational problem, or even the experience-</div><div>based problem I described.</div><div><br></div><div>I do see several ways in which having an available field for an abuse contact</div><div>can in part help the situation. I don't see significant benefit to making it</div><div>mandatory, and, I do see a few potential downsides.</div><div><br><blockquote type="cite"><div>That is exactly the way we want to go down. But we should start<br>somewhere. And the problem that generates most pain at RIR members are<br>the not existing abuse contact objects at the moment.<br><br></div></blockquote>I guess that depends on who you consider to be the RIR member. I think</div><div>what you are describing is the thing that causes the most pain at the</div><div>abuse reporter side. I would posit that most RIR members are actually</div><div>abuse report recipients rather than abuse report generators.</div><div><br><blockquote type="cite"><div>The problem you described is absolutely real, but it is already today<br>and not a problem of this proposal. So let talk about a dedicated abuse<br>contact object and talk later about the other problem.<br><br></div></blockquote>You brought up the recommendation of separate abuse contacts for</div><div>automated vs. personal abuse reports. I responded to that subject.</div><div><br></div><div><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite">How would you do that with already existing objects? Lets think about<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the abuse-mailbox attribute which can be part of every person or role<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">object. What I do not want to happen that there will be more than one<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">objects having an abuse-mailbox attribute. That would start the same<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">trouble we have a RIPE at the moment, that there are 15 possibilities to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">put an abuse@ address and in some queries you find 10 of them with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">different addresses.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">Yep. At ARIN, abuse-c is a field in an ORG object which can either be<br></blockquote><blockquote type="cite">inherited by all child objects, or, over-ridden by an abuse-c field in<br></blockquote><blockquote type="cite">a child NETWORK or ASN object. You can have zero or more abuse-c<br></blockquote><blockquote type="cite">fields in each such object. Each abuse-c field contains a handle for<br></blockquote><blockquote type="cite">a CONTACT object.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">A CONTACT object is either a person or a role account.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">So would it be able to create a special role object that has a mandatory<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">abuse-mailbox attribute, what I think makes sense, that can only be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">linked to an abuse-c?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">Why would it need to be a special role object? Why not just use the<br></blockquote><blockquote type="cite">generic CONTACT object that already exists and link to it the same<br></blockquote><blockquote type="cite">way that admin-c or tech-c links to it.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">For example, say you have CONTACT objects as follows:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">OD19-ARIN<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Person<br></blockquote><blockquote type="cite">ABXX-ARIN<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Role<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Then, an ORG object, for example, could have the following<br></blockquote><blockquote type="cite">attributes:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">tech-c: OD19-ARIN<br></blockquote><blockquote type="cite">admin-c: OD19-ARIN<br></blockquote><blockquote type="cite">abuse-c: ABXX-ARIN<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Or, I could have ABXX-ARIN in all three fields, or, OD19-ARIN, or<br></blockquote><blockquote type="cite">any other combination. If I wanted, I could create yet another<br></blockquote><blockquote type="cite">CONTACT object for any of the fields. Simple, easy to understand,<br></blockquote><blockquote type="cite">and pretty flexible, no?<br></blockquote><br>This would work. Absolutely.<br>If this is the solution AfriNIC members can live with, fine. I would<br>suggest adding the abuse mailbox field and the RIPE equivalent "whois<br>-b" option for short data output and unrestricted query access.<br><br></div></blockquote>I'm not sure what you mean by adding the abuse mailbox field. Each</div><div>contact object has a required "Email" field. For example,</div><div>OD19-ARIN expands to:</div><div><br></div><div><div>[owen-delongs-macbook-pro:he.net/ipv6/business_site] owen% whois -h <a href="http://whois.arin.net">whois.arin.net</a> OD19-ARIN</div><div><br></div><div>Name: DeLong, Owen</div><div>Handle: OD19-ARIN</div><div>Company:</div><div>Address: c/o 3251 Firth Way</div><div>City: San Jose</div><div>StateProv: CA</div><div>PostalCode: 95121</div><div>Country: US</div><div>Comment:</div><div>RegDate:</div><div>Updated: 2009-09-27</div><div>Phone: +1-408-890-7992 (Office)</div><div>Email: <a href="mailto:owen@delong.com">owen@delong.com</a></div><div><br></div><blockquote type="cite"><div>Restrict abuse-c to one object. Instead we are running in the same<br>problem than RIPE a few years ago.<br><br></div></blockquote>Again, I'm not sure what you mean by this. Do you mean a record should</div><div>have exactly one abuse-c or do you mean that abuse-c should only appear</div><div>in number resource records and not org records, or what?</div><div><br><blockquote type="cite"><div>I would also like to see that the abuse-mailbox attribute is just shown<br>if the object is linked to the abuse-c, because if not, you will have 3<br>different admin-c, tech-c and abuse-c objects with 3 different abuse<br>contacts. And that will end up in the same problem RIPE has today.<br><br></div></blockquote>I think you are not understanding. Let me give a real example:</div><div><br></div><div>ORG Record:</div><div><br></div><div><div>OrgName: DeLong Consulting</div><div>OrgID: DELONG-Z</div><div>Address: c/o 3251 Firth Way</div><div>City: San Jose</div><div>StateProv: CA</div><div>PostalCode: 95121</div><div>Country: US</div><div>Comment:</div><div>RegDate: 2009-02-04</div><div>Updated: 2009-02-09</div><div>AdminHandle: OD19-ARIN</div><div>TechHandle: OD19-ARIN</div><div>AbuseHandle: OD19-ARIN</div><div><br></div><div>(yes, in this case, I'm using one CONTACT record for all three roles, but,</div><div>I suspect you understand that each role could have any CONTACT record</div><div>associated, and, you can have 1-n each of AdminHandle and TechHandle,</div><div>and 0-n of AbuseHandle).</div><div><br></div><div>Here's an example of a network resource with the above ORG as its</div><div>parent:</div><div><br></div><div><div><div>OrgID: DELONG-Z</div><div>NetRange: 192.159.10.0 - 192.159.10.255</div><div>CIDR: 192.159.10.0/24</div><div>NetName: DELONG</div><div>NetHandle: NET-192-159-10-0-1</div><div>Parent: NET-192-0-0-0-0</div><div>NetType: Direct Assignment</div><div>NameServer: NS.DELONG.SJ.CA.US</div><div>NameServer: <a href="http://ASILOMAR.DELONG.COM">ASILOMAR.DELONG.COM</a></div><div>Comment:</div><div>RegDate: 1994-11-02</div><div>Updated: 2009-02-10</div><div><br></div></div><div>Now, in this record, you'll note no Admin/Tech/Abuse handles.</div><div>It could have them, but, since they are not present, it inherits</div><div>these properties from DELONG-Z. Whois will display</div><div>them if you query for the network record, but, what is displayed</div><div>is stored in the parent record, not the resource record. You can,</div><div>optionally have contacts specified in the resource as well (0 or more</div><div>of each of Admin, Tech, Abuse) which, if present will be displayed.</div><div>The ORG data is also displayed by ARIN whois.</div><div><br></div><div>So, even though Abuse-c would point to a contact record in the</div><div>database, the whois interface would retrieve and display that</div><div>contact record along side the resource record. Does that meet</div><div>your need?</div><div><br></div></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite"><blockquote type="cite">15 million messages come from around 10 million uniq IP addresses.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">You're telling me that there are 10 million NEW spam source addresses<br></blockquote><blockquote type="cite">every day? I find that fairly hard to believe. Even so, I bet those 10 million<br></blockquote><blockquote type="cite">IP addresses don't represent 10 million unique NETWORK objects.<br></blockquote><blockquote type="cite">I don't think it takes lots of hours to store what you already retrieved<br></blockquote><blockquote type="cite">from whois in a hash with a time-stamp. The code for doing this is<br></blockquote><blockquote type="cite">well known and I suspect there are open source tools already available<br></blockquote><blockquote type="cite">that do so.<br></blockquote><br>Nope sorry, that was not the way I wanted to say.<br>15 million trap hits per month coming from 10 million unique IP<br>addresses per month. We see 10 million different IP addresses every<br>month. Which is not the same as infected systems, because over an month<br>they switch addresses.<br><br></div></blockquote>Understood.</div><div><br><blockquote type="cite"><div>We are hashing this and we are offering our cache system to others to<br>give them more easy access to these abuse contact information, because<br>we know it is not that easy to get all the needed information out of<br>whois that quickly.<br><br></div></blockquote>OK</div><div><br><blockquote type="cite"><div>The problem is, that at the moment there is no easy way to query<br>different whois servers and get the right answer, so everybody is doing<br>it a little bit different and that is the problem.<br><br></div></blockquote>OK, but, this isn't the problem of the data structure. It is a problem of the</div><div>available UI to retrieve the data. You are proposing a change to the</div><div>structure of the data to address a problem with the UI. I agree that</div><div>there is a need for resolving your UI problem, but, I don't agree that</div><div>such a change to the underlying data structure is needed, nor do I see</div><div>doing so as a particularly reliable way to achieve the UI change that you</div><div>seek.</div><div><br><blockquote type="cite"><div>There is the need to have a standardized way of searching and finding<br>the right information.<br><br></div></blockquote>Agreed, however, that is a UI question...</div><div><br></div><div><blockquote type="cite"><div>That is another point that is pointing to the IRT Object. ;-)<br><br></div></blockquote>And this is a data structure change, not necessarily a UI change.</div><div><br><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite">But I think we can go down another road with issue. If we can not find<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">consensus on the IRT Object and are not able to stop the query<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">restrictions, I would propose to start a service like this:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://labs.ripe.net/content/updated-heuristics-abuse-finder-service">http://labs.ripe.net/content/updated-heuristics-abuse-finder-service</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">That seems fairly reasonable and I suspect would be relatively trivial<br></blockquote><blockquote type="cite">to implement.<br></blockquote><br>As mentioned above. Mandatory abuse contact : DNS based abuse contact DB<br>: setting up a local DNS cache : all good.<br><br></div></blockquote>Yeah, not so convinced on that. I think that optional abuse contacts added</div><div>to whois with provisions for relaxed whois query rate limits where needed</div><div>is a viable alternative. I still don't see the case for making abuse contact</div><div>mandatory, and, I really don't think that DNS is the right place to store the</div><div>abuse contact information.</div><div><br><blockquote type="cite"><div>That would make things easy and stops thousands of different ways to do it.<br><br></div></blockquote>Now, you are dreaming. It _MIGHT_ provide one consistent way you can</div><div>depend on, but, others will continue to use other methods.</div><div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">That would probably be more easy than it is at RIPE, because if there is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">only one object containing the abuse contact information it should be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">really easy to get this done.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">You might have to still look at the NETWORK or ASN object and the parent<br></blockquote><blockquote type="cite">ORG object, if the child object doesn't contain an abuse-c, but, you should<br></blockquote><blockquote type="cite">never need more than two queries to build your list of contacts for a given<br></blockquote><blockquote type="cite">address range. After that, it's just a matter of querying the applicable<br></blockquote><blockquote type="cite">CONTACT objects.<br></blockquote><br>Absolutely right. But why penetrate the whois server if there would be<br>another alternative?<br><br></div></blockquote>Because the other alternative requires additional maintenance steps on the</div><div>part of the end users that are likely to be poorly maintained and thus suffer</div><div>accuracy reduction over time.</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So in my opinion there is a need of unrestricted query access.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">We can, perhaps, agree to disagree on this. To me, it sounds like a problem<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">of application optimization which I would argue should not be used to place<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">additional undue burden on the RIR whois services.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Okay lets agree on that. ;-)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">Fair enough. Increasing the query rate limits or placing finer granularity<br></blockquote><blockquote type="cite">on them, btw, is not necessarily a bad idea in my opinion. Allowing you<br></blockquote><blockquote type="cite">to sign up an address for a higher query rate service with a signed<br></blockquote><blockquote type="cite">contract containing an AUP specifying you won't be harvesting the<br></blockquote><blockquote type="cite">data for unapproved purposes would also be a reasonable alternative.<br></blockquote><br>DNS Based list for everybody?<br><br></div></blockquote>Certainly would not be my first choice.</div><div><br></div><div>Owen</div><div><br></div></body></html>