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

About introduction of punishments in AFRINIC's policy
by Marilson 16 Apr '17

16 Apr '17

Abuse: shut down Internet access for political reasons Abuse authorship: autocratic governments Objective: punishment The RIPE policy list commented and it is under discussion on AFRINIC a policy proposal anti-shutdown which provides for punishment. https://afrinic.net/en/community/policy-development/policy-proposals/2061-a… https://www.theregister.co.uk/2017/04/12/no_ip_addresses_for_countries/ On the ARIN Public Policy Mailing List, a member commented: >Doesn't seem like the most workable policy to my novice eyes. >Is it really a good idea to convert RIRs into the internet police? >if we think it is a good idea, who decides what's a proper case for implementation? That is what I wrote there: To my novice eyes, but tired and disappointed, I find it rather appropriate that the entity responsible for the management and allocation of IP address blocks adopt punitive measures against those who interfere in the free internet or in the inappropriate use of those services. Who decides? The evidence. And the Internet community seems to be the only one capable of putting punitive measures into practice. No matter who we are or what we do, commitment to democracy should always be part of our activities. The owners of these resources is the population of the planet. RIRs manage these resources on behalf of this population and should effectively manage without omitting and transferring that responsibility to governments or to their ISP customers. I say this because, just as there are autocratic governments, there are bad ISPs who arrogantly refuse to punish clients with illicit activities even in the face of evidence. And in the face of these bad providers, governments, without exception, turn a blind eye. They are more concerned about employment within their territory even at the expense of the population being the victim of spammers and scammers. This situation explains and does not justify the 420 billion spam and scam per day (Cisco). Never so few done so much harm to so many. No more shutdowns. No more denying access to information and knowledge. No more bad ISPs. Even with Trump! Marilson

1 0

Re: [anti-abuse-wg] Abuse: ipv6 and spam
by Richard Clayton 13 Apr '17

13 Apr '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message , ox <andre(a)ox.co.za> writes >I am currently drafting a document regarding accepting email on ipv6 I am happy to argue that being able to obtain an IPv4 address for an MTA is a "clue test" and that failure to have that clue is a plausible reason for rejecting email from a sender... this is not Politically Correct but it's going to be a very effective heuristic for some years to come. [this doesn't apply to end users submitting email to a "smart host", but you authenticate them, so the issues are different] >On White Lists, the process is not as clear or obvious as one may >think as firstly the address space has 2(128) addresses, sec issues >( https://tools.ietf.org/html/rfc5782) etc etc etc you might like to look at M3AAWG's suggestions (essentially they suggest that /64s are the initial granularity of choice) <https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6 _Policy_Issues-2014-09.pdf> what will go wrong with this approach is that a major site could decide that they want all of their (100s of millions) of users to accrue their own reputation and so they use a unique IPv6 address for each user... >The actual listing entries, sure, we already have a few hundred >good/known ipv6 email servers, but how do admins go about adding >themselves to the white list? > >Obviously it has to be free, open, fair and anyone has to be able to >add themselves. that's not obvious at all -- reputation providers can and will have their own rules for setting the reputation of IPs. If their decisions are wise (and their pricing is acceptable) then people will flock to use their product. >which has given rise >to an idea that all servers (people providing services / providers of >services as opposed to users of) - should have their own, separate >resource listing... what you need to be able to do is to determine whether two IPv6 addresses are controlled by the same person (so that allocating a single reputation to a range of IPv6 addresses makes complete sense). For that you need to know the "cut point" ... what allocation unit is being used by the entity that handed out the IPv6 addresses. constructing a free/open directory of that information would be useful (before we all have to buy it from a commercial vendor) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBWO9/kju8z1Kouez7EQK9SQCcCd1tG8InFx144G2M0IP1jjqNsqAAoMNC SHHEW9eLteAdA2qSEALuTu6z =Ifr6 -----END PGP SIGNATURE-----

1 0

Abuse: ipv6 and spam
by ox 13 Apr '17

13 Apr '17

Hello Everyone, I am currently drafting a document regarding accepting email on ipv6 and building our white list database (it will eventually be either six.ascams.com or sixwhite.ascams.com) Ref: https://tools.ietf.org/html/draft-tzink-ipv6mail-whitelist-01 The actual practical implementation is so simple and easy:, simply use it in reverse of a blacklist, score all incoming ipv6 emails +1000 and if listed on six.ascams.com -1000 (and if listed with whitelist.example.com -1000 - etc etc) Defining the actual processes for white listing itself, is not as easy as it may seem... Black list: for example superblock.ascams.com: First time de-listing (takes anywhere from 24 hours to 7 days) Second time de-listing (takes anywhere from 7 days to 3 weeks) Third time listing is a semi permanent block (discussed in public) Fourth time listing is permanent, even if the ipv4 resource re-allocated On White Lists, the process is not as clear or obvious as one may think as firstly the address space has 2(128) addresses, sec issues ( https://tools.ietf.org/html/rfc5782) etc etc etc But, notwithstanding that, the actual listing & de listing is also, reasonably simple: For example: the same process as blacklists, if multiple users file complaints, the ipv6 entry is revoked, re-instated, etc etc and this is where I am at now. The actual listing entries, sure, we already have a few hundred good/known ipv6 email servers, but how do admins go about adding themselves to the white list? Obviously it has to be free, open, fair and anyone has to be able to add themselves. But, it is the actual adding, bots, trust and other issues that is still challenging. (and, yes, I have read BITAG (bitaq) etc as well as all the other copious amounts of drivel, diatribe and POV out there) One idea is for admins to go through manual verification process, for which volunteers would be required, Another idea is that In the TXT answer, for white listing, the email address of the ipv6 abuse@ is to be published and for the entire database to be available (like the RIPE whois) - which has given rise to an idea that all servers (people providing services / providers of services as opposed to users of) - should have their own, separate resource listing... There are of course many other ideas as well, but the reason for my post is: Do you have any value, comment or idea you could add to this? thanks! Andre

1 0

"abuse-c:" - a question....
by ripedenis＠yahoo.co.uk 31 Mar '17

31 Mar '17

Colleagues [Apologies if you receive duplicate versions of this email but my interaction with the RIPE NCC mailing lists is getting worse. Three attempts with gmail, yahoo and xs4all email accounts all failed to post this to the DB-WG so lets discuss it here...] I would like to ask the community a question that looks at a wider picture than the "abuse-c:" attribute itself. Depending on how people react to this question, it may impact the chosen path to solving the issue with documenting abuse contact details in the RIPE Database. The current implementation for "abuse-c:" documents the default contact details for who handles abuse issues within an organisation that holds resources. If the email address is invalid or there is no response to a complaint sent to that address it is clear who the organisation is and there are other contacts related to this organisation. Sometimes a resource holder delegates some responsibility for the management of (one or more of) their resource(s) to another person/organisation. This may be just the abuse handling. With the current database semantics it is not always possible to create a separate ORGANISATION object to document this responsibility. This issue has been described as 'How to reference the email address for the abuse reports for this resource?'. The simple version of my question is 'Is it enough to only know the email address and an un-validated postal address for the abuse handler?'. An email address can be 'anyone(a)anybody.com'. This tells you nothing about 'anyone' or 'anybody'. It is a one directional channel to throw something down that may end in a black hole. If nothing happens, who was supposed to have this responsibility? Not everyone who uses this abuse contact information understands the RIPE Database structure, the resource hierarchy or the contractual responsibilities of the related parties. They may have searched online for who to complain to, got this email address and got no response. How do you take further action against an email address? What I am working round to is explaining why the "abuse-c:" was designed the way it is. Where responsibility for handling abuse was delegated to another party (separate organisation or another internal department) we wanted to maintain a closely coupled link between the resource listing a contact and an organisation responsible or accountable for abuse handling. As it turned out this created the need for repetitive data in some cases and not being able to record the right details in some other cases. The simplest solution that has been discussed in the past is to allow the "abuse-c:" attribute in resource objects. This does create some resource and data management issues. But these can be solved by providing resource managers with the right software tools. Now we get to the in depth version of my question. Do we need to maintain that close coupling in the database between who is responsible or accountable for handling abuse for a resource and their correct and validated (by the resource holder) contact details? If the answer to this question is a simple 'no' then we can easily add "abuse-c:" attributes anywhere pointing to an email address and provide the resource managers with tools to maintain the data....job done. If the answer is anything other than a simple 'no' and we believe abuse information consumers without an in depth knowledge of the database or industry need to easily understand 'who' claims to be behind an email address then we may need a more complex solution. I hope this makes sense and look forward to comments and questions. cheers denis co-chair DB-WG

4 5

Re: [anti-abuse-wg] "abuse-c:" - a question....with no answers?
by Hal ponton 31 Mar '17

31 Mar '17

Sorry didn't cc in the list, Regards, Hal > Hal ponton <mailto:hal@buzcom.net> > 31 March 2017 at 09:53 > Andre, > > The issue I see with two contacts (emergency and standard) is that > everyone will email the emergency contact. > > I fully agree that the response required for 1 spam email vs 10000 > emails is vastly different, however, if someone wants a response they > will email the account they think they'd get the fastest / best > response from. It's just human nature. > > Whilst at first non-emergency complaints will be ignored, it will get > to a "boy who cried wolf" situation where the amount of non-emergency > emails vastly outweighs the emergency emails. To the point where the > organisation will just treat the emergency mailbox the same as the > current abuse mailbox. > > You would need some disincentive to email the emergency mailbox. Like > on a train where if you pull the emergency handle without there being > an emergency you get a fine. I'm not advocating a fine here, just > something similar to try and regulate emails coming into the emergency > mailbox. > > > >

2 1

Report of AS203496 (LLC AB-Telecom) to halt announcement of IPv4 block 168.197.120.0/23 (Operbes, S.A. de C.V. - MX-OSCV9-LACNIC)
by Jose Damian Cantu Davila 16 Mar '17

16 Mar '17

Hi, I apologize in advance if this is the wrong forum Im Damian Cantu, analyst at IAR Mexico, which is the National Internet Registry for Mexico. We find out that LLC AB-Telecom´s AS203496 started announcing in november 4th of 2016 the IPv4 block 168.197.120.0/23 which belongs to an ISP located in our region -LACNIC, the Latin American and Caribbean Internet Addresses Registry-. https://stat.ripe.net/168.197.120.0%2F23#tabId=at-a-glance The IPv4 block 168.197.120.0/23 belongs to Operbes, S.A. de C.V. (MX-OSCV9-LACNIC) which has a Legal contract with us. http://lacnic.net/cgi-bin/lacnic/whois?lg=EN&query=168.197.120/22&stkey=220… We need that LLC AB-Telecom´s AS203496 halt any further announcement of the IPv4 block since it is affecting our clients network operation. I had reported to their abuse info but haven´t had any response. Im wondering if someone in this forum can put me in contact with their tech-staff. Thanks in advance for your help, And I apologize if it's the wrong forum to post. Best regards. [damian cantu] ________________________________ Este mensaje contiene información confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor elimínalo, ya que difundir, revelar, copiar o tomar cualquier acción basada en el contenido está estrictamente prohibido. Network Information Center México, S.C., ubicado en Ave. Eugenio Garza Sada 427 L4-6 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus datos personales necesarios para: la prestación, estudio, análisis y mejora del servicio, la realización de comunicaciones y notificaciones; la transferencia y publicación en los casos aplicables; el cumplimiento de la relación existente; así como para la prevención o denuncia en la comisión de ilícitos. Si eres colaborador o candidato a colaborador de NIC México, tus datos serán utilizados para: la creación y administración de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realización de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestión y administración de servicios de pago y/o nómina; así como para contacto y/o notificaciones. Si participas en promociones o en estudios podrás dejar de participar. Para mayor información revisa el Aviso de Privacidad<http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf>. This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center Mexico, S.C., located on Av. Eugenio Garza Sada 427 Col. Altavista L4-6, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note<http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf>.

2 1

Draft Agenda - AA-WG RIPE74
by Brian Nisbet 13 Mar '17

13 Mar '17

Colleagues, Here is the draft agenda for RIPE 74. The WG meeting is to take place at 11:00CEST on Thursday 11th May. As you can see, there is still some space on the agenda, so if you would like to present, propose or discuss something in Budapest, please let Tobias or myself know. A. Administrative Matters * Welcome * Scribe, Jabber, Stenography * Microphone Etiquette * Approve Minutes from RIPE 73 * Finalise agenda B. Update * B1. Recent List Discussion? * B2. C. Policies - * C1. D. Interactions - * D1. Working Groups - DB & Implementation of "abuse-c" * D2. E. Presentation - * E1. Network & Information Security Directive, Nathalie Falot, NCSC-NL X. A.O.B. Z. Agenda for RIPE 75

1 0

Call For Agenda Items - RIPE 74
by Brian Nisbet 07 Mar '17

07 Mar '17

Colleagues, The next meeting of the Anti-Abuse WG will take place on Thursday 11th May at 11:00 CEST during RIPE 74. While we have a few things for the agenda already, there is still space, so please let Tobias and I know if there is something you would like to present or propose in Budapest. Thanks, Brian -- 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

FW: [gnso-rds-pdp-wg] Outreach to Impacted Stakeholders
by Michele Neylon - Blacknight 05 Mar '17

05 Mar '17

All As members of this list have an interest in whois either directly or tangentially the attached might be of interest to some of you. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blacknight.blog / http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: <gnso-rds-pdp-wg-bounces(a)icann.org> on behalf of Chuck Gomes <cgomes(a)verisign.com> Date: Sunday 5 March 2017 at 16:06 To: "gnso-rds-pdp-wg(a)icann.org" <gnso-rds-pdp-wg(a)icann.org> Subject: [gnso-rds-pdp-wg] Outreach to Impacted Stakeholders Attached is a PDF file of our latest WG update. If any of you know of organizations that may be impacted by work but are not involved in our WG, I encourage you to forward this update to them and encourage them to join us as members or observers. Chuck

1 0

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 63, Issue 28
by Marilson 03 Mar '17

03 Mar '17

Eventually, it would be that what you want? https://www.spamhaus.org/drop/drop.txt "The Spamhaus DROP (Don't Route Or Peer) lists are advisory "drop all traffic" lists, consisting of netblocks that are "hijacked" or leased by professional spam or cyber-crime operations (used for dissemination of malware, trojan downloaders, botnet controllers)." Which only includes netblocks allocated from RIR and NIR. Marilson From: anti-abuse-wg-request(a)ripe.net Sent: Tuesday, February 28, 2017 9:47 AM To: anti-abuse-wg(a)ripe.net Subject: anti-abuse-wg Digest, Vol 63, Issue 28 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. Seeking abuse/phishing/malware email content (Ross Dour) 2. Re: Seeking abuse/phishing/malware email content (ox) 3. Re: Seeking abuse/phishing/malware email content (Suresh Ramasubramanian) 4. Re: Seeking abuse/phishing/malware email content (ox) 5. Re: Seeking abuse/phishing/malware email content (Suresh Ramasubramanian) 6. Re: Seeking abuse/phishing/malware email content (ox) ---------------------------------------------------------------------- Message: 1 Date: Tue, 28 Feb 2017 22:42:06 +1100 From: "Ross Dour" <rossd(a)fraudwatchinternational.com> To: <anti-abuse-wg(a)ripe.net> Subject: [anti-abuse-wg] Seeking abuse/phishing/malware email content Message-ID: <4207474f99604a4a8bfcbe647ecaae02(a)fraudwatchinternational.com> Content-Type: text/plain; charset="utf-8" Hello everyone, I've been a subscriber to this mailing list for some time now and wanted to put a request for assistance to any members of the group. I'm seeking large data sets of abuse emails - to be more specific, I am interested in access to spam emails, phishing emails, malware emails. My interest is for legitimate and commercial purposes. Our company provides brand protection services to a variety of brands around the world. Our interest here is to detect malicious content within emails and email attachments to catalogue and where possible, take action and remove the content in collaboration with the responsible content hosts. Ideally, I would like to work in continued partnership with anyone who was interested in helping us combat abuse but I am also willing and able to take any one-time data dumps that people may have. We already partner with a large number of providers in this way and in doing so, we can help them combat malicious content in their environments more efficiently and effectively. I am happy to take any responses through the mailing list or alternatively I'm happy for you to email me directly if you're interested in working with us. Best regards, Ross Dour Chief Operating Officer FraudWatch International e: rossd(a)fraudwatchinternational.com This email and any attachments may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of the transmission along with any attachments immediately. You should not copy or use it for any purpose, nor describe the contents to any other person.

2 1