<div dir="ltr">" A statement by the registrant that they are not willing to employ an abuse team would be the best evidence."<div> </div><div>... Followed by swift de-registration of all IP resources.</div><div> </div><div>---</div><div> </div><div> </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 9, 2020 at 8:28 PM Alessandro Vesely <<a href="mailto:vesely@tana.it">vesely@tana.it</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri 08/May/2020 21:30:14 +0200 Ángel González Berdasco wrote: > On 08-05-2020 20:17 +0200, Alessandro Vesely wrote: >> On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ wrote: >>> Hi Alessandro, >>> >>> As I've indicated already several times (and not just in this >>> discussion), all the RIRs have forms or other methods to escalate >>> any issues. >>> >>> The proposal is only changing "let's have stats". >> >> >> I read: >> >> The RIPE NCC will validate the “abuse-mailbox:” attribute at >> least annually. Where the attribute is deemed incorrect, it >> will follow up in compliance with relevant RIPE Policies and >> RIPE NCC procedures. >> >> <a href="https://www.ripe.net/participate/policies/proposals/2019-04" rel="noreferrer" target="_blank">https://www.ripe.net/participate/policies/proposals/2019-04</a> >> >> The anonymized statistics is mentioned afterward. It seems to result >> from community escalation and reporting, rather than from the >> abuse-mailbox validation itself. By my proposal, instead, the output of >> the validation process is borne out when the abuse address is removed from >> the database —and the corresponding IP ranges duly transmitted. > > Currently there are already abuse contacts marked as having failed > validation. > Maybe it should be tagged in a different way. > I do not think removing them would be the solution, as that would be > ambiguous with not having been set at all. Plus, it is also possible > that it is actually working, and the failure was just a transient > error. Before removing or marking as invalid an abuse-mailbox, RIPE NCC has to make absolutely sure that that is a permanent condition. A statement by the registrant that they are not willing to employ an abuse team would be the best evidence. Then someone, possibly external, has to read the database and produce a list of the relevant IP addresses, so that MTAs having a suitable policy can immediately deploy it. As for removing vs. marking as invalid, the only consideration is that tools for retrieving abuse-addresses via rdap can hardly cope with the latter. However, they can probably check an exclusion list. So, it would work both ways. > An individual could contribute to the contact being marked as failed > (as it's already the case) by notifying RIPE. Is it? How? There is a contact form <a href="https://www.ripe.net/contact-form" rel="noreferrer" target="_blank">https://www.ripe.net/contact-form</a> where the topic can be selected to be "RIPE Database". However, I happened to report a bounce from an abuse address and see a reply from RIPE NCC Support asking "Could you please let us know which action is requested from our side?" The first steps of the validation process could be easily automated. The failure reporting web form could even show the first and last known dates when the reported address was tested. > The rir owner could also trigger a new check to show that it is working > again. Right. That should result in immediate rehabilitation. > And whatever you do with such information, is still up for local > policy. If am abuse contact is known to have been working last Monday, > but fails since yesterday, there's a good chance that it has been fixed > or it will be shortly. If it has never been verified to work and it has > been failing for seven years, well, there's probably no point in > notifying them through that address. Transient failures can happen, especially with heavily loaded mailboxes. However, the state of an abuse-mailbox should be a clear yes/no, not flipping too often. > However, all of that would still be a local policy decision, which I > suspect would be better received. You would set your own arbitrary > thresholds there, rather than the discussion on after which X time > should RIPE pull that entry from the db. Plus, not all purposes would > treat them similarly. > In case you are reporting an abuse from two hours ago, you may only > care that it is working *right now*. However, if you were checking > whether their abuse contact status, as one of multiple points > evaluating a peering request, trying to guess how problematic your > prospective neighbour may be, you might prefer seeing that their abuse > mail has been reachable for the last 6 months. I'd leave to RIPE NCC to determine how to reliably set an abuse contact status. If I, as an MTA admin, had to extract data from the RIPE database, trying to understand the reliability of abuse-c data, such as the first and last known dates it worked, I'd probably give up. OTOH, if I only had to rsync an IP list having a very low false positive rate, I'd probably go for it. If RIPE NCC remove or mark as invalid just the abuse-c's of acknowledged non-responding or non-existing abuse teams, then the FP rate ought to be very low. There will always be the case of the MTA which badly contracted with an unconcerned ISP. Their FP rate will account for the 0.x%, and they will keep complaining until they change provider. That's already the way email works for those large mailbox providers who can afford a reliable IP reputation system. Best Ale -- </blockquote></div>