This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] New on RIPE Labs: How We Will Be Validating abuse-c
- Previous message (by thread): [anti-abuse-wg] New on RIPE Labs: How We Will Be Validating abuse-c
- Next message (by thread): [anti-abuse-wg] New on RIPE Labs: How We Will Be Validating abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Wed Oct 10 22:07:46 CEST 2018
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
- Previous message (by thread): [anti-abuse-wg] New on RIPE Labs: How We Will Be Validating abuse-c
- Next message (by thread): [anti-abuse-wg] New on RIPE Labs: How We Will Be Validating abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]