- swinog - vmaill01.sys

Re: [swinog] Mail rejection at bluewin
by Sébastien Riccio 07 Apr '21

07 Apr '21

Hello Simon, Oops of course yes we found "NO" evidence... I should have re-read myself before sending the post. Thanks for pointing that out 😊 and for the cheers. Kind regards, Sébastien -----Message d'origine----- De : Simon Leinen <simon.leinen(a)switch.ch> Envoyé : mercredi, 7 avril 2021 10:30 À : Sébastien Riccio <sr(a)swisscenter.com> Objet : Re: [swinog] Mail rejection at bluewin Sébastien Riccio writes: [...] > It's the 3rd time it happens in two weeks and we found evidence of > unusual SPAM activity from our servers that would justify such a > ratelimiting/rejecting. You found evidence? Or is there a "no" missing somewhere? (Just trying to understand.) Cheers and good luck with the delivery issues! -- Simon.

1 0

G.Fast DSL modems - bridge only
by Jeroen Massar 01 Apr '21

01 Apr '21

Hi Folks, So there is the list: https://www.swisscom.ch/dam/swisscom/en/ws/documents/E_BBCS-Documents/e_bbc… Anybody got a recommendation out of that for a bridge-only G.Fast modem? Apparently FRITZ!Box 7582 does not do Bridge mode, but Zyxel XMG3927 does. Cisco C1113-8P ISR is a bit much for my purposes (and at 800+ bit much too) Anybody has any positive/negative experiences and/or other recommendations? Greets, Jeroen

7 7

Re: [swinog] Swisscom IPv6 Routing weirdness
by Jeroen Massar 29 Mar '21

29 Mar '21

> On 20210225, at 16:52, Jean-Pierre Schwickerath <swinog(a)hilotec.net> wrote: > > Hi Jeroen >> that "sinkhole" is just a misconfigured/internet-ignorant "load >> balancer": those things do not care about ICMP... >> >> you are thus reaching the dest, it is just misconfigured: the Internet >> is just HTTP for many, they do not care about this TCP, ICMP or IP >> thing... be happy there is some kind of IPv6... >> > I wouldn't have noticed the issue if the loadbalancer / webserver had > actually returned a webpage on port TCP/443. But it doesn't. So I tried > from a different network to see if the issue is reproducible and that > when I noticed the path taken by the traceroute packets. > Check with a tcpdump, don't forget to include ICMP. Could also be an MTU issue or something on your side killing it. Of course the behavior of the "load balancer" says quite a few things... sbb.ch is like that too... >> >> Btw, when complaining about something, it is wise to include IP >> addresses, especially for the source... >> > The first hop of the traceroute is actually a good indicator for the > source. 192.168.205.240 ? DNS is ambiguous and reverses do not always match forwards. Including the actual IPs can thus be very useful... That is, if you actually want it resolved. You might want contact swisscom directly (good luck with that) or at least your ISPs that provide the connectivity, they might have better chance at contacting them. (taking transit over swissix is a fun one; but yea it is not that swisscom likes to peer, what else would a monopoly do) Greets, Jeroen

7 9

DENOG Leadership Meetup #1 -- Save the DATE: Mittwoch 24. März 2021, 18:30 Uhr
by Stefan Funke 16 Mar '21

16 Mar '21

Good afternoon SWINOG! Since SWINOG is also a German-speaking network operator group, I wanted to take the chance to invite you to the first DENOG Leadership Meetup. The new meeting series will start on Wednesday, 24th March 2021, at 18:30 CET. It will come in a variety of different formats and is all about leadership. This series's target audience is people in the network operator community who currently are in leadership roles or are interested in leadership roles, either in your career or voluntary appearances. The first meeting is about leadership and managing a team during a global pandemic, including hidden challenges. You will find more details, the preliminary plan, and a way to register for a free ticket at https://www.denog.de/de/events/leadership.html. The event will be in GERMAN only! Greetings from DENOG. We would be pleased to see you at our Meetup next Wednesday. Regards, -Stefan

2 1

Bluewin SMTP server reachable from outside bluewin/swisscom?
by Jeroen Massar 11 Mar '21

11 Mar '21

Hi, (Possibly in relation to http://lists.swinog.ch/public/swinog/2021-March/007457.html, but in this case not even a TCP ACK...) It seems smtp.bluewin.ch (25 and 465 tested) is unreachable from all places I checked (Init7, Quickline, BIT.nl). Is that service normally open for Bluewin customers to connect to smtp.bluewin.ch? As apparently Swisscom is sending out mails to providers that their customers are complaining that their customers on non-swisscom/bluewin cannot use their SMTP service..... But telnet does not even answer.... (no TCP ACK at all, no ICMP, nada nothing), thus looks like it is firewalled away. Greets, Jeroen

1 3

OVH datacenter SBG2 in Strasbourg on fire 🔥
by Fredy Kuenzler 11 Mar '21

11 Mar '21

Very sad day for our colleagues at OVH AS16276 as they lost their datacenter SBG-2 in Strasbourg completly („everything is destroyed“) in a fire 🔥 and the neighboring SBG1/SBG3/SBG4 at least temporary. https://www.dna.fr/amp/faits-divers-justice/2021/03/10/strasbourg-important… -- Fredy Künzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur https://www.init7.net/

2 1

Coop.ch geoblocking?
by Benoit Panizzon 04 Mar '21

04 Mar '21

Dear List Having issue in accessing www.coop.ch "Aus Sicherheitsgründen ist ein Login aus Ihrem Land nicht erlaubt". And a hint I shall not use a VPN or Proxy. No proxy or VPN in use, just IPv4 NAT, as confirmed by 'wieistmeineip'. (www.coop.ch is not IPv6 yet) So I supposed a messed up GeoIP Database and changed my SNAT IP a couple of times (all those IP are registered with country=CH @RIPE since decades and I never had such issues) 157.161.57.65 => blocked (main NAT ip) 157.161.57.66 => Ok (a static server ip not used anymore) 157.161.57.68 => Ok (a static client ip) 157.161.57.70 => blocked (alternate NAT ip seldom used) 157.161.5.199 => blocked (Gateway IP, not usually used as src, except local stuff on the Mtik like DNS) Weird! Anyone has insight in what geoIP database coop uses? Or if there are other criteria they use for blocking? -- -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

9 9

Swisscom IPv6 Routing weirdness
by Jean-Pierre Schwickerath 25 Feb '21

25 Feb '21

Dear Swisscom Routing-Experts Are you not peeing at swissIX anymore? Your webserver www.swisscom.ch (2a02:a90:c400:4001::2) gives me a hard time to be reached. Either it wants it traffic to be routed from Berne via NL, UK, US and ends in a sinkhole or it uses what looks like using private peering from tineo/netrics/finecom to the same sinkhole: tracepath6 2a02:a90:c400:4001::2 1?: [LOCALHOST] 0.367ms pmtu 1500 1: sv96.hilotec.net 0.776ms 1: sv96.hilotec.net 0.740ms 2: 2a00:c38::1:0:2a 1.538ms 3: lo0.01.p.cbn.ch.as15576.nts.ch 1.725ms 4: lo0.01.p.czh.ch.as15576.nts.ch 4.075ms 5: lo0.02.p.czh.ch.as15576.nts.ch 4.354ms 6: zayog.swissix.ch 10.184ms 7: no reply 8: ae2.cs1.ams17.nl.eth.zayo.com 151.857ms asymm 25 9: no reply 10: no reply 11: no reply 12: ae5.cs1.lhr11.uk.eth.zayo.com 153.354ms asymm 21 13: no reply 14: 2001:438:ffff::407d:1d13 151.202ms asymm 19 15: ae6.cs1.sjc2.us.eth.zayo.com 159.227ms asymm 18 16: ae9.mpr1.pao1.us.zip.zayo.com 152.345ms 17: 2001:438:fffe::2456 153.873ms asymm 10 18: 2001:c10:80:1::e51 259.737ms asymm 10 19: 2001:c10:80:1::b96 265.511ms asymm 11 20: 2001:c10:80:2::ad2 243.109ms asymm 10 21: geb-030-lo0-0.ip6.ip-plus.net 247.019ms asymm 9 22: geb-015-loo6.ip6.ip-plus.net 236.957ms asymm 8 23: gem-005-loo6.ip6.ip-plus.net 242.943ms asymm 8 24: 2001:918:100:63::1 230.491ms asymm 7 25: 2001:918:100:4c::1 240.121ms asymm 8 26: 2001:918:100:52::1 247.741ms asymm 7 27: 2001:918:ce::49 241.013ms asymm 8 28: 2a02:a90:4024:fff::14 247.804ms asymm 9 29: 2a02:a90:4024:fff::15 234.473ms asymm 8 30: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 tracepath 2a02:a90:c400:4001::2 1?: [LOCALHOST] 0.030ms pmtu 1500 1: router.3550.ch 0.418ms 1: router.3550.ch 0.410ms 2: bd4.lar01.lna001.bb.fcom.ch 4.561ms 3: no reply 4: no reply 5: 2001:4d98:a000::1b4 3.218ms asymm 4 6: zhh-015-lo0-0.ip6.ip-plus.net 11.088ms asymm 5 7: 2001:918:ce::45 6.146ms asymm 6 8: 2a02:a90:4024:fff:8000::15 5.452ms 9: no reply 10: no reply 11: no reply 12: no reply 13: no reply 14: no reply 15: no reply 16: no reply 17: no reply 18: no reply 19: no reply 20: no reply 21: no reply 22: no reply 23: no reply 24: no reply 25: no reply 26: no reply 27: no reply 28: no reply 29: no reply 30: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 Is that a management decision or a technical issue? Cheers Jean-Pierre -- HILOTEC Engineering + Consulting AG - Langnau im Emmental IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls Tel: +41 34 408 01 00 - https://www.hilotec.com/

2 1

Bluewin / Swisscom Postmaster Contact
by Michael Naef 25 Feb '21

25 Feb '21

Hi all We (Hostpoint) see increasing problems sending automated Mails to bluewwin recipients (such as account confirmation emails). Respectively we see them identiefd as spam mails. Can a Swisscom/Bluewin Postmaster please get in touch with me/us to identify the cause? Thanks, Michael Naef Head of System Engineering, Hostpoint AG

1 0

Fwd: [ncc-announce] Attack on RIPE NCC Access - Please Enable Two-Factor Authentication
by Massimiliano Stucchi 18 Feb '21

18 Feb '21

-------- Forwarded Message -------- Subject: [ncc-announce] Attack on RIPE NCC Access - Please Enable Two-Factor Authentication Date: Thu, 18 Feb 2021 16:49:59 +0100 From: Ivo Dijkhuis <ivo.dijkhuis(a)ripe.net> To: ncc-announce(a)ripe.net Dear colleagues, Last weekend, RIPE NCC Access, our single sign-on (SSO) service was affected by what appears to be a deliberate ‘credential-stuffing’ attack, which caused some downtime. We mitigated the attack, and we are now taking steps to ensure that our services are better protected against such threats in the future. Our preliminary investigations do not indicate that any SSO accounts have been compromised. If we do find that an account has been affected in the course of our investigations, we will contact the account holder individually to inform them. We would like to ask you to enable two-factor authentication on your RIPE NCC Access account if you have not already done so to ensure that your account is secure. In general, using two-factor authentication across all your accounts can help limit your exposure to such attacks. If you notice any suspicious activity in your RIPE NCC Access account, please contact us immediately at <security(a)ripe.net>. Best regards, Ivo Dijkhuis Senior Information Security Officer, RIPE NCC

1 0

Quad9 moves to Switzerland
by Michael Hausding 17 Feb '21

17 Feb '21

Dear Swinog I am very pleased to inform you first-hand that SWITCH and Quad9 are jointly announcing today the relocation of Quad9's headquarters from California to Zurich. Quad9, a public domain name service, will thus offer its users worldwide maximum internet privacy protection. The move to Switzerland is being facilitated in large part by SWITCH. The joint mission of SWITCH and Quad9 - to provide security and robust services to internet users around the world - was a key factor in this collaboration. More information can be found in the joint media release https://www.switch.ch/news/Quad9-moves-to-Switzerland/ and on the Quad9 website https://quad9.net/ Should you have any questions about this, please don't hesitate to contact me or Quad9 directly. Best regards, Michael ------------------------------------ Michael Hausding, Competence Lead DNS & Domain Abuse SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 77, incident phone +41 44 268 15 40 michael.hausding(a)switch.ch http://securityblog.switch.ch

1 0

Bluewin quarantines outgoing mails
by Maxim Samo 09 Feb '21

09 Feb '21

Hi, Sometimes I have users send me email from bluewin. Those emails can be significantly delayed. An example just came in this morning: Received: from quar.lb.bluewin.ch ([195.186.123.234]) by vimdzmsp-sfwd04.bluewin.ch Swisscom AG with ESMTP id 9FbplVkv74QBH9Fc9l0UVW; Tue, 09 Feb 2021 00:06:41 +0100 Received: from vimdzmsp-sfwd04.bluewin.ch ([195.186.227.132]) by vimdzmsp-quar01.bluewin.ch Swisscom AG with SMTP id 82c8lv39dIuiP82c8lqzVg; Fri, 05 Feb 2021 16:01:41 +0100 Delayed from Friday until Tuesday by quar.lb.bluewin.ch. Quar seems to be short for "quarantine". The sending user had no idea that this happened. I previously asked in the Swisscom community about this and they confirmed that this happens when the server suspects it's spam. The questions I have now though are: - How is the sending user supposed to know that this happened? - It seems that they really expect the sending user to call their support line and ask the mail to be released (!). - How did the mail get released in this case? The length of the quarantine seems to change and you could suspect that it's a human looking through those emails. regards, Maxim

1 0

Bluewin / SMTP UTF8
by Rémy DUCHET 04 Feb '21

04 Feb '21

Hello Swinog, Does anybody from Bluewin can check SMTP host configuration ? It seems that mx doesnt support SMTP UTF8 (we have customers with email address that contains ~ (for example): SMTPUTF8 is required, but was not offered by host mxbw.lb.bluewin.ch[195.186.227.50] Thanks, Rémy

1 0

experiencing DDOS via a drupal GET request
by maj＠mbuf.net 21 Jan '21

21 Jan '21

Hello, this is to share with you that I am experiencing a ddos attack for a webserver I manage. It is a Drupal/PHP/Nginx platform that is flooded with GET requests such as: GET /es/search?f%5B0%5D=language%3Aes&f%5B1%5D=regions%3A4490&f%5B2%5D=regions%3A4511&f%5B3%5D=regions%3A4538&f%5B4%5D=regions%3A4556&f%5B5%5D=regions%3A4567&f%5B6%5D=regions%3A4593&f%5B7%5D=regions%3A4601&f%5B8%5D=regions%3A4603&f%5B9%5D=regions%3A4620&f%5B10%5D=regions%3A4631&f%5B11%5D=regions%3A4674&f%5B12%5D=type_of_content%3A4697&f%5B13%5D=type_of_content%3A4710&f%5B14%5D=type_of_content%3A4857&f%5B15%5D=type_of_content%3A4862&f%5B16%5D=type_of_content%3A4943&f%5B17%5D=type_of_content%3A6249&f%5B18%5D=type_of_content%3A6423&f%5B19%5D=wcc_programmes%3A4882&f%5B20%5D=wcc_programmes%3A4893 It targets the search module which does not cache the data and means resource impact. This involves more than 12'000 individual ip addresses, spread over CN, IN, KO, MX, and US. A list of the subnet part involved can be found here[0]. (list is of course gorwing over time, attack is not over and spread of hosts continue) I plan to further investigate the networks involved, how likely they are cloud nodes or infected hosts for instance. I am on the AS3303/Swisscom BTW. Is anyone experiencing such traffic? This is not huge in terms of bw, but scaled adequately to eat servers cpu resources. Regards. [0] https://www.mbuf.net/files/f/ebbc54f52b564824bf5e/ -- |_|0|_| Julien MABILLARD - Matrix: @jma:matrix.mbuf.net - XMPP: jma(a)tls.mbuf.net |_|_|0| OpenPGP fingerprint: 1E47 513E 8B00 8BC5 E874 23E4 54A4 32FB 260A 2D41 |0|0|0| ssb: @O7yM/4Y0Jcp1uZToeis2AKApyOvb8ZHkoXuAh0wPcAM=.ed25519

1 0

Anyone from AS9009 / GlobalAXS / m247 Zurich NOC?
by Benoît Panizzon 04 Jan '21

04 Jan '21

Happy new Year. If anyone from AS9009 Zurich NOC reads this list. Please contact me off list about a more serious incident involving some of your IP Addresses. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

.ch zone file is open data now
by Michael Hausding 04 Jan '21

04 Jan '21

Dear list Happy new Year! We want to let you know that the the .ch zone file, containing all delegated .ch domain names, is publicly available for download. Access is limited by Article 10(1)(a)(6) of the Ordinance on Internet Domains for combating cybercrime, scientific and social research or for other purposes in the public interest. Details, on how to access the file are available here: https://swit.ch/zonedata, and I also wrote a blogpost https://securityblog.switch.ch/2020/11/18/dot_ch_zone_is_open_data/. If you have any feedback or do anything interesting with the data, please share. Michael ------------------------------------ Michael Hausding, Competence Lead DNS & Domain Abuse SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 77, incident phone +41 44 268 15 40 michael.hausding(a)switch.ch http://securityblog.switch.ch

1 0

Spam from 'Rocketmails.ch'
by Benoît Panizzon 28 Dec '20

28 Dec '20

Dear List Today we received several delisting request for URI's and IP Addresses somehow associated with Newsletters sent by 'Rocketmails.ch'. The listings were caused during the last 14 days or so by multiple customers reporting those emails as spam and claiming not having subscribed, nor being a customer of the advertising company. And I guess I can figure out why... Quote: "Sie erhalten dieses Mailing, weil Sie sich bei unseren Aktionsseiten oder der unserer Werbepartner mit der Email-Adresse XXXX eingetragen haben." There is no mention of WHAT partner or WHAT website they allegedly subscribed. So that could also explain that they don't know the company whose products are advertised via Rocketmails. So for the recipient this is just spam. Anyone else seeing these and knowing more about how the transfer of such personal data happens between those partner and what kind of partners those are? So far no spamtrap hits, so this does not look like harvested addresses. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

10 23

Swiss4net : any experiences with this company ?
by Félix Curinga 20 Nov '20

20 Nov '20

Hi all, If someone is close to a city or a provider having experiences with Swiss4Net , can you please contact me directly. Thanks --félix -- Félix Curinga

1 0

Fwd: [PDB Announce] PeeringDB Satisfaction Survey
by Arnold Nipper 17 Nov '20

17 Nov '20

Guten Abend zusammen, wer mit Interconnection - sei es Colo, IXP oder Netzbetreiber - zu tun hat, dem ist PeeringDB ein Begriff und die gehört zum Toolset. Bitte lasst uns daher eure Meinung wissen. --- Buona sera a tutti, Chiunque si occupi di interconnessione, sia esso Colo, IXP o operatore di rete, conosce PeeringDB ed è parte del set di strumenti. Quindi per favore fateci sapere cosa ne pensate. --- Bonsoir à tous, Quiconque s'occupe de l'interconnexion - que ce soit Colo, IXP ou opérateur de réseau - connaît PeeringDB et fait partie de l'ensemble d'outils. Alors faites-nous savoir ce que vous en pensez. --- Good evening everyone, Anyone who deals with interconnection - be it Colo, IXP or network operator - is familiar with PeeringDB and it is part of your toolset. So please let us know what you think. Gruß Arnold -------- Weitergeleitete Nachricht -------- Betreff: [PDB Announce] PeeringDB Satisfaction Survey Datum: Mon, 2 Nov 2020 07:55:40 -0800 Von: Leo Vegoda <leo(a)peeringdb.com> An: pdb-announce(a)lists.peeringdb.com We want input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. This year we are running an anonymous satisfaction survey in addition to the usual feedback gathering we employ. The survey will be available here: https://surveyhero.com/c/f7be5236 until 23:59 UTC on 20 November 2020. We would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks.This survey will help us understand what is important to you and how satisfied you are with what we are doing. We will use your responses to focus our product roadmap on the improvements that will make things better for you. If you have specific comments or suggestions, we’d love you to leave them along with your ratings. This is the first survey we are making available in multiple languages. In this survey we are using the six UN languages for the questions. That said, we’re happy with people providing free text comments in another whichever language they are happiest expressing themselves. We’ll share the results and the new product roadmap early in 2021. Leo Vegoda on behalf of PeeringDB ProductCom _______________________________________________ Pdb-announce mailing list Pdb-announce(a)lists.peeringdb.com https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

Fwd: [uknof] PeeringDB Satisfaction Survey
by Massimiliano Stucchi 17 Nov '20

17 Nov '20

-------- Forwarded Message -------- Subject: [uknof] PeeringDB Satisfaction Survey Date: Mon, 2 Nov 2020 10:29:01 -0800 From: Leo Vegoda <leo(a)vegoda.org> To: uknof(a)lists.uknof.org.uk PeeringDB is a non-profit, freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. We want input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. This year we are running an anonymous satisfaction survey in addition to the usual feedback gathering we employ. The survey will be available here: https://surveyhero.com/c/f7be5236 until 23:59 UTC on 20 November 2020. We would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks.This survey will help us understand what is important to you and how satisfied you are with what we are doing. We will use your responses to focus our product roadmap on the improvements that will make things better for you. If you have specific comments or suggestions, we’d love you to leave them along with your ratings. This is the first survey we are making available in multiple languages. In this survey we are using the six UN languages for the questions. That said, we’re happy with people providing free text comments in another whichever language they are happiest expressing themselves. We’ll share the results and the new product roadmap early in 2021. Leo Vegoda on behalf of PeeringDB ProductCom

1 0

Fwd: [ncc-announce] [news] LIR Account closure? Notify us by 1 December
by Massimiliano Stucchi 16 Nov '20

16 Nov '20

If you have an LIR account you would like to close before the end of the year, pay attention to this email. -------- Forwarded Message -------- Subject: [ncc-announce] [news] LIR Account closure? Notify us by 1 December Date: Mon, 16 Nov 2020 13:38:00 +0100 (CET) From: henriette(a)ripe.net To: ncc-announce(a)ripe.net Dear RIPE NCC members, We would like to inform you that a request to close an LIR account or any request that will result in the closure of an LIR account should be submitted in full before 1 December 2020. This includes closures that result from policy transfers and changes in business structures. Any requests submitted after this date mean that you could be invoiced for 2021. The request should contain all the requested information and documents in order for the RIPE NCC to process it before the end of the year. An overview of the required documents can be found at: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/req… For requests resulting in the closure of an LIR account that are submitted later than 1 December 2020, or requests that are incomplete, we can not guarantee that the LIR account will be closed before 31 December 2020. Invoices for 2021 will be issued for LIR accounts still open on 1 January 2021. Best Regards, Henriette van Ingen Registry Services Assistant Manager RIPE NCC

1 0

Cloudflare 'relaying' complaints and take down notices to the hosting ISP instead of handling them.
by Benoît Panizzon 12 Nov '20

12 Nov '20

Hi Community A website (no imprint, domain registered via anonymous proxy), which allegedly breaks some copyright laws, is proxied by CloudFlare. CloudFlare got a DMCA take-down notice from an attorney and replied to the attorney, that the site in question is hosted at AS6772, ImproWare AG, but did not tell the attorney the IP Address (nor the customer which could have been looked up via RIPE). Cloudflare also contacted us and told the IP Address. I contacted the customer in question. He states he has nothing to do with that website (I might be tempted to doubt this statement, it could be a customer of the customer who is involved...). But I cannot verify: I have no access to the logs of our customer's Server. I have no access to the proxy logs @ Cloudflare. The attorney is now getting a bit impatient and considers filing a legal complaint against us to have us 'solve the issue'. So I contact Cloudflare as they must have a customer who ordered said proxy service with them and probably pays for it. Cloudflare could handle the issue themself, directly at the source, knowing the paying 'culpit'. I quickly got the reply, that they are not responsible for content hosted by their customer, therefore they relay complaints to the ISP in charge of the IP address in question. That is a bit weird.... isn't it? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 1

Übersetzer für PeeringDB gesucht // SwiNOG
by Arnold Nipper 05 Nov '20

05 Nov '20

[ German only for obvious reasons ] Hallo SwiNOG community seit einiger Zeit gibt es PeeringDB [0] nicht nur in Englisch, sondern in zwölf weiteren Sprachen; unter anderem Deutsch (de_de). Da PeeringDB ständig erweitert wird, sind auch laufend neue Übersetzungen im kleineren Umfang notwendig. Hast du Lust, an der Übersetzung mitzumachen? Ja? * du hast einen PeeringDB-Account [1] * registriere dich auf der Übersetzerliste [2] * melde dich bei dem Übersetzungstool [3] an * fülle dein Profil aus [4] * starte mit der Übersetzung [5] Wenn Du Fragen hast, komm gerne auf mich zu. Viele Grüße Arnold [0] https://peeringdb.com/ [1] https://peeringdb.com/register [2] http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-translate [3] https://translate.peeringdb.com/accounts/login/?next=/ [4] https://translate.peeringdb.com/accounts/profile/ [5] https://translate.peeringdb.com/languages/de/peeringdb/ -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

IANA AS Numbers Registry Update
by Selina Harrington 03 Nov '20

03 Nov '20

Hi, The IANA AS Numbers registry has been updated to reflect the allocation of the following blocks to ARIN: 399261-400284 Assigned by ARIN 2020-11-02 400285-401308 Assigned by ARIN 2020-11-02 You can find the registry at: https://www.iana.org/assignments/as-numbers/ The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries: https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en Best Regards, -- Selina Harrington Lead IANA Services Specialist

1 0

Handling of UCE / RBL while minor misconfigurations
by Mueller Urs SBB CFF FFS 27 Oct '20

27 Oct '20

Hello list I am writing on behalf of a colleague who is operating a small hosting business, mainly focused on the setup of the cms and consulting. He is not on the list and asked me to put his words into it. He had the following dispute with an ISP, but I will let him speak (translation via deepl reviewed by me). --- We run a small hosting business on three managed servers, which we rent from a well-known Swiss ISP and host our customers (SMEs and individuals) there. We have had the misfortune three times that the IP of one of our servers got on the blacklist "UCEprotect" through no fault of our own: http://www.uceprotect.net In each of these cases a Zurich-based ISP was at fault, who apparently is involved in this blacklist - he didn't want to tell us how exactly, but in the first case he still apologized and he was able to remove the IP from the blacklist at short notice without any problems. Therefore we assume that he has a great influence there. The first times the IP was blacklisted because there was a chaos with a telephone system (short: bounces on non-existent addresses). Last week the IP came back on UCEprotect because a customer had edited his SPF entry incorrectly (he forgot to enter the IP of the server) - a single mail from our customer to a customer of the mentioned Zurich provider was already enough for an entry on the RBL. There was neither a spam dispatch nor a spamtrap; the wrong SPF automatically led to a blacklisting of the whole IP with more than 200 hosting customers, who then of course got mail problems. It would be normal and justifiable for a mail to be classified as spam because of a wrong SPF record. However, we find it very questionable that a whole IP is "dragged into the abyss" because of this. Especially since we have been fighting against spam for almost 25 years, keeping our servers clean and thus "fighting on the same side", it is all the more irritating to have such obstacles put in the way by this provider. The fact that customers can adjust the DNS entries and thus the SPF record themselves is normal for many providers. A single hosting customer's mistake should not also affect his provider and dozens of other customers. The methods used for an automatic entry on the blacklist UCEprotect seem at least questionable. I would like to show the provider that he means well, but that it can easily hit the wrong people - and would be grateful for input. After the first case still said "sorry, you've been good to me", there are no more answers to the question whether he really considers these methods to be useful. What do you think can be done here? I don't have time and money for a legal dispute, and blocking any traffic to his IPs to prevent damage to our IPs would probably not be clean either. --- So, what is your opinion on the behavior of this ISP? Me, Urs, I am with my colleague and I think, it's not acceptable to block a whole IP just while receiving one or a small number of mail without a correct SPF. Thank you your thoughts, I will collect it and send it to my colleague. Urs Müller Schweizerische Bundesbahnen SBB Senior Architekt / Product Owner Informatik Operations-Management / CYBER Poststrasse 6 - Ostermundigen, 3000 Bern 65 urs.bf.mueller(a)sbb.ch / www.sbb.ch

10 19

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog