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] working in new version of 2019-04 (Validation of "abuse-mailbox")
- Previous message (by thread): [anti-abuse-wg] working in new version of 2019-04 (Validation of "abuse-mailbox")
- Next message (by thread): [anti-abuse-wg] working in new version of 2019-04 (Validation of "abuse-mailbox")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Briaut René
rbriaut at wanadoo.fr
Fri Jan 17 13:40:16 CET 2020
STOP SPAM Envoyé de mon iPhone par René Briaut Le 17 janv. 2020 à 13:04, Volker Greimann <vgreimann at key-systems.net> a écrit : Hmm, if you include RIPE NCC in all responses, you will greatly increase the overhead and noise to signal ratio it has to deal with. It may be better to maintain the ability to audit the responses. instead of receiving them all. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. > On Fri, Jan 17, 2020 at 12:00 PM JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg at ripe.net> wrote: > I will be fine with this (having RIPE NCC as an intermediator just to send the abuse report), if instead of a web form (or in addition to it), it is possible to automate it, for example RIPE NCC also accepts x-arf via email. > > RIPE NCC has the obligation to keep the information without disclosing it, so why we need to have a way to encypt it so RIPE NCC can’t read it? Furthermore, this should be an automated process. The staff is not going to handle every report manually. And moreover, in case of a bigger dispute, even if going to the courts, RIPE NCC can provide in a neutral way all the info of what happened. > > However, I’ve the feeling that in order to get this working, the policy must mandate that all the responser from the operator which customer is producing the abuse, also follow the same path, so: > > Abuse reporter (Victim or its ISP) -> RIPE NCC -> abuser operator -> RIPE NCC -> abuse reporter > > Otherwise, there will not be a way for RIPE to have stats of who is responding to abuse cases and who is not, or even simpler than that, what abuse mailboxes get bounced (which will be a policy violation if happens all the time with the same operator). Never mind we decide or not that not-responding is an abuse-c violation. Stats are good, even if not published with operator names. > > > > El 17/1/20 1:12, "anti-abuse-wg en nombre de ripedenis--- via anti-abuse-wg" <anti-abuse-wg-bounces at ripe.net en nombre de anti-abuse-wg at ripe.net> escribió: > > > > Hi Sergio > > > > As I read through this thread similar ideas came to my mind. The question I would ask is "Is it too late to take a completely different approach to abuse contacts and reporting via the RIPE Database?" > > > > Suppose we had a standard form available via the ripe.net website for providing details of abuse. If you are able to find the "abuse-c:" details in the database now then you must know the IP address involved. The RIPE NCC could send the report to the abuse contact taken from the database via the specified IP address. This does not have to be an email interface either. We could look at other options. The RIPE NCC would then at least know if the report was successfully delivered. Using a standard form would make it much easier for the resource holder to interpret the information. > > > > Someone said: > > "Making such a scheme compulsory would be unacceptable to people who wish to interact with network owners without disclosing that in public ..." > > I have no understanding of the technology involved here, but when I send you a message on WhatsApp it is encrypted end to end. WhatsApp have no idea (they say) of the content of the message. Would it be possible to submit a form on ripe.net in a way that the content of that form is encrypted and sent to the resource holder so the RIPE NCC have no idea of the content of the form? That would satisfy this concern. > > > > Regardless of the outcome of the RIPE Database Requirements Task Force, something like this could still be implemented as it is external to the RIPE Database. > > > > Food for thought... > > > > cheers > > > > denis > > > > co-chair DB-WG > > > > > > On Wednesday, 15 January 2020, 10:22:28 CET, Sérgio Rocha <sergio.rocha at makeitsimple.pt> wrote: > > > > > > Hi, > > Maybe we can change the approach. > If RIPE website had a platform to post abuse report, that send the email for > the abuse contact, it will be possible to evaluate the responsiveness of the > abuse contact. > > This way anyone that report an abuse could assess not only the response but > also the effectiveness of the actions taken by the network owner. After some > time with this evaluations we would easy to realize who manages the reports > and even who does not respond at all. > > Sérgio > > > -----Original Message----- > From: anti-abuse-wg [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of > Gert Doering > Sent: 15 de janeiro de 2020 08:06 > To: Carlos Friaças <cfriacas at fccn.pt> > Cc: Gert Doering <gert at space.net>; anti-abuse-wg <anti-abuse-wg at ripe.net> > Subject: Re: [anti-abuse-wg] working in new version of 2019-04 (Validation > of "abuse-mailbox") > > Hi, > > On Wed, Jan 15, 2020 at 07:23:38AM +0000, Carlos Friaças via anti-abuse-wg > wrote: > > I obviously don't speak for the incident handling community, but i > > think this (making it optional) would be a serious step back. The > > current situation is already very bad when in some cases we know from > > the start that we are sending (automated) messages/notices to blackholes. > > So why is it preferrable to send mails which are not acted on, as opposed to > "not send mail because you know beforehand that the other network is not > interested"? > > I can see that it is frustrating - but I still cannot support a policy > change which will not help dealing with irresponsible networks in any way, > but at the same time increases costs and workload for those that do the > right thing alrady. > > > > To an extreme, there should always be a known contact responsible for > > any network infrastructure. If this is not the case, what's the > > purpose of a registry then? > > "a known contact" and "an *abuse-handling* contact" is not the same thing. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20200117/1a7e5557/attachment.html>
- Previous message (by thread): [anti-abuse-wg] working in new version of 2019-04 (Validation of "abuse-mailbox")
- Next message (by thread): [anti-abuse-wg] working in new version of 2019-04 (Validation of "abuse-mailbox")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]