Hi,
An option could be the following: the possibility to set the abuse-mailbox field to something like "non-responsive", a predefined value, thats valid according to the format of the field. The cleanup will happen, the resource owner makes a decision and the reporter could see, that the resource owner does not want to have reports (via email) ...
That seems pretty reasonable to me.
That could be an option. There is only one point I do not understand. We are talking only about the direct allocations, which in my opinion should all have an abuse address and handle their abuse. That is at least my opinion. As I understood Franks idea the resource holder would have to call himself "non-responsive" and publish this information, which will definitevely create problems in the future. Just thinking of blacklists using this information and so on, so at the end the unresponsive will add addresses that are deleting inbound messages. Which is of course not good either, but we could even proof that an unresponsive ISPs has accepted mail on his given address. This can be interesting in legal situations like Frank explained as well. So at the moment I think we have a solution that is easy and understandable for everybody and tries to solve a lot of possible scenarios. I would rather not change things into a direction that makes specific scenarios impossible just to make it "easier" for reporters to manage things from a bounce handling or deliverability perspective. And on the other hand, we (abusix) are sending more than 500k reports per day to different ISPs all over the world using whois information and yes around 30% are bouncing. So what? We are not even looking at the bounce messages. Next time we try again to deliver messages. This is at the end not a real problem for reporting parties. And I would not put to much attention on it. On the long end I would rather like to see something like ARIN is doing with wrong contact information. Tagging whois entries if the data that is provided is not accurate and resource holders are not cooperative. Thanks, Tobias