A bit of context

First, a quick recap for anyone who is new to this. A policy proposal was accepted back in June 2018 that asked us to start checking abuse contacts in the RIPE Database and to follow-up with resource holders to fix any invalid or outdated information.

Abuse contacts are email addresses in the RIPE Database for people to report network abuse. Generally speaking, network abuse comes from the users or customers on a network. So, if you find the IP address of someone who is spamming or hacking or generally up to no good, you can report this to their ISP directly via the abuse contact address.

Of course, as good Internet citizens the RIPE NCC will always have a working and up-to-date abuse contact - you can see ours at the bottom of this image taken from the RIPE Database. 

Whether these abuse contacts actually contain working email addresses is an issue that was left hanging after the “abuse-c:” attribute was first created by a policy in 2012. The policy stated that it was mandatory for networks to have an abuse mailbox in place, but didn’t say anything about how or whether this should be validated. The result was that there was never really any strong incentive for networks to keep this information up to date, apart from good practice and maintaining the accuracy of the database. Though, it’s important to note here that most abuse contacts are valid, but this is about making certain that all of them are working.

Once accepted, the proposal updated the policy to state that we will validate abuse-contact information in the RIPE Database (at least annually) — and it’s this implementation that we will be discussing here.

Some considerations

With that bit of background covered, let’s briefly talk about some of the guiding considerations we have been thinking about as we’ve planned our implementation.

• We don’t want to be bothering people who already have working abuse contact mailboxes. We are aiming to fix invalid information — not to create headaches or disruption across our community.

• This isn’t a one-time thing. We need a process that will cover an initial validation, but also allows for the ongoing validation of these emails, including checking newly-entered abuse contacts (this part will be ready by the time we begin our initial validation).

• Legacy resources are not within the scope of the policy. We will not be validating the abuse contacts for these resources.

• With around 70,000 emails to be validated, we need as much automation as possible to minimise the impact on our workload.

• This process is about fixing invalid information — we’re not looking to apply sanctions or close down members. Nevertheless, it will be crucial that resource holders work with us to fix any inaccurate data.

• The nature of our validation is about checking that there is a working email in the RIPE Database and that this corresponds to a working mailserver that can accept emails. We have no say in what network operators do with any abuse reports they receive.

The process

Putting these considerations into action, our planned validation process (for both LIR and independent resources) looks like this:

We will start with a verification tool which checks that there are no formatting errors in the email address, verifies DNS entries, looks for bogus or honeypot emails, and uses ping to check that the mailbox exists and can accept mail. This tool does not send any emails and won’t require any action on the part of the abuse contact.

After running the tool, emails that failed the test will be marked as invalid, and a ticket will be created for each of these in our system.

The next step is to follow-up with these abuse contacts. We will be looking to either identify working emails that seemed invalid, or otherwise have the resource holder update their contact information. We will send a validation link to each invalid abuse contact email along with a brief explanation of what this is all about. If our initial check has returned false positives and the email does work, the recipient can simply click this link to close the ticket and mark the email as valid. Simple.

If we have not received a response and the email remains unvalidated after one week, we will send a follow-up email to all of the LIR contacts. This will explain what we are doing and ask them to check their abuse mailbox, where they will find an updated validation email (the original link will have expired by now).

If we do not hear back and the email remains unvalidated, we will repeat this process two more times at one-week intervals.

If we still don’t hear anything back from the LIR after this third email, we will look for other ways to get in contact. We will try calling and may look for other emails we can use. Up until now, this process has been entirely automated. This will be the first point at which a RIPE NCC staff member gets involved.

If, at any point throughout this process, the LIR replies and says that they need more time, or asks for help to update this information (perhaps they need to reset their maintainer password) we will give them additional time or assistance as required. There is no hard deadline that we will be working to.

However, if we have still not received a response after this final attempt to contact the LIR, the issue will be escalated according to our existing procedure for LIRs that cannot be contacted.

Next steps

We have just about finalised our internal software implementation. Our next step is to get a sense of how many abuse contacts will be invalid and how responsive resource holders will be.

We will test this process on batches of a few hundred LIRs. An initial test with the validation tool suggests that around 20-25% of resource holders may need to validate or update their abuse contacts. Will most take action after the first couple of emails — or will we need to call them by phone? And how long will each of these cases take to resolve? These details will have implications for the amount of work that is ahead of us.

Based on the outcomes of these tests, we will present our Executive Board with a few different implementation options. We will aim to spread validation of the 70,000 abuse contacts across the entire year, making distinctions between the types of resources involved (LIRs vs End Users, for example).

We expect to finish our testing in another month or so, and will decide on a way forward before the end of the year. We plan to start the full validation in early Q1 2019.