[anti-abuse-wg] New on RIPE Labs: How We Will Be Validating abuse-c

Ronald,

To address one point; Legacy resources are excluded because that is the way that RIPE Policy works. It was not a choice of the NCC, rather it is a consequence of history and not something easily changed.

I should note there will also be a short presentation from the NCC about this work at our meeting next week.

Brian
Co-Chair, RIPE AAWG

Brian Nisbet 
Network Operations Manager
HEAnet CLG, Ireland's National Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland
+35316609040 brian.nisbet at heanet.ie www.heanet.ie
Registered in Ireland, No. 275301. CRA No. 20036270

> -----Original Message-----
> From: anti-abuse-wg <anti-abuse-wg-bounces at ripe.net> On Behalf Of
> Ronald F. Guilmette
> Sent: Wednesday 10 October 2018 21:08
> To: Mirjam Kuehne <mir at ripe.net>
> Cc: anti-abuse-wg at ripe.net
> Subject: Re: [anti-abuse-wg] New on RIPE Labs: How We Will Be Validating
> abuse-c
> 
> 
> In message <405d6ae2-ca13-57d4-4c8d-09e1166cec3d at ripe.net>,
> Mirjam Kuehne <mir at ripe.net> wrote:
> 
> >At the RIPE NCC we’re busy working out a process so we can start
> >validating approximately 70,000 abuse contact email addresses in the
> >RIPE Database. Read on RIPE Labs how we will approach this:
> >
> >https://labs.ripe.net/Members/angela_dallara/how-we-will-be-validating-
> >abuse-c
> 
> I am not persuaded that the following two bullet points, taken together,
> make any real sense:
> 
>      *  Legacy resources are not within the scope of the policy. We will
>         not be validating the abuse contacts for these resources.
> 
>      *  This process is about fixing invalid information -- we're not
>         looking to apply sanctions or close down members.
> 
> Given that there is, explicitly, no element of sanctions/punishment intended
> here, why on earth would you build and deploy an entire set of mechanisms
> to perform abuse-c validation, and then intentionally avoid using these new
> tools for some subset of all resource holders, even though they could clearly
> produce benefits in all cases?
> 
> Another question...  The above document says the following:
> 
>     THE PROCESS
> 
>      ...
>      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.
> 
> If you would be so kind, could you please flesh out your notion of the
> intended meaning of the word "ping" in this context?
> 
> Because your intent is to follow through and actually send email messages,
> after these initial and preliminary checks, perhaps I am just picking at nits
> here, but I would suggest that "ping" in the context might best be defined as
> a process, using SMTP, that actually checks all relevant MXes (in priority
> order, of course) to see if they will accept (or at least not permanently reject)
> a partial SMTP transaction where the RCPT TO is the address of the intended
> recipient, but where no DATA command is issued.
> 
> I have just one last point.  The above document also says:
> 
>      An initial test with the validation tool suggests that around 20-25%
>      of resource holders may need to validate or update their abuse contacts.
> 
> Some may not see it that way, but in my opinion that is certainly an
> encouraging preliminary result.  I would have guessed something more on
> the order of 50% of all abuse-c contacts would have issues.  I suspect
> however that the figure of 20-25% may rise significantly if this process is
> applied universally, as it should be, to all resource holders.
> 
> 
> Regards,
> rfg