Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi Alessandro A query on APNIC's web query form for 136.185.0.0/16 only specifies a single abuse email contact. The other email address in the rdap output is the "email:" attribute value from the referenced IRT object. That is not intended for abuse reports. When we implemented abuse-c in the RIPE Database, one of the underlying principles was to have a single process for documenting and finding abuse contact details. We specifically removed "abuse-mailbox:" from the IRT object, which APNIC still has. So you can't directly compare the two database outputs. There are many ways we can tweak the technical details of how abuse-c works in the RIPE Database. Rather than go round in circles discussing all possible permutations, perhaps it would be better if you specified the behaviour you would like to see. If others in the community agree, then the RIPE NCC can make the necessary technical changes. As long as we don't break that basic principle of having the one process for documenting and finding abuse contacts, each of which is singularly defined, anything else can be changed. cheers denis co-chair DB-WG On Mon, 14 Feb 2022 at 11:09, Alessandro Vesely wrote: > > Hi, > > On Thu 10/Feb/2022 22:40:18 +0100 denis walker wrote: > > > > Yes you can allow any customer with an assignment to have their own > > abuse-c contact. But the database query will only return a single > > abuse contact for any IP address. If the assignment object has an > > abuse-c then a query on any IP address in the range of that assignment > > will only return the customer's abuse contact details. If an > > assignment does not have an abuse-c then such a query will return the > > resource holder's abuse-contact details. A query will not return both > > the customer's and the resource holder's details. > > > Queries at ARIN or APNIC (and maybe more) often return multiple addresses. > For > example: > https://rdap.apnic.net/ip/136.185.8.145 > has two addresses, returned as two entries in the relevant vcardArray. > > > > However, this can be changed if the community wants something > > different. We can make abuse-c a multiple attribute so the resource > > holder can add the customer's and their own abuse-c to an assignment. > > Or we can change the default behaviour of the query so when an abuse-c > > is found in an assignment it always returns the resource holder's > > abuse-c as well. Or we can add a new query flag to return both abuse-c > > details when available. Or we can modify the abuse-c attribute in some > > way so the resource holder can choose what a query returns. Any > > behaviour is possible as long as you define what behaviour you want > > and the community finds it useful. > > > I don't know if the current settings allows to enter a comma-separated list as > an abuse-c string value. Most often, the abuse-c value is an email alias. > So, > I don't see why people would enter several addresses if they can manage the > aliases. > > IMHO, it makes more sense to store multiple addresses if they can be added by > different people. > > > jm2c > Ale > -- > > > > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/anti-abuse-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi, On Thu 10/Feb/2022 22:40:18 +0100 denis walker wrote: Yes you can allow any customer with an assignment to have their own abuse-c contact. But the database query will only return a single abuse contact for any IP address. If the assignment object has an abuse-c then a query on any IP address in the range of that assignment will only return the customer's abuse contact details. If an assignment does not have an abuse-c then such a query will return the resource holder's abuse-contact details. A query will not return both the customer's and the resource holder's details. Queries at ARIN or APNIC (and maybe more) often return multiple addresses. For example: https://rdap.apnic.net/ip/136.185.8.145 has two addresses, returned as two entries in the relevant vcardArray. However, this can be changed if the community wants something different. We can make abuse-c a multiple attribute so the resource holder can add the customer's and their own abuse-c to an assignment. Or we can change the default behaviour of the query so when an abuse-c is found in an assignment it always returns the resource holder's abuse-c as well. Or we can add a new query flag to return both abuse-c details when available. Or we can modify the abuse-c attribute in some way so the resource holder can choose what a query returns. Any behaviour is possible as long as you define what behaviour you want and the community finds it useful. I don't know if the current settings allows to enter a comma-separated list as an abuse-c string value. Most often, the abuse-c value is an email alias. So, I don't see why people would enter several addresses if they can manage the aliases. IMHO, it makes more sense to store multiple addresses if they can be added by different people. jm2c Ale -- -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi Michele Yes you can allow any customer with an assignment to have their own abuse-c contact. But the database query will only return a single abuse contact for any IP address. If the assignment object has an abuse-c then a query on any IP address in the range of that assignment will only return the customer's abuse contact details. If an assignment does not have an abuse-c then such a query will return the resource holder's abuse-contact details. A query will not return both the customer's and the resource holder's details. However, this can be changed if the community wants something different. We can make abuse-c a multiple attribute so the resource holder can add the customer's and their own abuse-c to an assignment. Or we can change the default behaviour of the query so when an abuse-c is found in an assignment it always returns the resource holder's abuse-c as well. Or we can add a new query flag to return both abuse-c details when available. Or we can modify the abuse-c attribute in some way so the resource holder can choose what a query returns. Any behaviour is possible as long as you define what behaviour you want and the community finds it useful. chears denis co-chair DB-WG On Thu, 10 Feb 2022 at 11:54, Michele Neylon - Blacknight wrote: > > That’s not entirely true. > > > > It’ll depend on how granular the LIR is with their allocations to their > clients. > > > > Speaking on behalf of my company we do assign blocks and abuse-c contacts to > quite a few of our clients. > > However we wouldn’t do that for every single IP address and due to the nature > of some of the services we provide a single IP address is going to be linked > to multiple clients. > > > > The main issue we run into is with some reporters using a scatter gun > approach with reporting abuse, which is just a waste of everyone’s time. > (Basically sending notices to every single contact they can find – not just > the abuse-c) > > > > Regards > > > > Michele > > > > > > > > -- > > Mr Michele Neylon > > Blacknight Solutions > > Hosting, Colocation & Domains > > https://www.blacknight.com/ > > https://blacknight.blog/ > > Intl. +353 (0) 59 9183072 > > Direct Dial: +353 (0)59 9183090 > > Personal blog: https://michele.blog/ > > Some thoughts: https://ceo.hosting/ > > --- > > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > > Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 > > > > > > From: anti-abuse-wg on behalf of Ángel > González Berdasco > Date: Saturday, 22 January 2022 at 23:12 > To: denis walker > Cc: anti-abuse-wg@ripe.net > Subject: Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c > > [EXTERNAL EMAIL] Please use caution when opening attachments from > unrecognised sources. > > > This bit is not possible. The "abuse-c:" attribute is 'single'. So the > > > resource object can only ever reference one abuse contact. > > > > Thanks Denis. abuse-c arity is a point I was dubious about. > > > > Thus, it is not currently possible to publish an abuse-c with the customer > address and keep the ISP copied at the same time, as desired. > > In order to know what is being sent thete, the ISP needs to provide its own > address and (if appropriate) forward complaints received there to the > customer. > > > > > > Best regards > > > > -- > > INCIBE-CERT - Spanish National CSIRT > > https://www.incibe-cert.es/ > > > > PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys > > > > > > > > INCIBE-CERT is the Spanish National CSIRT designated for citizens, > > private law entities, other entities not included in the subjective > > scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen > > Jurídico del Sector Público", as well as digital service providers, > > operators of essential services and critical operators under the terms > > of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de > > las redes y sistemas de información" that transposes the Directive (EU) > > 2016/1148 of the European Parliament and of the Council of 6 July 2016 > > concerning measures for a high common level of security of network and > > information systems across the Union. > > > > > > > > In compliance with the General Data Protection Regulation of the EU > > (Regulation EU 2016/679, of 27 April
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
That’s not entirely true. It’ll depend on how granular the LIR is with their allocations to their clients. Speaking on behalf of my company we do assign blocks and abuse-c contacts to quite a few of our clients. However we wouldn’t do that for every single IP address and due to the nature of some of the services we provide a single IP address is going to be linked to multiple clients. The main issue we run into is with some reporters using a scatter gun approach with reporting abuse, which is just a waste of everyone’s time. (Basically sending notices to every single contact they can find – not just the abuse-c) Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: anti-abuse-wg on behalf of Ángel González Berdasco Date: Saturday, 22 January 2022 at 23:12 To: denis walker Cc: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. > This bit is not possible. The "abuse-c:" attribute is 'single'. So the > resource object can only ever reference one abuse contact. Thanks Denis. abuse-c arity is a point I was dubious about. Thus, it is not currently possible to publish an abuse-c with the customer address and keep the ISP copied at the same time, as desired. In order to know what is being sent thete, the ISP needs to provide its own address and (if appropriate) forward complaints received there to the customer. Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to d...@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
> This bit is not possible. The "abuse-c:" attribute is 'single'. So the > resource object can only ever reference one abuse contact. Thanks Denis. abuse-c arity is a point I was dubious about. Thus, it is not currently possible to publish an abuse-c with the customer address and keep the ISP copied at the same time, as desired. In order to know what is being sent thete, the ISP needs to provide its own address and (if appropriate) forward complaints received there to the customer. Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to d...@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi Angel On Sat, 22 Jan 2022 at 21:47, Ángel González Berdasco wrote: > > Alessandro Vesely wrote: > > > > And, if yes, would it be acceptable by the resource holder or are > > > > there > > > > contractual impediments? Finally, if feasibility is ok, would > > > > operators > > > > take advantage of it or is it only me? > > > > > > > If you are talking about adding extra abuse addresses to assignment > > > objects by agreement with the resource holder, as I explained, that > > > is > > > possible now by simply adding an abuse-c to the assignment . > > > > > > Except that I don't have write access to the assignment object. > > > > > > Best > > Ale > > > I'm not an expert on all the supported RIPE db details, but I think you > could have an abuse contact object, that you could modify, This bit is possible. The ROLE object containing the "abuse-mailbox:" can be maintained by the end user so they can set their own email address and change it whenever they wish. > with the > main resource linking to your abuse contact plus the ISP one. This bit is not possible. The "abuse-c:" attribute is 'single'. So the resource object can only ever reference one abuse contact. cheers denis co-chair DB-WG > > I find that abuse contacts are fairly static ones (if not directly > following rfc2142), so the client need to write to it is probably not a > very relevant use case. Maybe some weird setup, such as if you wanted > to present a dynamic abuse contact that changed every day- > > -- > INCIBE-CERT - Spanish National CSIRT > https://www.incibe-cert.es/ > > PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Alessandro Vesely wrote: > > > And, if yes, would it be acceptable by the resource holder or are > > > there > > > contractual impediments? Finally, if feasibility is ok, would > > > operators > > > take advantage of it or is it only me? > > > > > If you are talking about adding extra abuse addresses to assignment > > objects by agreement with the resource holder, as I explained, that > > is > > possible now by simply adding an abuse-c to the assignment . > > > Except that I don't have write access to the assignment object. > > > Best > Ale I'm not an expert on all the supported RIPE db details, but I think you could have an abuse contact object, that you could modify, with the main resource linking to your abuse contact plus the ISP one. I find that abuse contacts are fairly static ones (if not directly following rfc2142), so the client need to write to it is probably not a very relevant use case. Maybe some weird setup, such as if you wanted to present a dynamic abuse contact that changed every day- -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to d...@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
On Fri 21/Jan/2022 14:21:41 +0100 Hans-Martin Mosner wrote: Am 20.01.22 um 13:37 schrieb Alessandro Vesely: However, it is the ISPs' customers who are the effective users of those IPs. Any complaint, whether reporting spam or botnet activity, can probably be handled more effectively by the people who run the systems connected to a given IP than the actual owner. In a considerable amount of cases, the ISP's customer is also the spammer. I would prefer not to talk to them when complaining about their behavior - in the best case, they will ignore me, in the worst case, they might do something in revenge. That makes sense when you're reporting spam. Botnet activity differs. If RDAP data allows to recognize which abuse contact belongs to which kind of operator, tools can accept options to output either one or both. The IP owner is the one who can pull the plug on misbehaving customers. As it is much easier to identify IP owners, I can collect reputation data about who I can trust to handle my abuse complaint responsibly, who will just ignore it, who will forward it unedited to their customer. Depending on this assessment of their trustworthiness, I will or won't report. Wow! I just collect those which bounce. Some send some feedback, and in a minority of those cases I seem to be able to grasp that they actually do something to mitigate reported abuse. There are very few cases where reporting to end users makes much sense. Either they operate their system responsibly including monitoring the mail rejects and bounces, then they already know there's something that needs to be fixed, or they don't, and most often don't care, and my complaint will probably not change that. Some operators say they refuse abuse reporting by email because they want complainants to fill web forms. Of course, web forms have fields that provide for better handling. However, the only handling I can think of is to associate the IP field to the corresponding customer and automatically forward the complaint there. That could be done by RDAP. Best Ale -- -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi, On Fri 21/Jan/2022 19:40:40 +0100 denis walker wrote: On Fri, 21 Jan 2022 at 13:03, Alessandro Vesely wrote: The idea is to add extra addresses to assignment objects, irrespective of the resource holder, based on the wish of its customer who is actually connected to the resource. Would that be at all possible? When you say " irrespective of the resource holder, based on the wish of its customer" do you mean without their consent or control? That is not possible as they maintain the assignment object. I would also say it is not desirable. That would allow an abuser to override the resource holders abuse-c and ignore all abuse reports. Yes, I meant extra attributes linked to the assignment object. If it's not possible let's just forget it. And, if yes, would it be acceptable by the resource holder or are there contractual impediments? Finally, if feasibility is ok, would operators take advantage of it or is it only me? > If you are talking about adding extra abuse addresses to assignment objects by agreement with the resource holder, as I explained, that is possible now by simply adding an abuse-c to the assignment . Except that I don't have write access to the assignment object. Best Ale -- -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi Alessandro On Fri, 21 Jan 2022 at 13:03, Alessandro Vesely wrote: > > Hi Denis, > > I followed the discussion, and got a rough idea of how it works. At the time, > I succeeded convincing my ISP (Eutelia) to assign an abuse-mailbox to me. > Afterwards the policy changed, but meanwhile my ISP went belly up and I > couldn't convince the new one to set abuse-c for me. > > The idea is to add extra addresses to assignment objects, irrespective of the > resource holder, based on the wish of its customer who is actually connected > to > the resource. Would that be at all possible? When you say " irrespective of the resource holder, based on the wish of its customer" do you mean without their consent or control? That is not possible as they maintain the assignment object. I would also say it is not desirable. That would allow an abuser to override the resource holders abuse-c and ignore all abuse reports. > And, if yes, would it be > acceptable by the resource holder or are there contractual impediments? > Finally, if feasibility is ok, would operators take advantage of it or is it > only me? If you are talking about adding extra abuse addresses to assignment objects by agreement with the resource holder, as I explained, that is possible now by simply adding an abuse-c to the assignment . cheers denis co-chair DB-WG > > > Best > ale > > > On Thu 20/Jan/2022 16:18:10 +0100 denis walker wrote: > > Hi Alessandro > > > > Do you realise that abuse-c works hierarchically? The resource holder > > is required to have an abuse-c in their ORGANISATION object as a > > default. It was agreed by the community a few years ago to allow > > additional abuse-c attributes in the resource objects. So if an end > > user wants to receive abuse reports for their network the resource > > holder can add an additional abuse-c attribute into the assignment > > object (which is usually maintained by the resource holder). The abuse > > ROLE object can be maintained by the end user so they can set their > > own abuse email address. A query will only return the closest abuse > > email address to any given IP address. So for any address in the end > > user's range it will return their abuse email. > > > > cheers > > denis > > co-chair DB-WG > > > > On Thu, 20 Jan 2022 at 13:37, Alessandro Vesely wrote: > >> > >> Hi all, > >> > >> we all know abuse-c data is to be filled by the IP assignee, which I call > >> ISP > >> in the following. > >> > >> I understand that, since ISPs own IP space it is their job to ensure that > >> it > >> isn't abused. If they give up the receiving of abuse complaints and give > >> it to > >> their customer instead, and they don't receive the complaints as a result, > >> then > >> they won't be aware if their customer is violating important policies. > >> > >> However, it is the ISPs' customers who are the effective users of those > >> IPs. > >> Any complaint, whether reporting spam or botnet activity, can probably be > >> handled more effectively by the people who run the systems connected to a > >> given > >> IP than the actual owner. > >> > >> I propose that RIPE accepts abuse-c email addresses from verified effective > >> users of a range of IP numbers, stores them in the database, and serves > >> them in > >> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP. > >> Various > >> automated methods can be adopted to allow an effective user to be > >> verified; for > >> example publishing an HTTP URL or a DNS entry. Abuse contacts added that > >> way > >> can expire after a few months, forcing the effective user to renew them, > >> so as > >> to avoid stale entries. > >> > >> I'm unsure if the above requires proposing a new policy or what else. For > >> the > >> time being, it would be interesting to gauge if this WG likes the idea and > >> if > >> there are effective users, apart from me, who would be interested in > >> publishing > >> their abuse-c. > >> > >> > >> Best > >> Ale > >> -- > >> > >> > >> > >> > >> > >> -- > >> > >> To unsubscribe from this mailing list, get a password reminder, or change > >> your subscription options, please visit: > >> https://lists.ripe.net/mailman/listinfo/anti-abuse-wg > > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Am 20.01.22 um 13:37 schrieb Alessandro Vesely: However, it is the ISPs' customers who are the effective users of those IPs. Any complaint, whether reporting spam or botnet activity, can probably be handled more effectively by the people who run the systems connected to a given IP than the actual owner. In a considerable amount of cases, the ISP's customer is also the spammer. I would prefer not to talk to them when complaining about their behavior - in the best case, they will ignore me, in the worst case, they might do something in revenge. The IP owner is the one who can pull the plug on misbehaving customers. As it is much easier to identify IP owners, I can collect reputation data about who I can trust to handle my abuse complaint responsibly, who will just ignore it, who will forward it unedited to their customer. Depending on this assessment of their trustworthiness, I will or won't report. There are very few cases where reporting to end users makes much sense. Either they operate their system responsibly including monitoring the mail rejects and bounces, then they already know there's something that needs to be fixed, or they don't, and most often don't care, and my complaint will probably not change that. Cheers, Hans-Martin -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi Ángel, On Thu 20/Jan/2022 16:27:59 +0100 Ángel González Berdasco wrote: Alessandro Vesely wrote: I propose that RIPE accepts abuse-c email addresses from verified effective users of a range of IP numbers, stores them in the database, and serves them in RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP. Various automated methods can be adopted to allow an effective user to be verified; for example publishing an HTTP URL or a DNS entry. Abuse contacts added that way can expire after a few months, forcing the effective user to renew them, so as to avoid stale entries. I think you should describe how this proposal differs from what is available nowadays. Wouldn't they already be able to configure verified effective users for the IP addresses (e.g. with an abuse-c of the client and another of theirs) ? They may be unwilling to do so or consider it a hurdle, requiring them to create new objects and so on, but what makes you believe they would be willing to use that new system? Curiously, IME, they're keen on doing RFC 2317 delegations, but refrain from assigning abuse-c attributes. I don't know if those belong to different departments or if there's just a different policy. The concept that they are safer holding abuse-c for themselves was expressed on mailop recently. If I were an ISP, I'd set up different abuse-c addresses for each customer, something like abuse-customer@isp.example, with possible auto-forward to a customer supplied address. But I'm not. RDAP allows some leeway in responses, so that something could be set to indicate whether a vcard entry belongs to the ISP or to the final operator. I don't think ARIN or other RIRs are already featuring that kind of facility. Is it because nobody asked? Best Ale -- -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi Denis, I followed the discussion, and got a rough idea of how it works. At the time, I succeeded convincing my ISP (Eutelia) to assign an abuse-mailbox to me. Afterwards the policy changed, but meanwhile my ISP went belly up and I couldn't convince the new one to set abuse-c for me. The idea is to add extra addresses to assignment objects, irrespective of the resource holder, based on the wish of its customer who is actually connected to the resource. Would that be at all possible? And, if yes, would it be acceptable by the resource holder or are there contractual impediments? Finally, if feasibility is ok, would operators take advantage of it or is it only me? Best ale On Thu 20/Jan/2022 16:18:10 +0100 denis walker wrote: Hi Alessandro Do you realise that abuse-c works hierarchically? The resource holder is required to have an abuse-c in their ORGANISATION object as a default. It was agreed by the community a few years ago to allow additional abuse-c attributes in the resource objects. So if an end user wants to receive abuse reports for their network the resource holder can add an additional abuse-c attribute into the assignment object (which is usually maintained by the resource holder). The abuse ROLE object can be maintained by the end user so they can set their own abuse email address. A query will only return the closest abuse email address to any given IP address. So for any address in the end user's range it will return their abuse email. cheers denis co-chair DB-WG On Thu, 20 Jan 2022 at 13:37, Alessandro Vesely wrote: Hi all, we all know abuse-c data is to be filled by the IP assignee, which I call ISP in the following. I understand that, since ISPs own IP space it is their job to ensure that it isn't abused. If they give up the receiving of abuse complaints and give it to their customer instead, and they don't receive the complaints as a result, then they won't be aware if their customer is violating important policies. However, it is the ISPs' customers who are the effective users of those IPs. Any complaint, whether reporting spam or botnet activity, can probably be handled more effectively by the people who run the systems connected to a given IP than the actual owner. I propose that RIPE accepts abuse-c email addresses from verified effective users of a range of IP numbers, stores them in the database, and serves them in RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP. Various automated methods can be adopted to allow an effective user to be verified; for example publishing an HTTP URL or a DNS entry. Abuse contacts added that way can expire after a few months, forcing the effective user to renew them, so as to avoid stale entries. I'm unsure if the above requires proposing a new policy or what else. For the time being, it would be interesting to gauge if this WG likes the idea and if there are effective users, apart from me, who would be interested in publishing their abuse-c. Best Ale -- -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Alessandro Vesely wrote: > Hi all, > > (...) > > I propose that RIPE accepts abuse-c email addresses from verified effective > users of a range of IP numbers, stores them in the database, and serves them > in > RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP. > Various > automated methods can be adopted to allow an effective user to be verified; > for > example publishing an HTTP URL or a DNS entry. Abuse contacts added that way > can expire after a few months, forcing the effective user to renew them, so > as > to avoid stale entries. Hello Ale I think you should describe how this proposal differs from what is available nowadays. Wouldn't they already be able to configure verified effective users for the IP addresses (e.g. with an abuse-c of the client and another of theirs) ? They may be unwilling to do so or consider it a hurdle, requiring them to create new objects and so on, but what makes you believe they would be willing to use that new system? Best -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to d...@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi Alessandro Do you realise that abuse-c works hierarchically? The resource holder is required to have an abuse-c in their ORGANISATION object as a default. It was agreed by the community a few years ago to allow additional abuse-c attributes in the resource objects. So if an end user wants to receive abuse reports for their network the resource holder can add an additional abuse-c attribute into the assignment object (which is usually maintained by the resource holder). The abuse ROLE object can be maintained by the end user so they can set their own abuse email address. A query will only return the closest abuse email address to any given IP address. So for any address in the end user's range it will return their abuse email. cheers denis co-chair DB-WG On Thu, 20 Jan 2022 at 13:37, Alessandro Vesely wrote: > > Hi all, > > we all know abuse-c data is to be filled by the IP assignee, which I call ISP > in the following. > > I understand that, since ISPs own IP space it is their job to ensure that it > isn't abused. If they give up the receiving of abuse complaints and give it > to > their customer instead, and they don't receive the complaints as a result, > then > they won't be aware if their customer is violating important policies. > > However, it is the ISPs' customers who are the effective users of those IPs. > Any complaint, whether reporting spam or botnet activity, can probably be > handled more effectively by the people who run the systems connected to a > given > IP than the actual owner. > > I propose that RIPE accepts abuse-c email addresses from verified effective > users of a range of IP numbers, stores them in the database, and serves them > in > RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP. > Various > automated methods can be adopted to allow an effective user to be verified; > for > example publishing an HTTP URL or a DNS entry. Abuse contacts added that way > can expire after a few months, forcing the effective user to renew them, so as > to avoid stale entries. > > I'm unsure if the above requires proposing a new policy or what else. For the > time being, it would be interesting to gauge if this WG likes the idea and if > there are effective users, apart from me, who would be interested in > publishing > their abuse-c. > > > Best > Ale > -- > > > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/anti-abuse-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
[anti-abuse-wg] Proposal: Publish effective users' abuse-c
Hi all, we all know abuse-c data is to be filled by the IP assignee, which I call ISP in the following. I understand that, since ISPs own IP space it is their job to ensure that it isn't abused. If they give up the receiving of abuse complaints and give it to their customer instead, and they don't receive the complaints as a result, then they won't be aware if their customer is violating important policies. However, it is the ISPs' customers who are the effective users of those IPs. Any complaint, whether reporting spam or botnet activity, can probably be handled more effectively by the people who run the systems connected to a given IP than the actual owner. I propose that RIPE accepts abuse-c email addresses from verified effective users of a range of IP numbers, stores them in the database, and serves them in RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP. Various automated methods can be adopted to allow an effective user to be verified; for example publishing an HTTP URL or a DNS entry. Abuse contacts added that way can expire after a few months, forcing the effective user to renew them, so as to avoid stale entries. I'm unsure if the above requires proposing a new policy or what else. For the time being, it would be interesting to gauge if this WG likes the idea and if there are effective users, apart from me, who would be interested in publishing their abuse-c. Best Ale -- -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
