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

Reminder: AA-WG Session @ RIPE 84
by Brian Nisbet 11 May '22

11 May '22

Colleagues, Just a reminder about our hybrid session at RIPE 84 next week in Berlin and online. The current agenda is here: https://ripe84.ripe.net/programme/meeting-plan/aa-wg/ but there is still some time available, so if you would like to add something to the agenda, please let us know! Remember, this can be a couple of minutes of a point to raise, an idea for a policy or work item, a note of concern, anything related to the WG's work. It certainly doesn't have to be a full presentation with slides and all! Please let us know at aa-wg-chairs(a)ripe.net or find one of us in person in Berlin if you're at the meeting. Looking forward to seeing many of you next week! Brian Co-Chair, RIPE AA-WG Brian Nisbet (he/him) Service 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

Another incompetent ISP - Signet, B.V. - transip.net / signet.nl
by Ronald F. Guilmette 29 Apr '22

29 Apr '22

I recently attempted to report spam that was sent to me from [136.144.219.231]. This address is being routed by AS20857 (ORG-SI6-RIPE / Signet B.V.) and the containing IP block (136.144.128.0/17) is registered to TransIP B.V. (NOTE: no associated ORG record) which appears to be just a different face of the same Dutch company (Signet). My spam report was sent to the abuse reporting address contained in the RIPE WHOIS record for the revevant ASN (AS20857) i.e. <abuse(a)signet.nl>. Of course, I included in the report a complete copy of the spam message I received so that the people on the other end could have a clear picture of the nature of this incident and those responsible for it. Unfortunately, Signet/transIP appears to be yet another in a succession of ISPs that have failed to grasp the seemingly obvious fact that enabling spam filtering on your own inbound spam reporting email address is counterproductive. Thus, for my trouble I received back: <support(a)signet.blue> (expanded from <abuse(a)signet.nl>): host mx.transip.email[86.105.244.9] said: 550 5.7.1 Our system has detected that this message is likely unsolicited mail (SPAM). To reduce the amount of spam, this message has been blocked. (4Kpghy5Bcvz1J9nY) (in reply to end of DATA command) Based on this rejection it is now my intention to locally blacklist all IPv4 blocks assigned to this ISP. A partial list of these is included below. Unfortunately, due to ongoing and longstanding issues with the RIPE data base (which I will be mentioning yet again on the RIPE db-wg mailing list, for all the good it will do) it is not easily possible to derive a full list of all of the IP address blocks assigned to this company, at least not in a simple automated fashion. Blocks assigned to ORG-SI6-RIPE (fully aggregated): 31.3.8.0/21 31.3.96.0/21 31.14.96.0/22 31.223.160.0/20 37.17.208.0/20 37.34.48.0/20 37.97.128.0/17 37.230.96.0/21 46.21.224.0/20 46.226.56.0/21 77.72.144.0/21 78.108.128.0/20 79.170.88.0/21 80.69.64.0/19 80.84.224.0/19 80.246.192.0/20 80.255.240.0/20 81.4.64.0/19 81.4.96.0/22 81.4.112.0/21 81.21.136.0/21 81.30.32.0/20 83.96.128.0/17 84.247.8.0/21 85.10.128.0/18 85.158.248.0/21 85.222.224.0/21 86.105.244.0/22 87.253.128.0/19 89.31.96.0/21 89.41.168.0/22 91.142.240.0/20 91.205.32.0/22 91.216.162.0/24 93.119.0.0/20 93.191.128.0/21 94.142.208.0/21 95.170.64.0/19 141.138.136.0/21 141.138.192.0/20 141.255.176.0/21 149.210.128.0/17 171.33.128.0/21 176.74.224.0/19 178.18.80.0/20 185.3.208.0/22 185.10.48.0/22 185.15.248.0/22 185.21.188.0/22 185.65.52.0/22 185.69.232.0/22 185.76.236.0/22 185.84.72.0/22 185.89.152.0/22 185.95.68.0/22 185.96.4.0/22 185.105.204.0/22 185.105.216.0/22 185.108.112.0/22 185.110.172.0/22 185.110.200.0/22 188.240.52.0/22 188.241.148.0/22 193.93.172.0/22 193.138.204.0/22 193.242.119.0/24 194.60.207.0/24 195.8.195.0/24 195.135.195.0/24 213.187.240.0/21 217.21.240.0/20 217.149.128.0/20

2 2

194.87.132.0/22 jumps from AS210654 to AS209654
by Natale Maria Bianchi 19 Apr '22

19 Apr '22

We have just noticed announcements of 194.87.132.0/24, 194.87.133.0/24, 194.87.134.0/24 and 194.87.135.0/24 coming from AS209654. They seem a bit bizarre since: - AS209654 is assigned to an ISP in Lebanon that does not seem to be using it at this time. - 194.87.132.0/22 is assigned to Des Capital B.V (aka "Serverion") in NL - The same entity is also the assignee of AS210654 (note similarity of the number). - It was indeed AS210654 that was announcing these networks until very recently. https://stat.ripe.net/widget/bgplay#w.resource=194.87.132.0%2F24 shows the recent activity. Just bringing this to the attention of the community, given that this ISP is, let us say, "a bit problematic". Cheers, Natale M Bianchi Spamhaus Project

1 0

Fwd: RFC 9228 on Delivered-To Email Header Field
by Dave Crocker 14 Apr '22

14 Apr '22

Folks, This was just issued. It will aid in evaluating handling history of a message, especially through aliasing and mailing list sequences. d/ -------- Forwarded Message -------- Subject: RFC 9228 on Delivered-To Email Header Field Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: rfc-editor(a)rfc-editor.org, drafts-update-ref(a)iana.org A new Request for Comments is now available in online RFC libraries. RFC 9228 Title: Delivered-To Email Header Field Author: D. Crocker, Ed. Status: Experimental Stream: Independent Date: April 2022 Mailbox: dcrocker(a)bbiw.net Pages: 10 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-crocker-email-deliveredto-10.txt URL: https://www.rfc-editor.org/info/rfc9228 DOI: 10.17487/RFC9228 The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations. It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information. Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns. A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC -- Dave Crocker Brandenburg InternetWorking bbiw.net

1 0

Information request on skill gaps in ICT (security) education
by Wout de Natris 14 Apr '22

14 Apr '22

Dear colleagues, In this email I draw your attention to research currently being undertaken in the IGF’s Internet Standards, Security and Safety Coalition (IS3C). It has not been able to find volunteers from Europe and North America, the reason why I call on you with the request to conduct one interview. IS3C’s working group on education & skills works towards these goals: * To detect and resolve cyber security skill gaps in tertiary ICT education curricula; * To encourage tertiary educational institutions to include in their ICT curricula the essential skills, knowledge and understanding of security- related Internet standards and ICT best practices, building on current best practices, in order to bring tertiary education in line with emerging workforce requirements; * To strengthen collaboration between educational decision-takers and policy makers in governments and industry in order to align tertiary ICT curricula with the requirements of our cyber future; * To ensure effective collaboration between key stakeholders in order to keep tertiary ICT educational materials in step with new technologies and standards and prevent new skills gaps from developing. To identify the skill gap and determine current good practices, we are in search of people who have the expertise asked for and can "self-interview" or interview one colleague with experience in recruitement of recently graduated youths entering the work force. The workload involves asking five questions and to report the answers in an interview reporting tool. Should you be able to assist the working group members, please contact me at denatrisconsult (at) hotmail (dot) nl<mailto:denatrisconsult@hotmail.nl> so I can share further information with you. The results are open source and will be shared openly. More information on (how to join) IS3C you can find on the IGF website: https://www.intgovforum.org/en/content/internet-standards-security-and-safe… Best regards, Wout de Natris IS3C coordinator IS3C: Making the Internet more secure and safer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - De Natris Consult Kamerlingh Onnesstraat 43 Tel: +31 648388813 2014 EK Haarlem Skype: wout.de.natris denatrisconsult(a)hotmail.nl<mailto:denatrisconsult@hotmail.nl> http://www.denatrisconsult.nl Blog http://woutdenatris.wordpress.com

1 0

Someone on this list has been hacked
by Hans-Martin Mosner 14 Apr '22

14 Apr '22

Hi folks, looks like someone on this list had their PC and/or mailbox hacked, I got a "reply" to one of my mails trying to make me open some link (probably malware). This stuff is pretty common, but it feels a bit weird that it happened through someone who's active in anti-abuse and presumably not a noob :-) This is what I got (since the link does not include an URL scheme, I consider it fairly safe to post here) > HI THERE, > > The data file you wanted is available down below. > > > 1)eddieserotica.com/eu/uocfqimediifa > > > Please tell me in case you have any questions. Cheers, Hans-Martin

4 3

LEA Transparency Report 2021
by Lina Tarasonyte 06 Apr '22

06 Apr '22

Dear colleagues, We have published a transparency report that details the nature of the requests we received from Law Enforcement Agencies in 2021. You can find the report at: https://www.ripe.net/publications/docs/ripe-779 <https://www.ripe.net/publications/docs/ripe-779> Kind regards, Lina Tarasonyte Legal Counsel RIPE NCC

1 0

Re: [anti-abuse-wg] ORG-OG2-RIPE -- plusserver.com / plusserver.de
by Christian Adler 06 Apr '22

06 Apr '22

Hi All, you are completely right. This is not acceptable and I escalate this to my collegues who are in charge of this problem. Kind Regards Christian I just wanted to make you all aware that whereas most networks require any spam report to include the entire spam message, attempting to include an actual spam sample in an abuse report sent to ORG-OG2-RIPE aka plusserver.com<http://plusserver.com> results in an an undeliverable (5xx) bounce message contain text like the following: <abuse at plusserver.com<https://lists.ripe.net/mailman/listinfo/anti-abuse-wg>>: host mx01.hornetsecurity.com<http://mx01.hornetsecurity.com>[94.100.132.8] said: 554 5.6.3 Your mail contains SPAM. To unblock visit http://cloud-security.net/unblock?REDACTED (in reply to end of DATA command) Is is of course admirable that this network is able to accurately recognize -inbound- spam messages so accurately. It is rather a shame however that this network is apparently incapable of doing likewise when it comes to spam flowing outwards from their network. For reference, the fully aggregated set of IPv4 CIDRs currently assigned to this network within the RIPE region is as follows: 46.22.32.0/20 46.23.208.0/20 46.163.80.0/22 46.163.88.0/21 46.163.100.0/22 46.163.120.0/21 46.231.88.0/21 62.75.128.0/23 62.75.131.0/24 62.75.132.0/23 62.75.135.0/24 62.75.140.0/24 62.75.153.0/24 62.75.154.0/24 62.75.172.0/24 62.75.174.0/24 62.75.176.0/24 62.75.180.0/24 62.75.205.0/24 62.75.206.0/24 62.75.212.0/24 62.75.226.0/23 62.75.231.0/24 62.75.239.0/24 62.138.64.0/18 62.138.192.0/18 78.138.64.0/19 78.138.108.0/22 78.138.112.0/22 78.138.116.0/23 78.138.119.0/24 78.138.120.0/22 78.138.124.0/23 80.86.80.0/24 80.86.88.0/23 80.237.131.0/24 80.237.134.0/24 80.237.140.0/23 80.237.152.0/21 80.237.176.0/20 80.237.192.0/23 80.237.196.0/22 80.237.200.0/21 80.237.208.0/22 80.237.213.0/24 80.237.216.0/21 80.237.224.0/20 80.237.240.0/21 80.237.250.0/24 80.242.128.0/19 83.169.48.0/22 83.169.56.0/21 83.220.128.0/19 85.25.18.0/23 85.25.21.0/24 85.25.22.0/23 85.25.24.0/23 85.25.28.0/22 85.25.65.0/24 85.25.69.0/24 85.25.70.0/24 85.25.80.0/21 85.25.88.0/22 85.25.96.0/23 85.25.101.0/24 85.25.111.0/24 85.25.121.0/24 85.25.158.0/24 85.25.175.0/24 85.25.212.0/24 85.25.221.0/24 85.25.234.0/24 85.25.240.0/23 85.25.245.0/24 85.25.247.0/24 85.119.200.0/21 87.119.192.0/23 87.119.194.0/24 87.119.196.0/22 87.119.200.0/21 87.119.208.0/21 87.119.216.0/22 87.230.36.0/22 87.230.50.0/23 87.230.52.0/22 87.230.56.0/22 87.230.65.0/24 87.230.72.0/22 87.230.82.0/23 87.230.96.0/21 87.230.108.0/23 87.230.120.0/22 87.230.124.0/23 87.230.127.0/24 89.19.224.0/19 91.209.52.0/24 91.250.72.0/21 91.250.92.0/22 91.250.104.0/22 92.51.152.0/21 92.51.168.0/23 92.51.171.0/24 92.51.172.0/22 92.51.176.0/22 92.51.184.0/21 93.187.112.0/21 151.106.64.0/19 176.28.24.0/21 176.28.60.0/23 176.28.63.0/24 178.77.88.0/21 178.77.120.0/22 178.77.125.0/24 178.77.126.0/23 185.55.68.0/22 185.209.64.0/22 188.64.192.0/21 188.138.64.0/22 188.138.80.0/24 193.33.20.0/23 193.34.200.0/25 194.15.144.0/24 194.24.192.0/19 194.64.0.0/16 194.163.16.0/20 194.163.64.0/18 194.163.192.0/18 194.195.0.0/18 194.195.64.0/20 194.195.96.0/20 194.195.128.0/18 194.195.192.0/20 194.195.224.0/20 194.233.0.0/18 194.233.112.0/20 194.233.128.0/19 194.233.192.0/18 195.177.0.0/18 195.179.0.0/17 195.179.128.0/18 195.179.208.0/20 195.179.240.0/20 195.180.0.0/16 195.191.26.0/23 195.206.128.0/19 195.244.96.0/19 195.252.128.0/18 212.1.32.0/19 212.40.160.0/24 212.40.166.0/24 212.40.168.0/24 212.40.174.0/23 212.40.176.0/24 212.40.181.0/24 212.40.182.0/23 212.40.186.0/24 212.116.0.0/19 212.224.0.0/18 213.131.224.0/19 213.174.32.0/19 213.203.192.0/18 217.69.64.0/19 217.115.136.0/22 217.115.140.0/24 217.115.144.0/24 217.115.148.0/22 217.119.48.0/24 217.119.51.0/24 217.119.52.0/23 217.119.55.0/24 217.119.57.0/24 217.119.58.0/23 217.119.60.0/22 217.172.163.0/24 217.172.165.0/24 217.172.166.0/23 217.172.168.0/23 217.172.173.0/24 217.172.174.0/23 217.172.191.0/24 Christian Adler Senior Network Engineer PlusNetwork Squad [cid:C81E12D7-E9A9-4037-8236-00A6D211C61E] +49 40 77175-763 Christian.Adler(a)plusserver.com<mailto:Christian.Adler@plusserver.com> PlusServer GmbH Nagelsweg 33-35 20097 Hamburg HRB 84977 / Amtsgericht Köln Geschäftsführer: Alexander Wallner (CEO), Dr. Frank Nellissen

2 1

Anti-Abuse Training - Next iteration of goals and design
by Markus de Brün 05 Apr '22

05 Apr '22

Hi all, Gerardo has incorporated the feedback from the "Abuse Handling Training Call" and also the recent "Anti-Abuse Open House" into the draft. You can find the updated version here: https://docs.google.com/document/d/10BNul-6Y47kMhJOlVLuyaUXi6C4mF_cRD03CE52… If you have any additional feedback, please send your comments by 15th of april. Regards, Markus

1 0

ORG-SOVF2-RIPE -- "Oleksandr Siedinkin" -- thehost.ua
by Ronald F. Guilmette 02 Apr '22

02 Apr '22

Sending a spam report to this network results in the following ignorebot reply: ------------------------------------------------------------------------------ Mailbox confirmation Hello. You sent an email to our support team, but unfortunately you are not registered in our customer support system. In order for the message to be accepted, you need to follow the link https:// my.thehost.com.ua/manager/billmgr?func=confirmemail&code= REDACTED and confirm the registration. TheHost Team Official website - TheHost.ua TheHost - Hosting-provider Customer support - support(a)thehost.ua TelegramFacebookInstagramVKTwitter ------------------------------------------------------------------------------ My feeling is that one should not have to register in order to simply report spam received from any given network. Thus I've decided to locally blacklist all RIPE blocks currently assigned to this network. The fully aggregated set of these is as follows: 45.154.116.0/22 88.218.188.0/22 91.223.180.0/24 91.234.32.0/22 176.114.0.0/20 185.166.216.0/22 185.230.88.0/22 185.252.24.0/22

1 0