Re: [anti-abuse-wg] Spamming LIR accounts
- On May 12, 2020, at 12:51 PM, Randy Bush ra...@psg.com wrote: Hi Randy, > would those helpful folk kindly giving us legal opinions please tell us > your legal credentials? Fair point. I dropped out of law school in my third year. I liked engineering more. Strongly considering to go back and add "J.D." to my list of credentials tho. Also, my MBA program consisted of 30% law and regulations related courses. However, I'm sure Anne-of-many-titles and any other person that actually did graduate will agree with my analysis. The concept of personal jurisdiction in the U.S. (and its associated challenges) is something that was discussed during the first year. That said, you are totally right in ignoring all of my legal bla-bla. In the end, only a real court case will decide the matter. IANALYET. Thanks, Sabri Berisha, M.Sc, MBA, JNCIE #261
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Hi Petrit, all, Thanks a lot for the clarification. I only discovered that once I was working on the slide for tomorrow, as during the previous days discussion I always used my original word proposal document. I had the feeling that some of the points that we discussed in the last days were misunderstood because there was a "reinforcement or duplication" of the policy text, while it was meant as a clarification. I will make sure to clarify it tomorrow during the WG presentation. Regards, Jordi @jordipalet El 13/5/20 17:58, "anti-abuse-wg en nombre de Petrit Hasani" escribió: Dear colleagues, The proposer has alerted us to a mistake in the “Draft Document” prepared for policy proposal 2019-04: https://www.ripe.net/participate/policies/proposals/2019-04/draft The “Additional information” section in the draft document is part of the proposal and should not be included in the actual policy text. We will update the draft document to remove this section. This means that this section would not be part of the policy text if the proposal is accepted. Please note that the policy proposal itself is not changed - the "Additional information" section remains a part of the proposal: https://www.ripe.net/participate/policies/proposals/2019-04 Kind regards, -- Petrit Hasani Policy Officer RIPE NCC > On 28 Apr 2020, at 16:01, Petrit Hasani wrote: > > Dear colleagues, > > A new version of RIPE policy proposal, 2019-04, "Validation of > "abuse-mailbox"", is now available for discussion. > > This proposal aims to have the RIPE NCC validate "abuse-c:" information > more often and introduces a new validation process. > > Most of the text has been rewritten following the last round of > discussion and the proposal is now at version 3.0. Some key points in > this version: > > - The abuse-mailbox should not force the sender to use a form > - The validation process must ensure that the abuse mailbox is able to > receive messages > - The validation should happen at least every six months > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-04 > > 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 Anti-Abuse Working Group Chairs, will decide how to proceed with the > proposal. > > We encourage you to review this proposal and send your comments to > before 27 May 2020. > > Kind regards, > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > > ** 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.
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Hi Alessandro,
I just read Marco response to this thread (Marco thanks for the quick reaction
on it!), and also Angel response (so to avoid answering to several emails about
the same).
I guess all your other inputs are also relevant for the NCC.
In principle, I don't think all that should be part of the policy proposal, but
if the NCC seems otherwise, I'm happy to work with you/Angel/others to make
sure that we have captured correctly that and see what the WG believes.
Thanks!
Regards,
Jordi
@jordipalet
El 13/5/20 13:02, "anti-abuse-wg en nombre de Alessandro Vesely"
escribió:
Hi Jordy,
On Tue 12/May/2020 22:21:11 +0200 JORDI PALET MARTINEZ via anti-abuse-wg
wrote:
> El 12/5/20 19:26, "anti-abuse-wg en nombre de Alessandro Vesely"
escribió:
>
> I think it is more useful instead of removing the address, marking the
> record as invalid, and this is being done if I recall correctly from RIPE
> NCC presentations. Because it may be a temporary failure of the address,
so
> *not removing it* may bring it back in a subsequent verification.
If at all possible, I'd suggest to register a suitable RDAP JSON value for
the
relevant remark type, at IANA[*]. That would allow automated tools to
discard
the corresponding vcard entry.
ARIN write a remark, like so:
"remarks" : [
{
"description" : [
"ARIN has attempted to validate the data for this POC, but has
received no response from the POC since 2011-06-07"
],
"title" : "Unvalidated POC"
}
],
Such remark is not quite actionable, as it doesn't say which POC does not
work
(recall there are various arrays of vcards, only some of which are tagged
with
the "abuse" role.) Perhaps more importantly, it doesn't say if the invalid
nature of the mailbox was notified to the responsible organization, and such
notification acknowledged.
> [Jordi] I think both [actual validity and statistics] are useful to know.
Is
> the address valid/invalid. If valid, is this LIR processing abuse reports
or
> there is information escalated from the community that is not?
The latter datum is much more difficult to get right. I'd stick with an
invalid mark. If, say, email messages bounced since 2011, and the
organization
was promptly notified and shrugged, a loud and clear mark is well deserved.
> [Jordi] Totally agree. I still think ideally, we should have X-ARF as the
> single way to do all the abuse reporting. Not sure if this could be also
> connected to provide feedback to DNSBL, but I'm not convinced RIPE NCC (or
> any other RIR) could do that ... very difficult to reach consensus on that
> at the time being. The stats might prove that on the long term and then we
> can change our minds.
The format, like the actual handling of reports, is one or more levels
above.
As for a DNSBL, I keep reading that most data in the RIPE Database is
public.
Are there API to browse its content? Is it possible to maintain a
(filtered)
copy of it? If one could collect all the blocks whose abuse-c is marked as
invalid, she could then run a corresponding DNSBL. However, article 3 of
the
Terms and Conditions for Data Access[†] seems to disallow just that.
Best
Ale
--
[*] https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml
[†] https://labs.ripe.net/datarepository/conditions/basic
**
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.
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Dear colleagues, The proposer has alerted us to a mistake in the “Draft Document” prepared for policy proposal 2019-04: https://www.ripe.net/participate/policies/proposals/2019-04/draft The “Additional information” section in the draft document is part of the proposal and should not be included in the actual policy text. We will update the draft document to remove this section. This means that this section would not be part of the policy text if the proposal is accepted. Please note that the policy proposal itself is not changed - the "Additional information" section remains a part of the proposal: https://www.ripe.net/participate/policies/proposals/2019-04 Kind regards, -- Petrit Hasani Policy Officer RIPE NCC > On 28 Apr 2020, at 16:01, Petrit Hasani wrote: > > Dear colleagues, > > A new version of RIPE policy proposal, 2019-04, "Validation of > "abuse-mailbox"", is now available for discussion. > > This proposal aims to have the RIPE NCC validate "abuse-c:" information > more often and introduces a new validation process. > > Most of the text has been rewritten following the last round of > discussion and the proposal is now at version 3.0. Some key points in > this version: > > - The abuse-mailbox should not force the sender to use a form > - The validation process must ensure that the abuse mailbox is able to > receive messages > - The validation should happen at least every six months > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-04 > > 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 Anti-Abuse Working Group Chairs, will decide how to proceed with the > proposal. > > We encourage you to review this proposal and send your comments to > before 27 May 2020. > > Kind regards, > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > > signature.asc Description: Message signed with OpenPGP
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
El mié, 13-05-2020 a las 15:11 +0200, Marco Schmidt escribió: > Hello Jordi, > > Allow me to respond as this is a more an operational topic. > > I agree with you that RIPE policies should provide the general > framework, while the RIPE NCC works out the best operational details > to > apply the policies. > > In the mentioned example the procedure has worked, as the contact > was > identified and marked as invalid. > Ed has clarified already that after the RIPE 80 meeting, we will work > on > adding this information also to the RIPE RDAP service. > > Thank you and Angel once more for bringing this to our attention. > > Kind regards, > Marco Schmidt > RIPE NCC You are welcome, Edward, Marco. I only noticed that such note was missing from rdap when I was going to show here that it an example of contact marked as invalid by RIPE process. Long-term, Alessandro proposal of having a field for tagging the contact status as (probably) not-working seems the way to go (not sure who should propose that to IANA), but storing it in a comment would allow for a quick solution in the interim. Best regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute 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.
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Hello Jordi, Allow me to respond as this is a more an operational topic. I agree with you that RIPE policies should provide the general framework, while the RIPE NCC works out the best operational details to apply the policies. In the mentioned example the procedure has worked, as the contact was identified and marked as invalid. Ed has clarified already that after the RIPE 80 meeting, we will work on adding this information also to the RIPE RDAP service. Thank you and Angel once more for bringing this to our attention. Kind regards, Marco Schmidt RIPE NCC On 13/05/2020 09:05, JORDI PALET MARTINEZ via anti-abuse-wg wrote: Clearly something that RIPE NCC should improve in their procedures (or at least explain if there is any issue doing so), but I don't think we need to include those procedural details in the policy proposal. What do you think Petrit? Regards, Jordi @jordipalet El 13/5/20 0:46, "anti-abuse-wg en nombre de Ángel González Berdasco" escribió: El mar, 12-05-2020 a las 22:21 +0200, JORDI PALET MARTINEZ via anti- abuse-wg escribió: > You misunderstood me. I'm not advocating de-registration of IP > resources. I > meant to remove just the abuse-c email address, since it does not > work. As an > alternative, as Àngel noted, there could be a tag saying that the > email address > is not valid, without actually removing it. > > [Jordi] I got your point now, thanks! > > I think it is more useful instead of removing the address, marking > the record as invalid, and this is being done if I recall correctly > from RIPE NCC presentations. 5.135.48.50is one of such IP addresses. It has as abuse-c ab...@for-ns.com, which is trivially invalid: for- ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25 Port 43 access provides: > % Information related to '5.135.48.48 - 5.135.48.51' > > % Abuse contact for '5.135.48.48 - 5.135.48.51' is 'ab...@for-ns.com' > % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for > further information. I am unable to see such piece of information on the RDAP view, though: https://rdap.db.ripe.net/ip/5.135.48.48 Best regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute 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. Disclaimer: This message may contain confidential information, within the framework of the corporate Security Management System.If you are not the intended recipient, please notify the sender and delete this message without forwarding or retaining a copy, since any unauthorized use is strictly prohibited by law. ** 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.
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Hi Jordy,
On Tue 12/May/2020 22:21:11 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote:
> El 12/5/20 19:26, "anti-abuse-wg en nombre de Alessandro Vesely"
> escribió:
>
> I think it is more useful instead of removing the address, marking the
> record as invalid, and this is being done if I recall correctly from RIPE
> NCC presentations. Because it may be a temporary failure of the address, so
> *not removing it* may bring it back in a subsequent verification.
If at all possible, I'd suggest to register a suitable RDAP JSON value for the
relevant remark type, at IANA[*]. That would allow automated tools to discard
the corresponding vcard entry.
ARIN write a remark, like so:
"remarks" : [
{
"description" : [
"ARIN has attempted to validate the data for this POC, but has
received no response from the POC since 2011-06-07"
],
"title" : "Unvalidated POC"
}
],
Such remark is not quite actionable, as it doesn't say which POC does not work
(recall there are various arrays of vcards, only some of which are tagged with
the "abuse" role.) Perhaps more importantly, it doesn't say if the invalid
nature of the mailbox was notified to the responsible organization, and such
notification acknowledged.
> [Jordi] I think both [actual validity and statistics] are useful to know. Is
> the address valid/invalid. If valid, is this LIR processing abuse reports or
> there is information escalated from the community that is not?
The latter datum is much more difficult to get right. I'd stick with an
invalid mark. If, say, email messages bounced since 2011, and the organization
was promptly notified and shrugged, a loud and clear mark is well deserved.
> [Jordi] Totally agree. I still think ideally, we should have X-ARF as the
> single way to do all the abuse reporting. Not sure if this could be also
> connected to provide feedback to DNSBL, but I'm not convinced RIPE NCC (or
> any other RIR) could do that ... very difficult to reach consensus on that
> at the time being. The stats might prove that on the long term and then we
> can change our minds.
The format, like the actual handling of reports, is one or more levels above.
As for a DNSBL, I keep reading that most data in the RIPE Database is public.
Are there API to browse its content? Is it possible to maintain a (filtered)
copy of it? If one could collect all the blocks whose abuse-c is marked as
invalid, she could then run a corresponding DNSBL. However, article 3 of the
Terms and Conditions for Data Access[†] seems to disallow just that.
Best
Ale
--
[*] https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml
[†] https://labs.ripe.net/datarepository/conditions/basic
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Hello Ángel, WG, > On 13 May 2020, at 00:45, Ángel González Berdasco > wrote: > >> ... > > 5.135.48.50is one of such IP addresses. > It has as abuse-c ab...@for-ns.com, which is trivially invalid: for- > ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has > address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25 > > Port 43 access provides: >> % Information related to '5.135.48.48 - 5.135.48.51' >> >> % Abuse contact for '5.135.48.48 - 5.135.48.51' is 'ab...@for-ns.com' >> % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for >> further information. > > > I am unable to see such piece of information on the RDAP view, though: > https://rdap.db.ripe.net/ip/5.135.48.48 > > You are correct: the RIPE RDAP service returns the abuse-c contact as an entity under an IP object, but not the "validation failed" comment. We will add this comment as a "remarks" data structure within the IP object: https://tools.ietf.org/html/rfc7483#section-4.3 We plan to work on the RDAP functionality after the RIPE 80 meeting, we will include this change. Thanks for bring this omission to our attention. Regards Ed Shryane RIPE NCC smime.p7s Description: S/MIME cryptographic signature
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Clearly something that RIPE NCC should improve in their procedures (or at least explain if there is any issue doing so), but I don't think we need to include those procedural details in the policy proposal. What do you think Petrit? Regards, Jordi @jordipalet El 13/5/20 0:46, "anti-abuse-wg en nombre de Ángel González Berdasco" escribió: El mar, 12-05-2020 a las 22:21 +0200, JORDI PALET MARTINEZ via anti- abuse-wg escribió: > You misunderstood me. I'm not advocating de-registration of IP > resources. I > meant to remove just the abuse-c email address, since it does not > work. As an > alternative, as Àngel noted, there could be a tag saying that the > email address > is not valid, without actually removing it. > > [Jordi] I got your point now, thanks! > > I think it is more useful instead of removing the address, marking > the record as invalid, and this is being done if I recall correctly > from RIPE NCC presentations. 5.135.48.50is one of such IP addresses. It has as abuse-c ab...@for-ns.com, which is trivially invalid: for- ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25 Port 43 access provides: > % Information related to '5.135.48.48 - 5.135.48.51' > > % Abuse contact for '5.135.48.48 - 5.135.48.51' is 'ab...@for-ns.com' > % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for > further information. I am unable to see such piece of information on the RDAP view, though: https://rdap.db.ripe.net/ip/5.135.48.48 Best regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute 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. Disclaimer: This message may contain confidential information, within the framework of the corporate Security Management System.If you are not the intended recipient, please notify the sender and delete this message without forwarding or retaining a copy, since any unauthorized use is strictly prohibited by law. ** 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.
