[acm-tf] Draft of RIPE NCC Fuctionality Document
Alessandro Vesely vesely at tana.it
Tue Jun 14 20:08:46 CEST 2011
Hi Brian and all, On 13/Jun/11 17:06, Brian Nisbet wrote: > In conversation with Denis Walker from the NCC he let me know that he > had a document which proposed a way of dealing with some of the > matters the TF is dicussing. I'd like to share this with you today > (and, indeed, apologies for not sending it out to you sooner) and > discuss it on Wednesday. The document is a design approach based on > the current DB model that could form the basis for a policy > discussion. I think working out this kind of stuff is exactly what a mailing list is optimal for doing, as participants can propose snippets of text and give +1/-1 feedback about them in order to reach consensus. If Denis had posted this file to the list in May, we could have begun discussing it then. > I am by no means suggesting this is the only approach, but I do > like what is laid out in the document and so I submit it to the TF > for discussion. I like it too, and have some comments. Foremost, the paper has a section named "What to do if no dedicated abuse handler found", but never actually spells what to do if it /is/ found. It obviously assumes people have (their own) knowledge about that. The document mentions "a web interface for the public to use directly." I hope it doesn't refer to end-users. IMHO end-users should just click This-is-Spam buttons. I think the tool will mostly be used in scripts (for forwarding messages reported as spam to the right handler(s) --a process to be defined). An interactive version would be fine, of course. Care has to be taken for the "e-mail" attribute not to be misunderstood. Abuse reporting is going to be a cooperative effort. Defining abuse contact to be mandatory may result in abuse-mailboxes directly connected to /dev/null, a waste of resources for both setting up and running them. Having TiS buttons directly do nothing in such cases would sort the same effect more cheaply. OTOH, spam scoring tools may learn to take into account whether a message can be reported as spam or not, so I'd rather opt for auto-removal of non-functioning entries.
[ Acm-tf Archive ]