- anti-abuse-wg - mailman.ripe.net

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

You're right, if we opt for some human interaction, never mind is using a privacy service, but it doesn't make sense to me that a privacy service is used for this kind of email, so I will strongly suggest to have some wording that "exclude privacy whois services for this abuse contact". Regards, Jordi -----Mensaje original----- De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox <andre(a)ox.co.za> Organización: ox.co.za Fecha: viernes, 19 de enero de 2018, 10:47 Para: JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) not sure that I know of any abuse@ email that is privacy.85o8095.849804938(a)example.com (the privacy.xxx domain may exist and be a real domain - as such the "privacy.85o8095.849804938(a)privacy.xxx" you used, in your example, may actually belong to someone...) But quick question: who decides what email address is "real" and what is not "real" If an abuse@ uses privacy.85o8095.849804938(a)example.com then receives email and solves a capcha and then clicks a tickbox - the email address is functional / working and "real" ??? Regards Andre On Fri, 19 Jan 2018 10:40:40 +0100 JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> wrote: > One more thing I just realized ... > > I understand that the mailbox must be a "real" one, not the typical > "privacy.85o8095.849804938(a)privacy.xxx" that is used often in whois > data ... > > Regards, > Jordi > > -----Mensaje original----- > De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox > <andre(a)ox.co.za> Organización: ox.co.za > Fecha: viernes, 19 de enero de 2018, 10:37 > Para: <anti-abuse-wg(a)ripe.net> > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase > (Regular abuse-c Validation) > > > Yes, the idea Thomas had about human interaction, solving a > captcha and a tickbox is a great idea > my 1c > > Andre > > On Fri, 19 Jan 2018 10:29:42 +0100 > JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> > wrote: > > I also think that Thomas suggestion of a checkbox agreeing with > > regularly monitoring the abuse-mailbox is a wonderful > > suggestion. Regards, > > Jordi > > Para: <anti-abuse-wg(a)ripe.net> > > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review > > Phase (Regular abuse-c Validation) > > I support the proposal in general and i also think a human > > interaction of the resource holder is required. > > > > Am 19.01.18 um 09:52 schrieb Thomas Hungenberg: > > > I second Jordi's opinion that validation of the > > > abuse-mailbox should require human interaction of the > > > resource holder. In addition to solving a captcha the > > > resource holder might need to confirm (click a checkbox) > > > that he will monitor the abuse-mailbox account on a > > > regular basis and take appropriate action to solve > > > reported abuse cases. > > > > > > > > > - Thomas > > > > > > CERT-Bund Incident Response & Malware Analysis Team > > > > > > > > > On 18.01.2018 19:44, JORDI PALET MARTINEZ via > > > anti-abuse-wg wrote: > > >> I fully agree with this proposal and should be > > >> implemented ASAP. > > >> > > >> HOWEVER, I’ve a question regarding the impact analysis, > > >> and specially this sentence: > > >> > > >> “To increase efficiency, this process will use an > > >> automated solution that will allow the validation of > > >> “abuse-mailbox:” attributes without sending an email. No > > >> action will be needed by resource holders that have > > >> configured their “abuse-mailbox:” attribute correctly.” > > >> > > >> Reading the policy proposal, how the NCC concludes that > > >> it should be “without sending an email”? > > >> > > >> I will say that the right way to do a validation (at > > >> creation/modification and yearly) is, in a way that makes > > >> sense (having an email that nobody is processing is > > >> exactly the same as not having the abuse attribute at > > >> all): 1) Send an email with a link that must be clicked > > >> by a human (so some kind of captcha-like mechanism > > >> should be followed) 2) If this link is not clicked in a > > >> period of 48 hours (not including Saturday-Sunday), an > > >> alarm should be generated so the NCC can take the > > >> relevant actions and make sure that the mailbox is > > >> actively monitored by the LIR > > >> > > >> Regards, > > >> Jordi > > > > > > > -- > > Mit freundlichem Gruß > > > > Artfiles New Media GmbH > > > > Andreas Worbs > > > > > > Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg > > Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 > > E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de > > Geschäftsführer: Harald Oltmanns | Tim Evers > > Eingetragen im Handelsregister Hamburg - HRB 81478 > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > 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. > > > > > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > 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. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.

1 0

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

One more thing I just realized ... I understand that the mailbox must be a "real" one, not the typical "privacy.85o8095.849804938(a)privacy.xxx" that is used often in whois data ... Regards, Jordi -----Mensaje original----- De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox <andre(a)ox.co.za> Organización: ox.co.za Fecha: viernes, 19 de enero de 2018, 10:37 Para: <anti-abuse-wg(a)ripe.net> Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) Yes, the idea Thomas had about human interaction, solving a captcha and a tickbox is a great idea my 1c Andre On Fri, 19 Jan 2018 10:29:42 +0100 JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> wrote: > I also think that Thomas suggestion of a checkbox agreeing with > regularly monitoring the abuse-mailbox is a wonderful suggestion. > Regards, > Jordi > Para: <anti-abuse-wg(a)ripe.net> > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase > (Regular abuse-c Validation) > I support the proposal in general and i also think a human > interaction of the resource holder is required. > > Am 19.01.18 um 09:52 schrieb Thomas Hungenberg: > > I second Jordi's opinion that validation of the abuse-mailbox > > should require human interaction of the resource holder. In > > addition to solving a captcha the resource holder might need to > > confirm (click a checkbox) that he will monitor the > > abuse-mailbox account on a regular basis and take appropriate > > action to solve reported abuse cases. > > > > > > - Thomas > > > > CERT-Bund Incident Response & Malware Analysis Team > > > > > > On 18.01.2018 19:44, JORDI PALET MARTINEZ via anti-abuse-wg > > wrote: > >> I fully agree with this proposal and should be implemented > >> ASAP. > >> > >> HOWEVER, I’ve a question regarding the impact analysis, and > >> specially this sentence: > >> > >> “To increase efficiency, this process will use an automated > >> solution that will allow the validation of “abuse-mailbox:” > >> attributes without sending an email. No action will be needed > >> by resource holders that have configured their > >> “abuse-mailbox:” attribute correctly.” > >> > >> Reading the policy proposal, how the NCC concludes that it > >> should be “without sending an email”? > >> > >> I will say that the right way to do a validation (at > >> creation/modification and yearly) is, in a way that makes > >> sense (having an email that nobody is processing is exactly > >> the same as not having the abuse attribute at all): 1) Send an > >> email with a link that must be clicked by a human (so some > >> kind of captcha-like mechanism should be followed) 2) If this > >> link is not clicked in a period of 48 hours (not including > >> Saturday-Sunday), an alarm should be generated so the NCC can > >> take the relevant actions and make sure that the mailbox is > >> actively monitored by the LIR > >> > >> Regards, > >> Jordi > > > > -- > Mit freundlichem Gruß > > Artfiles New Media GmbH > > Andreas Worbs > > > Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg > Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 > E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de > Geschäftsführer: Harald Oltmanns | Tim Evers > Eingetragen im Handelsregister Hamburg - HRB 81478 > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > 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. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.

2 1

Automatische Antwort: [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Heger, Christian 18 Jan '18

18 Jan '18

Ich bin zurzeit nicht im Hause. Bitte wenden Sie sich in dringenden Fällen an meine Kollegen. Diese Mail wird nicht weitergeleitet! Mit freundlichen Grüßen Christian Heger Netzwerk Access & Security | P352 Tel.: +49 911 319-42250 ________________________________ DATEV eG 90329 Nürnberg Telefon +49 911 319-0 Telefax +49 911 147-43196 E-Mail: info(a)datev.de Internet: https://www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstraße 6-14 Registergericht Nürnberg, GenReg Nr. 70 Vorstand Dr. Robert Mayr (Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Prof. Dr. Peter Krug Jörg Rabe von Pappenheim Diana Windmeißer Vorsitzender des Aufsichtsrates: Joachim M. Clostermann

1 0

abuse-c attributes in resource objects
by Thomas Hungenberg 04 Jan '18

04 Jan '18

The "FAQs for abuse-c" says: You can have an "abuse-c:" attribute on both your ORGANISATION object AND your RESOURCE object (inetnum, inet6num and aut-num). The "abuse-c:" reference on applicable RESOURCE objects will override the value in the "abuse-c:" of your ORGANISATION object. [https://www.ripe.net/manage-ips-and-asns/resource-management/faqs-for-abuse…] However, in the RIPE documentation, the list of all possible attributes allowed in AUT-NUM and INETNUM objects does *not* include "abuse-c": [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object] [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object] There are currently some RESOURCE objects in the RIPE database having abuse-c attributes (which should not be allowed according to the documentation). For example: inetnum: 62.27.57.0 - 62.27.57.255 netname: TIS-D406483-NET descr: Cheetah Digital Germany GmbH country: DE admin-c: NET12312-RIPE tech-c: NET12312-RIPE abuse-c: CDAC23-RIPE status: ASSIGNED PA mnt-by: AS12312-MNT So we wonder what is correct? We would prefer sticking to the documentation allowing abuse-c attributes only in ORGANISATION objects but not in RESOURCE objects as this makes maintaining a local abuse contact database (for CERTs sending thousands of abuse reports per day) much easier. For example, for our local contact database, we import all ORGANISATION objects with "country: DE" and use "org-name" for the contact's name. Then, we link all RESOURCE objects referencing this ORG to the respective contact in our database. Also evaluating abuse-c attributes directly included in RESOURCE objects would make building a local contact database much more complex. - Thomas CERT-Bund Incident Response & Malware Analysis Team

1 0

Help Re: anti-abuse-wg Digest, Vol 73, Issue 5
by Ervin Radosavlevici 19 Dec '17

19 Dec '17

Sent from my iPhone > On Dec 19, 2017, at 11:00 AM, anti-abuse-wg-request(a)ripe.net wrote: > > Send anti-abuse-wg mailing list submissions to > anti-abuse-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/anti-abuse-wg > or, via email, send a message with subject or body 'help' to > anti-abuse-wg-request(a)ripe.net > > You can reach the person managing the list at > anti-abuse-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of anti-abuse-wg digest..." > > > Today's Topics: > > 1. DMARC Solution Applied to this Mailing List (Adam Castle) > 2. Re: DMARC Solution Applied to this Mailing List (ox) > 3. Re: DMARC Solution Applied to this Mailing List (ox) > 4. Re: DMARC Solution Applied to this Mailing List (Gert Doering) > 5. Re: DMARC Solution Applied to this Mailing List (ox) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Dec 2017 12:29:01 +0100 > From: Adam Castle <acastle(a)ripe.net> > To: anti-abuse-wg(a)ripe.net > Subject: [anti-abuse-wg] DMARC Solution Applied to this Mailing List > Message-ID: <a2863ca3-d7f8-6b1e-a1db-3fb8c5af8c35(a)ripe.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > Dear Working Group, > > As more email providers enable Domain Message Authentication Reporting & > Conformance (DMARC), some people find they can no longer receive emails > from the mailing lists they are subscribed to. We have deployed a > Mailman setting change to address this problem. > > After consultation with the RIPE Working Group Chairs, we have enabled > the DMARC "Munge From" setting on all RIPE mailing lists. This means > that if your email service provider has DMARC enabled, you will continue > to receive all emails sent to this mailing list, but the "From" part of > the header will change. If you don't have DMARC enabled, you won't see > any change to the emails you receive from this mailing list. > > You can find more information about how we have been handling DMARC in > the following RIPE Labs articles: > > https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc > > https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc > > To ensure all working group participants are aware of the changes, I am > sending this mail to all working groups. If you have any questions or > encounter any issues on this mailing list, please let me know. > > Many thanks. > > Adam Castle > Web Services Manager > RIPE NCC > > > > ------------------------------ > > Message: 2 > Date: Mon, 18 Dec 2017 14:16:43 +0200 > From: ox <andre(a)ox.co.za> > To: Adam Castle <acastle(a)ripe.net> > Cc: anti-abuse-wg(a)ripe.net > Subject: Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing > List > Message-ID: <mailman.4.1513681201.2983.anti-abuse-wg(a)ripe.net> > Content-Type: text/plain; charset=US-ASCII > > > Hi Adam, > > Please enlighten me why RIPE does not support publish any SPF records? > > I do see the RRSIG, so am keen on understanding why RIPE supports DMARC > and no SPF? > > Andre > > -- > dig TXT ripe.net > ; <<>> DiG 9.9.9-P1 <<>> TXT ripe.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25373 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;ripe.net. IN TXT > > ;; AUTHORITY SECTION: > ripe.net. 299 IN SOA manus.authdns.ripe.net. > dns.ripe.net. 1513415885 3600 600 864000 300 > > > On Mon, 18 Dec 2017 12:29:01 +0100 > Adam Castle <acastle(a)ripe.net> wrote: > >> Dear Working Group, >> >> As more email providers enable Domain Message Authentication >> Reporting & Conformance (DMARC), some people find they can no longer >> receive emails from the mailing lists they are subscribed to. We have >> deployed a Mailman setting change to address this problem. >> >> After consultation with the RIPE Working Group Chairs, we have >> enabled the DMARC "Munge From" setting on all RIPE mailing lists. >> This means that if your email service provider has DMARC enabled, you >> will continue to receive all emails sent to this mailing list, but >> the "From" part of the header will change. If you don't have DMARC >> enabled, you won't see any change to the emails you receive from this >> mailing list. >> >> You can find more information about how we have been handling DMARC >> in the following RIPE Labs articles: >> >> https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc >> >> https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc >> >> To ensure all working group participants are aware of the changes, I >> am sending this mail to all working groups. If you have any questions >> or encounter any issues on this mailing list, please let me know. >> >> Many thanks. >> >> Adam Castle >> Web Services Manager >> RIPE NCC >> > > > > > ------------------------------ > > Message: 3 > Date: Mon, 18 Dec 2017 14:23:06 +0200 > From: ox <andre(a)ox.co.za> > To: Adam Castle <acastle(a)ripe.net> > Cc: anti-abuse-wg(a)ripe.net > Subject: Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing > List > Message-ID: <mailman.5.1513681201.2983.anti-abuse-wg(a)ripe.net> > Content-Type: text/plain; charset=US-ASCII > > > I just realised that my question is confusing :) > > I mean > > RIPE does not have dmarc or spf (but does dnssec) so, for me, my spam > filters score points on lack of SPF or even hard bounce on wrong SPF > > RIPE emails (from the mailing list) attracts points - for not having SPF > > So, more directly, I am asking if it is possible to add SPF even with a "~" is fine? > > > Andre > > On Mon, 18 Dec 2017 14:16:43 +0200 > ox <andre(a)ox.co.za> wrote: > >> Hi Adam, >> >> Please enlighten me why RIPE does not support publish any SPF records? >> >> I do see the RRSIG, so am keen on understanding why RIPE supports >> DMARC and no SPF? >> >> Andre >> >> -- >> dig TXT ripe.net >> ; <<>> DiG 9.9.9-P1 <<>> TXT ripe.net >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25373 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: >> 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 512 >> ;; QUESTION SECTION: >> ;ripe.net. IN TXT >> >> ;; AUTHORITY SECTION: >> ripe.net. 299 IN SOA >> manus.authdns.ripe.net. dns.ripe.net. 1513415885 3600 600 864000 300 >> >> >> On Mon, 18 Dec 2017 12:29:01 +0100 >> Adam Castle <acastle(a)ripe.net> wrote: >> >>> Dear Working Group, >>> >>> As more email providers enable Domain Message Authentication >>> Reporting & Conformance (DMARC), some people find they can no longer >>> receive emails from the mailing lists they are subscribed to. We >>> have deployed a Mailman setting change to address this problem. >>> >>> After consultation with the RIPE Working Group Chairs, we have >>> enabled the DMARC "Munge From" setting on all RIPE mailing lists. >>> This means that if your email service provider has DMARC enabled, >>> you will continue to receive all emails sent to this mailing list, >>> but the "From" part of the header will change. If you don't have >>> DMARC enabled, you won't see any change to the emails you receive >>> from this mailing list. >>> >>> You can find more information about how we have been handling DMARC >>> in the following RIPE Labs articles: >>> >>> https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc >>> >>> https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc >>> >>> To ensure all working group participants are aware of the changes, I >>> am sending this mail to all working groups. If you have any >>> questions or encounter any issues on this mailing list, please let >>> me know. >>> >>> Many thanks. >>> >>> Adam Castle >>> Web Services Manager >>> RIPE NCC >>> >> >> > > > > > ------------------------------ > > Message: 4 > Date: Mon, 18 Dec 2017 16:46:37 +0100 > From: Gert Doering <gert(a)space.net> > To: ox <andre(a)ox.co.za> > Cc: Adam Castle <acastle(a)ripe.net>, anti-abuse-wg(a)ripe.net > Subject: Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing > List > Message-ID: <20171218154637.GV45648(a)Space.Net> > Content-Type: text/plain; charset="us-ascii" > > Hi, > >> On Mon, Dec 18, 2017 at 02:16:43PM +0200, ox wrote: >> Please enlighten me why RIPE does not support publish any SPF records? >> >> I do see the RRSIG, so am keen on understanding why RIPE supports DMARC >> and no SPF? > > Adam did not state RIPE NCC would "support DMARC". DMARC is full of shit. > > What the RIPE NCC does is "activate workarounds to avoid mailing list > issues caused by other people running their domain with p=reject". > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >

1 0

Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing List
by Gert Doering 19 Dec '17

19 Dec '17

Hi, On Mon, Dec 18, 2017 at 02:16:43PM +0200, ox wrote: > Please enlighten me why RIPE does not support publish any SPF records? > > I do see the RRSIG, so am keen on understanding why RIPE supports DMARC > and no SPF? Adam did not state RIPE NCC would "support DMARC". DMARC is full of shit. What the RIPE NCC does is "activate workarounds to avoid mailing list issues caused by other people running their domain with p=reject". Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

2 1

DMARC Solution Applied to this Mailing List
by Adam Castle 18 Dec '17

18 Dec '17

Dear Working Group, As more email providers enable Domain Message Authentication Reporting & Conformance (DMARC), some people find they can no longer receive emails from the mailing lists they are subscribed to. We have deployed a Mailman setting change to address this problem. After consultation with the RIPE Working Group Chairs, we have enabled the DMARC "Munge From" setting on all RIPE mailing lists. This means that if your email service provider has DMARC enabled, you will continue to receive all emails sent to this mailing list, but the "From" part of the header will change. If you don't have DMARC enabled, you won't see any change to the emails you receive from this mailing list. You can find more information about how we have been handling DMARC in the following RIPE Labs articles: https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc To ensure all working group participants are aware of the changes, I am sending this mail to all working groups. If you have any questions or encounter any issues on this mailing list, please let me know. Many thanks. Adam Castle Web Services Manager RIPE NCC

2 2

Abuse auto responders & Legacy resources
by ox 16 Dec '17

16 Dec '17

Hi Everyone, Just when you thought it was safe to go in the water again..[1] (I did not expect to be posting again in 2017 :) ) Currently many people are not bothering to even monitor Abuse-C email boxes. As a real world example: 163.172.0.0 - 163.172.255.255 Right now, multiple Online SAS resources (in a bot net) is attempting to brute force web cms and there is no easy way to: Report the abuse or Notify the resource 'owner' - effectively the abuse-c has become useless and non relevant and it makes no difference that abuse-c exists as it is not monitored and means absolutely nothing. Legacy resources do this quite often and with everything: The argument is that new policies do not have to apply to legacy resources as these are somehow 'special' or 'old' or not relevant to policies. Legacy resources are actually MORE responsible for new policies than "new" resources. As legacy resources are OLD, outdated and not in line with the modern, new and present issues facing the Internet as a whole. So, my point is that as far as abuse is concerned: Policies should target legacy resources much more directly and with much more relevance as quite frequently, policy delinquency is directly tied and related to mostly legacy resources. Then, with regards the practical example: ONLINESAS-MNT's legacy range: So, the choices are: drop everything from the range - firewall only the affected port and spend our resources on tracking only the affected ip numbers (which with the eventual advent of ipv6 will make absolutely no sense) or simply just to dev/null everything from the entire range. What should concern abuse admins is that practically, the simplest, cheapest, easiest and most effective method is just to null the entire range. If we all start doing that, the planet will become less and less connected, except through the large peers with adequate resources to actively filter on a short term basis only the precise bot nets for that slice of time. ONLINESAS-MNT has configured an autoresponder that basically tells anyone sending mail there that they have to create an account on the company website, submit a ticket after figuring out how the web platform works, then interact with the system etc. Of course reporting abuse to ONLINESAS-MNT is so resource intensive, takes so long and is so involved that it is not done. My point is that ONLINESAS-MNT is not alone. managing abuse is a cost. Large companies want to make money - but they want to spend as little as possible to make that money. They are all the same. Avoiding a working abuse-c is a simple and easy way to cut down on your abuse management costs. In my opinion, this is a very bad practice and it does render the whole abuse-c as non functional anyway. As more and more companies figure out how they can avoid managing abuse, with no/limited blowback, they will all probably start doing exactly that - this will render abuse-c as pointless and futile as it will mean nothing - and it also devalues much of what RIPE/RIR does to ensure some sort of responsibility for maintaining functional data. It is patently pointless to have a resource record, like abuse-c - if it means absolutely nothing. Andre -- [1] Peter Benchley - JAWS 2 Just as an additional over share - I live by the ocean and yesterday morning we (me and my family) swam in close proximity to some great white sharks (the lifeguards then closed the beach) - beautiful creatures.

1 0

DRAFT WG Minutes - RIPE75
by Brian Nisbet 13 Dec '17

13 Dec '17

Colleagues, The RIPE NCC staff have put together the draft minutes from RIPE75. I would appreciate if you could take a look and let me know of any errors, issues or required corrections. RIPE 75 Anti-Abuse Working Group Minutes Wednesday, 25 October 2017, 11:00 - 12:30 WG Co-Chair: Brian Nisbet  Scribe: Nathalie Trenaman, RIPE NCC  Status: Draft A. Administrative Matters Brian Nisbet opened the meeting and welcomed the working group. There was one addition to the agenda: Jan Žorž will do a brief presentation about the BCOP work. The minutes for the RIPE 74 meeting were approved. B. Update B1. Recent list Discussion Brian mentioned that there was nothing much to reference content-wise on the mailing list apart from the usual discussions. The RIPE community Code of Conduct is extended and includes the mailing list. There was positive feedback about this development. C. Policies C1. Policies: 2017-02 (Regular Abuse-C Validation) - Gregory Mounier and Hervé Clemens The presentation is available at: https://ripe75.ripe.net/presentations/119-Policy-change-proposal-RIPE-75-Du… Jan Žorž, ISOC, said he liked the idea of an auto-responder and wanted to give RIPE NCC the mandate to validate contacts, but he was not sure about the frequency of once-a-year for validation. Jan thinks that over 90% of the contacts are probably correct. Ruediger Volk, Deutsche Telekom, stressed his point that he would like to see a guideline document for abuse-c contact information. Brian Nisbet pointed out that this has been a discussion before and that more input was then requested and not received. Ruediger Volk added that the RIPE NCC already has the mandate to keep the registry accurate and that there is no need for a separate policy to enforce that. A repercussion of closing an LIR from this policy violates the Standard Service Agreement (SSA). Nigel Titley, RIPE NCC Executive Board, stated that if this becomes a policy, it becomes automatically part of the SSA. Piotr Strzyžewski, Silesian University of Technology, Computer Centre, said he missed the financial impact slide in this presentation. Gregory Mounier, Europe, explained that it would be in the impact analysis, produced by the RIPE NCC. Piotr Strzyžewski said that in the General Meeting yesterday, it was discussed that there should not be an increase of more RIPE NCC staff members. He added that he feared robots and automation will be set up by members to deal with the process. Andrew de la Haye, RIPE NCC, explained that there would be an impact analysis published in the next phase of the policy process. If the policy would reach consensus, they would not include the cost factor. The cost factor will be discussed in the General Meeting. Erik Bais, A2B Internet, said that he thought the ARC (Assisted Registry Check) process was the right process for this and that the RIPE NCC had enough issues chasing members for ARCs. He added that he was strongly against the part of this policy proposal that mentions closing members. Andrea Cima, RIPE NCC, commented that the RIPE NCC wouldn’t be able to contact all the members through ARCs on a yearly basis, but they can partially use ARCs to prioritise those members where they think the abuse-c information is incorrect. He added that they do not know the numbers yet, so ARCs may not be enough to fulfil. ARCs can help but it's not the full solution. Peter Hessler, Hostserver GmbH, stated that he is very much against this policy. He said it was a waste of resources in all areas and he is extremely against the closure clause of this policy proposal. Alexander Isavin, Internet Protection Society, said that what is sad about this policy proposal, was that is comes from law enforcement. He added that RIPE is not about helping law enforcement, but to support networks. Brian Nisbet says that they should not forget that law enforcement is part of their community. Gregory Mounier said that by monitoring an email address, law enforcement would not be able to investigate criminals and that this policy proposal is for the good of the community. William Sylvester, Addrex, asked if this policy proposal excluded legacy space holders. Brian replied that it did because they have no ability to impose policy on legacy address space. William said he opposes policies that reclaim any space. Brian added that this raised an interesting point because it's been said a couple of times and this is something for the community to consider, not specifically to this. If people don't support a policy which may lead potentially to the revocation of resources (speaking purely as himself here), it puts the community in a very interesting position in regards to what they may or may not be able to do in the future and the policies which currently exist which can lead to closure of members and revocation of resources. It is a very general comment, that is an interesting thing because it was referenced during the General Meeting last time as well. Gregory commented that he would also like to include the legacy space, but he was told not to. Jordi Palet Martinez, The IPv6 Company, said that he was in favour of this proposal because it improved contact information. He said that a form is not a good idea, because it is a waste of resources. An email should be answered in a certain amount of days. Brian added that version two of this policy proposal would be sent to the mailing list soon. D. Interactions D1. Working Groups - RIPE Database and Implementation of “abuse-c" Brian encouraged everyone to look at the conversations on the Database mailing list and to attend the Database Working Group session if they wanted to discuss this topic. He said he was not going to go into it here because it was a piece of work on the database but it was worth referencing because it's about the abuse‑c. E. Presentation E1. Netflow Based Botnet Detection - Alireza Vaziri  The presentation is available at: https://ripe75.ripe.net/presentations/89-Botnet-V3.pdf There were no questions or comments. E2. Pre-Transfer Clean-Up of Abused Prefixes - Erik Bais  The presentation is available at:  https://ripe75.ripe.net/wp-content/uploads/presentations/45-Prefix-Broker-p… Brian asked how to make contact with the larger RBLs (Real-Time Blackhole Lists) and how to persuade them to update their information. Erik said they had some experience with them because of GRUMbot, but the people from Shadowserver have very good contacts. Typically is wasn’t that hard to get them to update their information. Gregory Mounier asked if he knew how the bad guys got the IPs, was it hijacking. Erik replied that the IP space was from a Dutch hosting provider that was a member of the RIPE NCC. So it was customers that were in this space that were using it for this type of activity and hiding their command and control servers. X. AOB Jan Žorž presented about a new idea from the BCOP (Best Current Operational Practice) Task Force. It is about IPv6 and mail servers; how to protect them, including DKIM, DMARC etc. Jan asked if there were any volunteers in the WG to help write this document. Jan will send a mail to the mailing list as well. Peter Koch, DENIC, asked about the scope of this best practice document and if there was a guideline for these operational best practices. Jan Žorž replied that Franck Martin from LinkedIn wrote something already, but he wants a BCOP document for a broader audience. Z. Agenda for RIPE 76 Brian closed the meeting and reminded people to submit topics for the RIPE 76 agenda. -- Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

2 1

Proposal Update 2017-02
by Brian Nisbet 30 Nov '17

30 Nov '17

Colleagues, I just wanted to update you on the status of 2017-02. Grégory & Hervé have finalised the new version of the proposal and the NCC are creating the impact analysis based on this version. Both will hopefully be shared with the mailing list for discussion in early January. Thanks, Brian Co-Chair, RIPE AA-WG -- Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0