Am 17.11.2010 17:40, schrieb Alessandro Vesely:
Tobia's proposal (2010-09) doesn't quite address testing, as it only concerns update notifications and corresponding corrections. How does RIPE NCC become aware that a database object contains invalid information? By "testing an abuse-mailbox" I mean actually sending a message to it, and verify the outcome.
The reason for splitting this up was, that the whois database has accuracy problems at other places as well. So the intend was to find a way to solve the accuracy problem in the hole whois database. And it was mentioned by Brian Nisbet before at the RIPE Service Group meeting, that there should be collaboration on this with different groups and this found more or less consensus. So at least it would be enough to setup a policy proposal, that requests from RIPE NCC to fix all accuracy problems in the database.
Sending is the most effective way to determine an address' validity. Thus, RIPE might define a "test" message-type. It should work much like any other complaint, except it does not affect reputation. To acknowledge the test, the recipient should send a response of some kind; it should be designed so as to also allow testing feedback loops. So much for the merit of testing.
Accepting mails from one system in a standardized format will tell you, that this system is accepting standardized mails from exactly this system. Not more. It does not show you if there is a spamfilter implemented (which is might be one good measurement), it does not tell you if the account is accepting mails from other IP addresses and not in other formats. I'm would more like a spreaded approach. People who are using the data for reporting, should be able to easily give feedback to RIPE. API, Webform, whatever. Putting these things together would help much more and would give RIPE NCC more power. "Oh damn I have overseen this message!" would not work anymore. The other part is, that in my opinion it is not RIPEs part to judge the work others are doing. I think the market is big enough that there will be self regulatory mechanism that show exactly who is doing a good job and who is not. Important for that is, that the information is freely available.
For the overall impact, building such a testing infrastructure implies that operators learn to run automated scripts upon receiving messages at their abuse-mailboxes, recognizing a few kinds of message formats (arf, x-arf, and iodef extension; one or more of these should provide for test messages.) The possibility to serve feedback loops for interested end users may also be aired, and postmasters may then want to send test messages to their own ISPs to check they work as expected.
I think the idea of a test message is a good idea, but I would not like to use this measurement only. Thanks, Tobias