[acm-tf] Abuse Contact Information - Policy Proposal
Alessandro Vesely vesely at tana.it
Tue Oct 18 19:58:39 CEST 2011
On 18/Oct/11 13:21, Denis Walker wrote: > On 17/10/11:43 8:29 PM, Alessandro Vesely wrote: >> >> The "abuse-c:" reference to an abuse handler should make use of >> the hierarchical nature of the resource data, so that a given >> abuse team retains its relationship with the relevant resources >> until a different "abuse-c:" reference explicitly overrides it for >> a given assignment. Such transfers of abuse handling to less >> specific assignments are not meant to be automated, yet they >> minimize the workload on resource holders and facilitate good >> database design. > > Brian mentioned the issue of responsibility. With the IRT object we > assumed responsibility in a network hierarchy as recorded in the RIPE > Database? So for any IP address an IRT object referenced by the most > specific encompassing object held the relevant contact details (if any > IRT object was found). Can you assume the same responsibility structure > for abuse handling? Well, that's the idea the text is meant to convey. > Will an LIR, by default, be responsible for all abuse complaints > for their (PA assignments and sub allocations) customers who don't > manage it themselves? That is the practical reality of using this > network hierarchy in this way, especially if you make it mandatory > that an "abuse-c:" is referenced at some point in all hierarchies. Yes, as soon as a LIR sets an abuse-c, it becomes "responsible". As far as the proposal goes, it can just set, say, noreply at LIR and boast of being fully compliant with it. BitBucket at LIR would be a slightly better choice. Piping complaints to a tool that is able to extract some information, e.g. the IP numbers of both the spammer and the complainant, allows to collect interesting data. I would call the latter a passably decent solution, assuming such data will be used. Obviously, running a full blown abuse team involves costs that competitive providers may want to shun. > You said above "a different abuse-c: reference explicitly overrides it > for a given assignment". This is the case now for IRT. For abuse > handling do you want this to 'override' or 'take precedence over' a less > specific reference? I don't have direct experience of IRTs, but my understanding is that network providers are much more in touch with one another than mailbox providers --except possibly for huge ones. Hence, although mnt-irt and abuse-c are formally similar, trust may be more of a problem for the latter than the former. > The Abuse Finder tool should be promoted as the preferred way for > anyone to find abuse contact details in the RIPE Database. Yes. > There is a web form for 'the public' to use for one off enquires > and we have an API for 'power users' to use for doing many queries. > The logic of the Abuse Finder can be made to do whatever you want. > So if you want the 'override' option in the hierarchical lookups we > can stop searching at the first encompassing object with an > "abuse-c:". If you want the 'take precedence over' option we can > continue up the hierarchy until we get to an allocation and select > all "abuse-c:" attributes found. Yes. For the public, the abuse handler does not produce results widely different from regular web-whois queries, albeit it "knows" the history of how abuse contacts came into being and may thus help inexperienced users. For the power users, which I imagine consist of scripts running on various MTAs with minimal user intervention, a single target address should be the default behavior. An interesting idea is described in http://tools.ietf.org/html/draft-newton-et-al-weirds-rir-query For both uses, the major difficulty is to work out what RIR should be queried and take into account any different semantics in the response. > As the Abuse Finder is a tool that interprets raw whois queries we can > structure the output any way you want. So with a precedence option we > could clearly show which addresses should be used first for any > complaint. But also list alternatives to use if the primary option does > not respond. Good point. For feedback-loop, which seems to be the only documented practice right now, any human interaction is done beforehand, and no response is expected after filing a complaint. On the opposite, some acknowledgment from an abuse-c can be useful in some cases. Abuse reporters may want to keep track of the reports they send, and estimate the reactions of abuse teams. In case they decide they don't trust a team, they will want to use the alternative addresses only. By always giving a list of addresses, we may encourage reporters to send reports to all of them. I'd try to avoid such situation, see http://www.rhyolite.com/anti-spam/you-might-be.html#spam-fighter-3 If the reporters have to query the (first, second, ...) alternative contact, the query-log can be used to gauge the average trust that an abuse team scores --we'd better use authenticated queries if we want reliable data. IOW, we may force power users to evaluate abuse teams by providing a tool taking suitable parameters. > There was some talk earlier about best practices. If you have (or write) > such a document this could be referenced in the Abuse Finder output. I try and push for having these practices documented. I trust we'll get to know it when some reliable source publishes something relevant. Conversely, by publishing the experience we'll obtain with the tool, we can stimulate interest in standardizing such practices. > I know the TF was set up to decide where to 'put' abuse contact details. > But in order to finalise where to put the data, some thought must also > be given into how the data will be found and what interpretation can be > applied to the data. > > Maybe the answers to these questions are obvious. But at least you will > have thought about it and have a clear answer ready if these questions > are asked when you present your policy to the community. I don't think they're obvious at all. In particular, I don't know how users perceive the responsibility of network providers. Polls come to mind, as a way of asking. What if we engage the Anti-Abuse attendants in refining a questionnaire, Tuesday afternoon? We might propose them a set of basic questions, such as * Are ISPs responsible for spam sent by their customers? * Spammer supporters are less/equally/more culpable than spammers? * Should ISPs terminate support to a customer as soon as they become aware that it is a spammer? * How should ISPs become aware that a customer of theirs is a spammer? * ... >>> 1.) Which one would be the correct domain-name? >> > > You are suggesting adding a mandatory attribute, but are you sure all > resource holders will have valid data to put in this mandatory > attribute? Your assumption here is that all IP and AS resource holders > have a domain name. Is that true? Hm... most people has a domain name nowadays, it would be interesting to allow "none" (rather than null) for resource holders that actually don't have one. Do they need an abuse-c in that case? It shouldn't be mandatory, since it's the domain owner's interest to set it.
[ Acm-tf Archive ]