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/[email protected]/
[anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
- Previous message (by thread): [anti-abuse-wg] Europol report on Cyber Crime threats IOCTA
- Next message (by thread): [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
denis walker
ripedenis at yahoo.co.uk
Thu Oct 5 01:54:44 CEST 2017
Colleagues I have read the proposal and all the comments. Many things have already been said. I will try to say something new, mostly on the technical issues. My first comment is as the co author of the original "abuse-c:" policy. It was clearly said during the discussion about that policy that it was ONLY intended to define a place to store abuse contact information in the RIPE Database. It was also said that further policies may be brought forward at a later time about validating the email addresses and/or enforcing action on abuse reports. So the lack of any validation does not undermine the existing policy. This was by design. This policy extension is about validating the email address in the "abuse-mailbox:" attribute. These will only exist in ROLE objects after the planned cleanup to be done soon. These ROLE objects are referenced by "abuse-c:" attributes in ORGANISATION objects and soon INET(6)NUM and AUT-NUM objects. They may also be unreferenced. There will be a default "abuse-c:" for all resources administered by the RIPE NCC. There will also be delegated "abuse-c:" attributes in a variety of places managed by or on behalf of customers of LIRs. It is not clear at all in this proposal which ones are going to be validated. Just the mandatory ones for resource holders or all of them? Validating all of them will be more challenging both technically and procedurally. But not validating them all may leave invalid data in the RPE Database. How will they be marked as invalid? Will this show up on a database query or in the information returned from the Abuse Finder or RIPEstat? Or is it for RIPE NCC internal use only? Will they only be marked as invalid because of a lack of response from the test email? What if someone informs the RIPE NCC of an invalid address? The new policy text says "attempt to correct the issue". Saying 'attempt' is a very weak statement. If the end result 'could be' deregistration then I think the policy should say something stronger like "the issue will be fixed". If that is the end goal then make it clear. There is some mention of 'complying with national laws'. Did you have a particular nation in mind or do you mean all nation's laws or just all those in the RIPE region? One of the supporting arguments is given as "Validating “abuse-c:” information is essential to ensure the efficiency of the abuse reporting system." It may be "helpful to the effectiveness" but it has nothing to do with efficiency. During the discussion it was said that using an auto responder would validate the email address in compliance with this policy. So anyone who doesn't intend to handle any abuse reports just needs to set up an auto responder, or even filter emails on "@ripe.net" or on some keyword/phrase in what will probably be a standard text and respond to that email. The data is valid and the RIPE NCC at least will get a response. But it is meaningless. Of course it will highlight those resource holders who are already serious about handling abuse but mistyped an address or forgot to update it. But resource holders who have no intention of responding to any abuse complaint can easily avoid any hassle from the RIPE NCC with this validation process. Also during this discussion it was said "The point is: if there is an auto-responder, there won't be an absolute and definitive invalidity of the answer. But additional investigations would be conducted, of course." Now I am not an expert on the inner workings of email clients. So do all auto responders add something to the email header to make it clear it is an auto response? Or can one be configured to send back an email looking as if I wrote it? If so what is going to trigger the 'additional investigations' for auto responses? I don't understand why possible deregistration is listed as an argument 'against' the proposal. The arguments listed as supporting the proposal, in my mind, read like a marketing brochure. I don't think that style of writing in this type of proposal is helpful...but that is just my opinion... Overall I neither support nor oppose the policy. I just wanted to highlight some issues. cheers denis From: Marco Schmidt <mschmidt at ripe.net> To: anti-abuse-wg at ripe.net Sent: Thursday, 7 September 2017, 13:59 Subject: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation) Dear colleagues, A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is now available for discussion. The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information and to follow up in cases where contact information is found to be invalid. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-02 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to <anti-abuse-wg at ripe.net> before 6 October 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20171004/c9289fa8/attachment.html>
- Previous message (by thread): [anti-abuse-wg] Europol report on Cyber Crime threats IOCTA
- Next message (by thread): [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]