- swinog - vmaill01.sys

##### SwiNOG #36 - Call for Papers & Sponsors (2019-Nov-14) #####
by Steven Glogger 29 Jul '19

29 Jul '19

Dear SwiNOG supporter, this is the official Call for Paper email. Please submit your proposal via https://www.swinog.ch/cfp/ <https://www.swinog.ch/cfp/> The 36th meeting of the Swiss Network Operators Group (SwiNOG) will be held in Berne on top of the Gurten on Thursday November 14th 2019. Important Dates for https://www.swinog.ch/meetings/swinog36/: 29.07.2019 Call for Papers 19.08.2019 Registration opens 31.10.2019 Final publication of agenda 03.11.2019 Registration closes 08.11.2019 Deadline for all slides 14.11.2019 Meeting day Topics for Presentations/Talks The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 5 to 45 minutes. Here is a non-exhaustive list of typical SwiNOG meeting topics: Security, DDOS Mitigation, IPv6 Open Source tools and interesting Github projects International view of the internet (incidents, outages, measurements) Routing Server applications (DNS, Web, etc.) Legal issues (BüPF, etc.) Telecommunication politics (Net Neutrality, Incumbent monopoly, etc.) -> PLEASE feel free to talk to us about any kind of topic and collaboration!!! You can always start a discussion on the list - I'm sure people join in. Language of Slides and Talks The whole day will be held in English, therefore we kindly ask you to produce your presentation in English. Be aware that in general we will record your presentation on video and publish it on Youtube (unless disapproved). Submission Guidelines All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you to fill in the form at https://www.swinog.ch/cfp/ <https://www.swinog.ch/cfp/> We also welcome suggestions for specific presentations which you feel would be valuable to the SwiNOG community. Please be aware that your presentation will be published on the SwiNOG website after the event. We can publish modified slides if requested - it might be that some confidential data will be presented by you which are not intended for publication on the internet. Call for Sponsors At the moment we don't have yet a sponsor (thus the meeting is not yet fixed). If you are interested to be part of SwiNOG #36 as sponsor or supporter, please get in touch with us. For more informations about sponsoring opportunities check out: http://www.swinog.ch/sponsor Greetings, Steven Glogger SwiNOG Core Team General Information (SwiNOG Community) The Swiss Network Operators Group (SwiNOG) is an informal group of people who are concerned with engineering and operation of the Swiss Internet. SwiNOG exists to enhance the quality of Internet services available in Switzerland. It does this by fostering the free exchange of technical ideas and information between different companies and organisations. SwiNOG is a community for professionals who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about SwiNOG can be found at http://www.swinog.ch/ <http://www.swinog.ch/>, Facebook, Xing, Information about the meeting will be published at http://www.swinog.ch/meetings/swinog36 <http://www.swinog.ch/meetings/swinog36>/ General Information (SwiNOG Organisation) The SwiNOG Organisation Association is a non-profit association under article 60 and further of the swiss civil law. It manages the SwiNOG community ressources (domain, web, mailing-lists, etc..) and organises SwiNOG meetings. Contact: SwiNOG Organisation 8000 Zurich Switzerland

1 0

Fwd: [nog-org] Free BGP related training material
by Arnold Nipper 23 Jul '19

23 Jul '19

Just wanted to share this info w/ you. Cheers and enjoy summertime Arnold -------- Weitergeleitete Nachricht -------- Betreff: [nog-org] Free BGP related training material Datum: Tue, 23 Jul 2019 11:06:15 +0200 Von: Mirjam Kuehne <mir(a)ripe.net> An: nog-org(a)ripe.net Dear colleagues, The Network Startup Resource Center (NSRC) is maintaining a wealth of training material related to BGP, Peering, IXPs, Routing Security etc.: https://learn.nsrc.org/bgp Maybe interesting to pass on to your communities? Kind regards, Mirjam Kühne RIPE NCC _______________________________________________ nog-org mailing list nog-org(a)ripe.net https://lists.ripe.net/mailman/listinfo/nog-org -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

openssl 1.1.1c and too short DH key on @bluewin.ch
by Benoît Panizzon 17 Jul '19

17 Jul '19

Hi List If you also noticed emails not being delivered anymore to @bluewin after uprading to Debian Buster or and other system with newer openSSL libraries. This is due to new versions of openSSL not accepting DH keys shorter than 1024 to counter the logjam attack. Unfortunately the keys provided by bluewin are too short, causing the TLS handshake to fail. Work-Around for now: Disable DH Test with: # openssl s_client -cipher 'DEFAULT:!DH' -connect \ mxbw.lb.bluewin.ch:smtp -starttls smtp In sendmail.mc O CipherList=HIGH:!DH -Benoît-

2 1

[misc] Research project on blacklists
by Anushah Hossain 16 Jul '19

16 Jul '19

Hi everyone, I'm a researcher at UC Berkeley and the International Computer Science Institute. My colleagues and I are working on evaluating and improving the accuracy of blacklists. As part of this work, we'd like to hear from you about the blacklists you currently use, what you perceive as their strengths and weaknesses, and any thoughts you have on how they might be improved. We've prepared an anonymous survey where you can share your views: https://berkeley.qualtrics.com/jfe/form/SV_200mg5hnQiAOgUl If you have five to ten minutes free today to fill it out, I would greatly appreciate your help! Thank you, and please don't hesitate to respond to me with comments or questions. Best, Anushah -- Anushah Hossain, PhD Student Energy and Resources Group, UC Berkeley

1 0

Call for presentations and RIPE 79
by Franziska Lichtblau 15 Jul '19

15 Jul '19

Dear colleagues, Please find the CFP for RIPE 79 below or at: https://ripe79.ripe.net/submit-topic/cfp/. The deadline for submissions is *16 August 2019*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. However, on an individual basis, participants can apply for a RIPE Fellowship or RACI, see the "Speakers" paragraph in CFP for more information. Kind regards, Franziska Lichtblau RIPE PC Chair https://ripe79.ripe.net/ripe-pc/ ---------------------------------------------------------------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. *RIPE 79 will take place from 14-18 October in Rotterdam, The Netherlands* The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 79. See the full descriptions of the different presentation formats: https://ripe79.ripe.net/submit-topic/presentation-forma ts/ Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *16 August 2019*. Proposals submitted after this date will be considered depending on the slots still available in the programme. The PC is looking for presentations covering the topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) _____________________________________________________ Speakers _____________________________________________________ Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. Please note that participants can apply for a RIPE Fellowship or RACI, on an individual basis, to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship https://www.ripe.net/participate/ripe/raci In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc(a)ripe.net. _____________________________________________________ Submissions _____________________________________________________ Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe79.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non- commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and should not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes in total for both the presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe79.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe79.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. _____________________________________________________ Diversity and Inclusion - On-Site Childcare and the RIPE _____________________________________________________ Meeting Code of Conduct _____________________________________________________ Did you know that RIPE Meetings now have on-site childcare? You can reserve a spot for your child (age 6 months - 10 years) during the registration process for the meeting. Childcare places are limited, so please be quick to reserve a spot for your child while registering for the meeting. More information at: https://ripe79.ripe.net/on-site/on-site-childcare/ Ensuring that RIPE Meeting values are upheld and that attendees experience a professional, respectful and safe meeting is a priority. Please do read the RIPE Meeting Code of Conduct: https://www.ripe.net/participate/meetings/ripe-meetings/ripe-meeting-code-o… _____________________________________________________ If you have any questions or requests concerning content submissions, please email pc(a)ripe.net. -- Franziska Lichtblau, Forschungsgruppe Internet Architecture (INET) Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken E1 4 - Raum 514 fon +49 681 9325 3514 mobil: +49 176 63897173 gpg-fp: 4FA0 F1BC 8B9A 7F64 797C 221C C6C6 2786 91EC 5CD5

1 0

bluewin & DNSNULL
by Andreas Fink 11 Jul '19

11 Jul '19

Does any one have a clue what DNSNULL means in the following context of a mail delivery error? <....(a)bluewin.ch <mailto:claudine.beaud@bluewin.ch>> (mx-v02.bluewin.ch <http://mx-v02.bluewin.ch/>: 554 mxbw.lb.bluewin.ch <http://mxbw.lb.bluewin.ch/> vim dzmsp-mxin12.bluewin.ch <http://dzmsp-mxin12.bluewin.ch/> Swisscom AG IP: 79.134.251.203, You are not allowed to send us mail. Please see DNSNULL if you feel this is in error)Reporting-MTA: dns; mail.fink.org <http://mail.fink.org/> Arrival-Date: Thu, 11 Jul 2019 11:19:58 +0200 ... Andreas Fink ------------------------------------------------------------------ Paradieshofstrasse 101, 4054 Basel, Switzerland andreas(a)fink.org <mailto:andreas@fink.org> https://www.fink.org <https://www.fink.org/> Mobile: +41-78-6677333 Office: +41-61-6666330 Home: +41-61-6666345 Skype: andreasfink Jabber/XMPP: andreas(a)fink.org <mailto:andreas@fink.org> ICQ: 8239353 Twitter: @kiwi66 PGP Key: https://www.fink.org/FILES/afink-pgp.asc ------------------------------------------------------------------

3 2

Re: [swinog] swinog Digest, Vol 174, Issue 3
by Andreas Fink 11 Jul '19

11 Jul '19

Except that this is not applicable. In my case my mailserver is not hosted at Swisscom but on my own infrastructure, is on the same IP since years, has proper MX records and reverse DNS entries and has delivered email to the same bluewin customer yesterday successfully. Only the reply on that receiver today which I received and replied again got rejected. And the response is cryptic to me. And if you mail to abuse(a)bluewin.ch <mailto:abuse@bluewin.ch> you get the same error... So who is this famous DNSNULL I should contact? > On 11 Jul 2019, at 13:49, Florin sfetea <f_sfetea(a)yahoo.com> wrote: > > See https://community.swisscom.ch/t5/E-Mail/Bluewin-akzeptiert-E-Mails-von-eige… <https://community.swisscom.ch/t5/E-Mail/Bluewin-akzeptiert-E-Mails-von-eige…> > > > Beste Grüsse, Regards si s-auzim de bine > Florin Sfetea > > From: swinog-request(a)lists.swinog.ch <mailto:swinog-request@lists.swinog.ch> > Sent: Thursday, July 11, 2019 12:00 > To: swinog(a)lists.swinog.ch <mailto:swinog@lists.swinog.ch> > Subject: swinog Digest, Vol 174, Issue 3 > > Send swinog mailing list submissions to > swinog(a)lists.swinog.ch <mailto:swinog@lists.swinog.ch> > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog <http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog> > or, via email, send a message with subject or body 'help' to > swinog-request(a)lists.swinog.ch <mailto:swinog-request@lists.swinog.ch> > > You can reach the person managing the list at > swinog-owner(a)lists.swinog.ch <mailto:swinog-owner@lists.swinog.ch> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of swinog digest..." > > > Today's Topics: > > 1. bluewin & DNSNULL (Andreas Fink) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Jul 2019 11:32:38 +0200 > From: Andreas Fink <afink(a)list.fink.org <mailto:afink@list.fink.org>> > To: "swinog(a)swinog.ch <mailto:swinog@swinog.ch>" <swinog(a)swinog.ch <mailto:swinog@swinog.ch>> > Subject: [swinog] bluewin & DNSNULL > Message-ID: <75DA5D85-1A68-4D10-94B8-6237FD9D54DB(a)list.fink.org <mailto:75DA5D85-1A68-4D10-94B8-6237FD9D54DB@list.fink.org>> > Content-Type: text/plain; charset="us-ascii" > > > Does any one have a clue what DNSNULL means in the following context of a mail delivery error? > > > > <....(a)bluewin.ch <http://bluewin.ch/> <mailto:claudine.beaud@bluewin.ch <mailto:claudine.beaud@bluewin.ch>>> (mx-v02.bluewin.ch <http://mx-v02.bluewin.ch/> <http://mx-v02.bluewin.ch/ <http://mx-v02.bluewin.ch/>>: 554 mxbw.lb.bluewin.ch <http://mxbw.lb.bluewin.ch/><http://mxbw.lb.bluewin.ch/ <http://mxbw.lb.bluewin.ch/>> vim > dzmsp-mxin12.bluewin.ch <http://dzmsp-mxin12.bluewin.ch/> <http://dzmsp-mxin12.bluewin.ch/ <http://dzmsp-mxin12.bluewin.ch/>> Swisscom AG IP: 79.134.251.203, You are not allowed > to send us mail. Please see DNSNULL if you feel this is in error)Reporting-MTA: dns; mail.fink.org <http://mail.fink.org/> <http://mail.fink.org/ <http://mail.fink.org/>> > Arrival-Date: Thu, 11 Jul 2019 11:19:58 +0200 > ... > > > > Andreas Fink > ------------------------------------------------------------------ > Paradieshofstrasse 101, 4054 Basel, Switzerland > andreas(a)fink.org <mailto:andreas@fink.org> <mailto:andreas@fink.org <mailto:andreas@fink.org>> https://www.fink.org <https://www.fink.org/> <https://www.fink.org/ <https://www.fink.org/>> > Mobile: +41-78-6677333 Office: +41-61-6666330 Home: +41-61-6666345 > Skype: andreasfink Jabber/XMPP: andreas(a)fink.org <mailto:andreas@fink.org> <mailto:andreas@fink.org <mailto:andreas@fink.org>> ICQ: 8239353 > Twitter: @kiwi66 PGP Key: https://www.fink.org/FILES/afink-pgp.asc <https://www.fink.org/FILES/afink-pgp.asc> > ------------------------------------------------------------------ > > > > > >

2 2

Re: [swinog] swinog Digest, Vol 174, Issue 3
by Florin sfetea 11 Jul '19

11 Jul '19

See https://community.swisscom.ch/t5/E-Mail/Bluewin-akzeptiert-E-Mails-von-eige… Beste Grüsse, Regards si s-auzim de bine Florin Sfetea From: swinog-request(a)lists.swinog.ch Sent: Thursday, July 11, 2019 12:00 To: swinog(a)lists.swinog.ch Subject: swinog Digest, Vol 174, Issue 3 Send swinog mailing list submissions to swinog(a)lists.swinog.ch To subscribe or unsubscribe via the World Wide Web, visit http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog or, via email, send a message with subject or body 'help' to swinog-request(a)lists.swinog.ch You can reach the person managing the list at swinog-owner(a)lists.swinog.ch When replying, please edit your Subject line so it is more specific than "Re: Contents of swinog digest..." Today's Topics: 1. bluewin & DNSNULL (Andreas Fink) ---------------------------------------------------------------------- Message: 1 Date: Thu, 11 Jul 2019 11:32:38 +0200 From: Andreas Fink <afink(a)list.fink.org> To: "swinog(a)swinog.ch" <swinog(a)swinog.ch> Subject: [swinog] bluewin & DNSNULL Message-ID: <75DA5D85-1A68-4D10-94B8-6237FD9D54DB(a)list.fink.org> Content-Type: text/plain; charset="us-ascii" Does any one have a clue what DNSNULL means in the following context of a mail delivery error? <....(a)bluewin.ch <mailto:claudine.beaud@bluewin.ch>> (mx-v02.bluewin.ch <http://mx-v02.bluewin.ch/>: 554 mxbw.lb.bluewin.ch <http://mxbw.lb.bluewin.ch/> vim dzmsp-mxin12.bluewin.ch <http://dzmsp-mxin12.bluewin.ch/> Swisscom AG IP: 79.134.251.203, You are not allowed to send us mail. Please see DNSNULL if you feel this is in error)Reporting-MTA: dns; mail.fink.org <http://mail.fink.org/> Arrival-Date: Thu, 11 Jul 2019 11:19:58 +0200 ... Andreas Fink ------------------------------------------------------------------ Paradieshofstrasse 101, 4054 Basel, Switzerland andreas(a)fink.org <mailto:andreas@fink.org> https://www.fink.org <https://www.fink.org/> Mobile: +41-78-6677333 Office: +41-61-6666330 Home: +41-61-6666345 Skype: andreasfink Jabber/XMPP: andreas(a)fink.org <mailto:andreas@fink.org> ICQ: 8239353 Twitter: @kiwi66 PGP Key: https://www.fink.org/FILES/afink-pgp.asc ------------------------------------------------------------------

1 0

*****SPAM***** Re: *****SPAM***** bluewin & DNSNULL
by Claudio Kuenzler 11 Jul '19

11 Jul '19

Spam detection software, running on the system "mail01.infiniroot.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Not sure about the bluewin severs, but my server sent your mail immediately to spam because of this: 8.5 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist [URIs: mail.fink.org] Might be the same or related to this. Content analysis details: (7.6 points, 7.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL blocklist [URIs: fink.org] 8.5 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist [URIs: fink.org] The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

Call for Presentations European Peering Forum 14 (EPF14) // SwiNOG
by Arnold Nipper 10 Jul '19

10 Jul '19

Dear Community This is the Call for Presentations European Peering Forum 14 (EPF14) AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th September 2019. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu>. Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Presentation Abstract Deadline 15/07/2019 12:00 UTC Final Selection of Speakers 26/07/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC More information about the event and other activities around EPF14 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1486607564933665/ Best regards Arnold -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 1

Fwd: Teilrevision GebV-ÜPF: Vernehmlassungsverfahren / Révision partielle OEI-SCPT; procédure de consultation / Revisione parziale OEm-SCPT; procedura di consultazione
by Roman Hochuli 03 Jul '19

03 Jul '19

FYI

1 0

Geldspielgesetz: Zugangssperren Q&A
by Benoit Panizzon 28 Jun '19

28 Jun '19

Hallo zusammen Nachdem ich ausgiebigen Kontakt mit Suissedigital hatte, hier noch ein paar Infos zusammengefasst, welche Euch vermutlich auch interessieren könnte. F: Wann muss dies umgesetzt sein? A: Die Behörden sind noch nicht so weit. Es gibt keine Liste von zu sperrenden Domains, welche am 1. Juli publiziert wird. Es wird vermutlich Herbst, bis eine erste Liste publiziert wird. F: Muss jeder ISP selber diese Stoppage hosten, auf welcher die Besucher der gesperrten Domains geleitet werden sollen? Wer bezahlt die Hosting Kosten? A: Nein, die Behörden hosten diese Seite bereits, um auch schnell Anpassungen am Text und den Informationen auf der Seite vornehmen zu können. In der technischen Dokumentation sei die IP Adressen zum Eintragen in die DNS Zonenfiles zu finden (ich habe diese nicht gefunden, Suissedigital konnte sie mir auf Anhieb nicht nennen, kennt die jemand?). ISP mit Bedenken betreffend dem Schutz der Privatspäre Ihrer Kunden, dürfen dies aber auch selber Hosten. Ein Template ist auf der Webseite der ESBK erhältlich. F: Werden die Emails mit den Sperrlisten irgendwann als Emails versendet oder nur umständlich als .eml Download angeboten? Wie erfährt man, wenn eine neue Liste publiziert wird? A: Vorgesehen war der Versand per Email, dies ist aber auf wenig Akzeptanz bei den Providern gestossen, daher werden die .eml Dateien der Emails als Work-Around zum Download angeboten. Nicht schön, hat 'Verbesserungspotential' (Text-Datei anstatt .eml). An eine Lösung für eine Notification über Updates der Liste wird gearbeitet. F: 99% der Casino Seiten benutzen SSL. Stimmt das SSL Cert der Sperrseite nicht, kriegt der Besucher nur eine Fehlermeldung und sieht so die Informationen warum die Seite gesperrt ist nicht. Wird mit der CA des Bundes daher gültige Zertifikate für alle gesperrten Domains generiert? A: Ja, dies ist ein Problem welches nicht gelöst ist. Es ist nicht vorgesehen, dass die Sperrseite ein gültiges Zertifikat haben soll und der Problematik dass die Browser dann eine Fehlermeldung anzeigen sind sich alle bewusst. Suissedigital ist froh um Tipps, wie man dieses Problem lösen könnte. F: Was passiert mit dem MX Einträgen zu diesen Casinos? Müssen wir sicherstellen dass Email noch funktioniert? Sprich die Original MX Einträge in die Zonenfiles kopieren? SPF Einträge auch? Oder könnte man ein 'Zentrales' Zonenfile generieren und die verschiedenen Hostnamen darauf zeigen lassen und der Bund betreibt dann einen SMTP Relaying Server der sicherstellt, dass Emails an die Casino Domain richtig weitergeleitet werden (und diese möglicherweise mit liest). A: An das Thema wurde noch gar nicht gedacht. Noch eine Bemerkung am Rande: Die meisten versendeten PDF Dokumente haben ungültige Links. Man hat dies bei der ESBK erst kürzlich bemerkt und werde diese Dokumente nochmals korrigiert versenden. :-) Mit freundlichen Grüssen -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 ______________________________________________________

11 12

Geldspielgesetz: Zugangssperren. Wirklich vom Volk so gewünscht?
by Benoit Panizzon 26 Jun '19

26 Jun '19

Hallo zusammen Ich darf mich mit der Aufforderung der Eidgenössische Spielbankenkommission und Suissedigial auseinandersetzen die gewünschten DNS Sperren bei uns per 1. Juli einzurichten. Es geht mir hierbei hauptsächlich um die technische Umsetzung, so dass der Wunsch der ESBK wirklich umgesetzt wird. * Muss der Traffic auf Port 53 intercepted werden, damit Kunden keine eigene DNS Server mehr betreiben können und nicht die DNS Server von Google und CloudFlare nutzen können? Wir möchten vor allem verhindert, dass durch diese Aktion unsere Kunden mehr zu Google & Co getrieben werden und diesen noch mehr Daten über ihr Nutzugsverhalten zur Verfügung stellen. * Wir setzen wir vom Bakom gewünscht DNSSEC Validierung ein. Woher erhalten wir gültige Keys für die DNS Zonen welche wir 'hijacken'? Suissedigital sagt mir, es gehe nur einzig darum, auf unseren 'Caching' DNS Server die genannten Domains zu sperren, damit die Kunden diese darüber NICHT resolven können. Alles andere sei nicht verlangt. Ich habe eingewendet, dass dies absolut nutzlos sei, da die Kunden sehr genau wissen, wie dies zu umgehen ist. Suissedigital wie auch Bakom stimmen mir hier zu. Suissedigital sagt mir aber diese DNS Sperren seien bei einer Volksabstimmung Thema gewesen und das Volk habe, obwohl von allen Experten immer wieder darauf hingewiesen wurde, dass dies nicht funktioniert, sich für die Variante DNS Sperren entschieden. Interessant, ich müsste diese Volksabstimmung doch irgendwie mitgekriegt haben. Stimmt dies? Wie setzt ihr dies um? Mit freundlichen Grüssen -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 ______________________________________________________

5 8

What are the legal requirements of swiss email providers to identify users?
by Benoit Panizzon 17 Jun '19

17 Jun '19

Hi List Lately we received mass advertizement emails sent via protonmail.com an email provider offering freemail and commercial email accounts. One of the first statements on their website is: Quote: "ProtonMail is incorporated in Switzerland and all our servers are located in Switzerland. This means all user data is protected by strict Swiss privacy laws" So I suppose, as we other ISP all do, they have to keep logs for 6 months and are required to somehow verify the identity of their customers prior to offering them a service. So I asked them to provide the identity of their 'mass advertizement' sending customer to ask this customer for a proof of opt-in or existing customer relationship, as intended by swiss privacy laws. They promptly terminated the account in question, but stated that they do not keep any logs and have no means to identify whom the account belongs to. => is this legal? Mit freundlichen Grüssen -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 ______________________________________________________

2 1

Fwd: Teilrevision GebV-ÜPF: Vernehmlassungsverfahren / Révision partielle OEI-SCPT; procédure de consultation / Revisione parziale OEm-SCPT; procedura di consultazione
by Roman Hochuli 14 Jun '19

14 Jun '19

FYI

2 1

please unsuscribe me
by Stefano.Calvo＠swisscom.com 11 Jun '19

11 Jun '19

1 0

SafeHost AS21217 accused to leak routes for two hours to China Telecom AS4134 - anyone from SafeHost to comment?
by Fredy Kuenzler 09 Jun '19

09 Jun '19

https://blog.apnic.net/2019/06/07/large-european-routing-leak-sends-traffic… -- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland http://www.init7.net/

8 8

RIPE NCC Survey 2019
by Arnold Nipper 08 Jun '19

08 Jun '19

Dear SwiNOG-Community please find enclosed a message from RIPE NCC. --------------------------- schnipp --------------------------- The RIPE NCC Survey 2019 is now online. https://www.ripe.net/survey We ask you to take part in this survey for the RIPE NCC and the RIPE community. By taking part, this will help the RIPE NCC build a strategy that will best benefit the Internet community in Luxembourg and throughout the entire service region, but you will also have a chance to win one of five iPads if you complete the survey. You have until 30 June 2019 to participate. --------------------------- schnapp --------------------------- Cheers, Arnold -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

SwissNeutralNet want to provide Internet connectivity over DSL/fiber
by Florian Siegenthaler 13 May '19

13 May '19

Hello SwiNOG list ! SwissNeutralNet is an non-profit association for net neutrality in Switzerland like others ISP in French region under the federation of FFDN (we are not actually member but it's a goal) -> https://www.ffdn.org/en. Actually we are over 30 members, and everyone can join us to support net neutrality. We aim to provide Internet connectivity with neutral rules like non discrimination on traffic, fixed IP address v4/v6 and to prove this is possible. For the moment our website is writed in french, it's not finished, i want to translate it in english, and why not in the future in german and italian if a person is interested to do that. In 2018 we have become a RIPE member (AS200601), we obtained a last /22 IPv4 block from 185.0.0.0/8 and one IPv6 prefix. We have an infrastructure in a datacenter in Lausanne, for the moment we are able to provide automated VPN service and we want to provide Internet access directly to our members which subscribe to the service (yes, we don't have customer), each person want to obtain our services need to become member in SwissNeutralNet. To be able to provide connectivity to our members by copper/fiber lines, we take some informations from Swisscom Wholesale and the price is very very high (page 6/8 from this document if it's correct: https://www.swisscom.ch/dam/swisscom/en/ws/documents/E_BBCS-Documents/d_bbc… ). 100'000 CHF for a BBCS interconnexion to provide connectivity on local loop is correct ? How an enterprise which want to enter in the market can be a provider at this cost ? I know there is some costs to provide lines, to install and maintain cables under roads etc, but if this price is the official cost, how a little enterprise can enter in the market ? Okay, today we need to enter in the market for our goals about net neutrality, and we don't have much money to spend it into /dev/null so we ask you how we can provide Internet access via local loop at a reasonable price ? Which of you, if you have a copper/fiber collect interconnexion with Swisscom, would be interested to cooperate with us for some DSL/fiber lines ? We would be happy to read you in private at info(a)swissneutral.net for your proposition/partnership and to reply to your message. And of course it's very interesting to discuss here about solutions, tips and idea about access to local loop. I'm happy to meet you in a future event, i cannot be present tomorrow at SwiNOG #35 in Berne. Best regards -- Florian Siegenthaler Association SwissNeutral.net Fournisseur d'accès associatif à but non lucratif florian(a)swissneutral.net https://www.swissneutral.net/

1 1

Init7 is about to reconnect SwissIX
by Fredy Kuenzler 08 May '19

08 May '19

As some may know Init7 decided to leave SwissIX at the end of 2018 mainly to protest against the recent policy of the not-for-profit SwissIX association. A decade ago SwissIX was completely volunteer driven, offering peering infrastructure for no recurring fee. This had changed over time and ended in an very high fee for a 10gig port of CHF 750 per month (including a 2nd port for redundancy), which is a lot of money, comparing other exchanges with similar size and structure such as LONAP and considering current hardware pricing. As a matter of fact, SwissIX ports were twice as expensive as the commercial internet exchange of Equinix in Zürich. This resulted in accumulation of cash on SwissIX bank account, as well as rather high consulting fees paid to people which apparently abandoned the community volunteering idea of the association. For more details please refer to http://lists.swinog.ch/public/swinog/2018-December/007105.html What happend since then: The SwissIX board reconsidered their price policy quicker than expected and lowered port prices to a reasonable level with effect of beginning of 2019. After all Init7's protest leave was for good, as everybody has to pay less ... you may show your gratitude by sending a 10pack of your favorite beer to Winterthur - delivery address in the footer ;-) Init7 is now back and currently reconnecting with two redundant 10gig: in the recently established site of green.ch in Lupfig, along with e-shelter in Rümlang. The connections should be ready in a few days, as we are waiting for cross connect delivery. A few words about our peering policy - please consider before sending a request: 1. Init7 AS13030 is not peering with SwissIX Route Servers 2. Init7 is not peering with transit customers or customer customers 3. Init7 expects you to setup 4 BGP sessions (v4, v6 to each router) without MD5 4. Init7 expects you to have an up-to-date PeeringDB record 5. Any peering request should be sent to peering at init7 dot net exclusively 6. If there is more traffic than a few hundred Mbps, Init7 expects you to setup at least one preferred PNI in any common location to offload traffic and dependency from public infrastructure 7. Init7 expects you to send beer - ehm no So here we are again, because peering matters. Happy peering! Fredy on behalf of Init7, SwissIX President 2004 - 2009 -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/

1 0

Strange NTP packet loss
by Stefan Brand 03 May '19

03 May '19

Hi everyone, We[1] are running some public NTP servers that are included in the NTP Pool[2]. In recent months we've had some issues with our servers being marked as unavailable by the monitoring host that tracks availability for the pool. The logs from the NTP pool website showed high packet loss. However we could not see any issues on our side and pings from the looking glass closest to the monitoring host didn't show any packet loss at all. After quite some debugging we realized that the packet loss only occurs for NTP packets via one of our transit providers, namely Liberty Global (AS6830). We queried their support, our theory being that they're trying to do some sort of DDoS protection for NTP reflection attacks. However they aren't aware of anything like this and also couldn't figure out why this is happening. So I was wondering, has anyone else encountered this issue or something similar? We worked around the issues by routing the traffic around AS6830 but this still bothers me somehow. Kind regards and see you soon at Swinog #35, Stefan [1] https://nine.ch [2] https://www.ntppool.org/user/ninech

2 2

### SwiNOG#35 - May 8th - Agenda ###
by Simon Ryf 23 Apr '19

23 Apr '19

Dear SwiNOGers, I’m happy to present the final agenda of SwiNOG#35 If you have not registered yet, please do it now and let your friends and colleagues know ;-) 08:15 | Registration, Coffee & Gipfeli 09:15 | Welcome, Agenda | Simon Ryf (SwiNOG) 09:20 | How to grow IPv6 only services | Nico Schottelius (ungleich glarus ag) As an IPv6 first Data Center, we are looking at IPv6 from a technological and marketing perspective. In this talk I will show our findings in how users reacted towards IPv6 (only) offers, which challenges we encountered on this path and which strategies aid in building and selling IPv6 only services. IPv6 adoption is often compared to the chicken or the egg problem. At the end of the talk I will present you with 2 (strongly biased) solutions to it. 09:45 | Network Telemetry and Big Data - Part 1 | Thomas Graf, Paolo Lucente & Zongren Liu (Swisscom) This presentation with demo shows the collaboration with Swisscom to advance Network Telemetry and Big Data technologies in two parts. Swisscom explains, from a Service Provider viewpoint, the challenges in virtualization and why Swisscom believes this is a key topic to gain visibility in their networks and improve quality. This includes flow aggregation, BMP and Streaming Telemetry for forwarding-plane, control-plane and topology/device metrics. We will underline the importance of schema conversion and registration and the current challenges to align Big Data (data processing, storage and analytics) and Network Telemetry (data collection). We are going to demo flow aggregation and streaming telemetry. Paolo Lucente is going to present the open source project pmacct. Its versatility to cover flow technologies such as IPFIX, BMP and last but not least streaming telemetry metrics where Paolo and Swissscom co-developing. 10:30 | Coffee Break 11:00 | Network Telemetry and Big Data - Part 2 | Christian Kuster (Huawei) Huawei is going to present the new Swisscom Broadband network Sultan, what part Network Telemetry and Big Data plays there and how Huawei supports Swisscom with their innovations and close collaboration. 11:45 | RIPE RPKI | Massimiliano Stucchi (RIPE) tbd 12:05 | SwissIX Update | Manuel Schweizer (SwissIX) Traditional SwissIX update 12:15 | Lunch 13:45 | The State of Internet Security: 2019 | Rayhaan Jaufeerally There are a wide range of technologies that have been developed to secure core Internet infrastructure, however not all of them have yet been widely deployed to reap their benefits. In this presentation we present a selection of these technologies, investigate what security properties they will provide given sufficient adoption, and look at the current deployment status. Specifically we focus on three core areas: interdomain routing, Public Key Infrastructure, and the Domain Name System. In interdomain routing we look at mechanisms to validate routing control protocol messages (Resource Public Key Infrastructure, and Border Gateway Protocol Security), in PKI we focus on the Certificate Authority ecosystem and Certificate Transparency, and for DNS security we look at DNSSEC, and DNS over HTTPS. 14:15 | machine Learning in action - L7 Behavioral Analysis for DDoS detection | Carine Polaillon (F5) tbd 14:40 | The State of DNSSEC Implementation in Switzerland | Michael Hausding (SWITCH) DNSSEC, the DNS Security Extensions was introduced more than 10 years ago. The adoption of DNSSEC in Switzerland was slow for the last 10 years, but gained some momentum in the last 24 months. What is the reason behind a growing number of DNSSEC signed domain names and more ASNs having validating resolvers in Switzerland? Will the recommendation of ICANN for DNSSEC after the recent attacks help with the implementation of DNSSEC in Switzerland? What can hosters and ISPs do to secure the basic DNS infrastructure in Switzerland. 15:05 | Everything is a Freaking DNS problem - dnsdist to the rescue | Dominic Lüchinger (cyon GmbH) DNS plays a crucial part in any network infrastructure. dnsdist, a DoS- and abuse-aware loadbalancer, can help you mitigate the risk of a downtime that occur during maintenance work, attacks and configuration errors. We share our experience putting dnsdist in front of our nameservers and resolvers. With the help of the many built-in stats, we were able to improve the performance even further. 15:35 | Coffee Break 16:05 | Managing sleep with a resilient DNS infrastructure | Jeroen Massar (Quickline AG) The talk will discuss deploying both an Authoritive and Recursive DNS infrastructure that is resilient against outages of network (DoS, misconfiguration), datacenter and people with the ultimate goal of very rarely having ops folks awake during the night. We'll discuss the combination of various open source projects in combination with the techniques that achieve this goal and how we have deployed the setups without anybody noticing. 16:35 | Buffer Sizing Revisited | Simon Leinen (SWITCH) Routers and switches need buffers to accommodate traffic bursts. But how big should those buffers be? The elders recommended RTT*bottleneck bandwidth[Villamizar1994], but more recent work suggests we can get away with much less. We will look at economic and performance trade-offs of small vs. big buffers in light of recent trends in forwarding hardware and transport protocol evolution. 17:00 | grey energy used by data traffic | Kordian Caplazi The goal of my thesis is to calculate the grey energy imported and exported in Switzerland, which is generated by the data traffic of the internet. Today it is already done for consumer products such as clothes or cars, but not for the internet. For the internet our approach is to map the total traffic and its energy consumption along the route. A more detailed view on the energy consumption and therefore the greenhouse gas production will be achieved by splitting the traffic by country and its sources for energy production. 17:05 | How not to integrate Access CPEs | Pascal Gloor (Quickline AG) you'll see ;-) 17:15 | Roundup | Simon Ryf (SwiNOG) 17:20 | Social Event Many thanks to your sponsors for this event Huawei & F5 Hope to see you on the 8th of May Simon SwiNOG

1 0

ipv4 for rent / sale
by sh＠shgh.biz 10 Apr '19

10 Apr '19

Anybody looking for ipv4? We have some unused blocks: /21 /22 /23 /23 PI, RIPE Cheers Sebastian

1 0

Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem
by Müller Urs (IT-OM-SDP-SDN) 01 Apr '19

01 Apr '19

Hello Nico / everybody Yesterday, I was contacted by Silvia (and others) about that task. I was then not registered with that list. Let me introduce me shortly. My name is Urs Mueller. I am working together with my colleague Hans-Peter at SBB in the IT department. We are the stack owners of network & network security on behalf of the IT department. Our network is built and operated by our colleagues from SBB Telecom. IPv6 is a goal we tried to reach since several years, at least since I attended an IPv6 congress in Hannover many years ago. We were struggling with convincing the management to fund projects until last year. The current solution is more or less a workaround and this year, we are trying to achieve a direct connection to our webservers. Currently, there are seeing around 2 Mbit/s incoming and 20 Mbit/s outgoing on IPv6. This is approx. 20% of the total traffic, we are actually handling for our webserver through regular http/s from browsers. This year, we will give more effort on the subject. But our network is quite complex and grown over the years. So there is no way to "just put a box in between and some cables" ;-) If you Nico, would like to contact me about your thesis, feel free. Perhaps we can arrange something. Regards, Urs -----Ursprüngliche Nachricht----- Von: swinog-bounces(a)lists.swinog.ch <swinog-bounces(a)lists.swinog.ch> Im Auftrag von Nico Schottelius Gesendet: Dienstag, 12. März 2019 15:55 An: Silvia Hagen <silvia.hagen(a)sunny.ch> Cc: Nico Schottelius <nico-swinog-2(a)schottelius.org>; swinog(a)lists.swinog.ch Betreff: Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem Hey Silvia, thanks a lot for the insight! I did not expect this answer when asking this morning. I am currently doing my master thesis [0] about IPv6 in fully programmable P4 switches (my hardware platform will be Barefoot Tofino in the end) - I assume this might be rather interesting for SBB, as it potentially can solve all problems [tm] in the network. Also I hear the 6.5 TBit/s switches are not that crazy expensive anymore. If you could get me in touch with the right people at SBB, this would be very interesting to talk about their network. Best, Nico [0] https://gitlab.ethz.ch/nicosc/master-thesis Silvia Hagen <silvia.hagen(a)sunny.ch> writes: > Hi guys > > Here's some info from SBB (I was working with them and just spoke with them today). > > . They are aware of the problem. > . The problem only happens when someone uses smaller packet sizes (often when using some tunnelling techniques). > . Currently the webserver is in an IPv4 zone, the Internet router is a Cisco box which does 64 Translation. The packets go through an F5 LB to reach the webserver. > . When the packets go out and the Cisco box asks for fragmention, it sends the ICMP packet to the webserver. The F5 box has a bug, something with the checksum goes wrong and the F5 discards the ICMP packet. > . They have had a neverending incident with F5 and F5 does not seem to be able to fix that. SBB has given up on this incident. > > The plan: > . SBB is currently enabling IPv6 on the routing layer, plan to be accomplished by summer 2019. > . Next step on the plan is to enable v6 out to the datacenter, with priority on the webserver zone. So with that the problems should go away. > > SBB was attending the last swinog event in Switzerland. They will also come again and they offered to have a talk if desired. I can connect to the right person if you are interested. > > Thanks, Silvia > > > -----Ursprüngliche Nachricht----- > Von: swinog-bounces(a)lists.swinog.ch > [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Nico > Schottelius > Gesendet: Dienstag, 12. März 2019 10:33 > An: swinog(a)lists.swinog.ch > Betreff: [swinog] SBB.ch / IPv6 MTU / fragmentation problem > > > Good morning, > > is anyone from sbb.ch reading here? > > https://sbb.ch does not load on IPv6 for us. > It seems that packets > 1420 bytes are dropped inside the SBB network, > > Local PMTU / fragmentation seems to work, my local outgoing MTU is 1420. MTR below. > > Best, > > Nico > > > [10:23] line:~% mtr -w -c1 -s 1500 sbb.ch > Start: 2019-03-12T10:24:17+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 11.2 11.2 11.2 11.2 0.0 > 2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 69.8 69.8 69.8 69.8 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 74.3 74.3 74.3 74.3 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 69.4 69.4 69.4 69.4 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 69.1 69.1 69.1 69.1 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 58.0 58.0 58.0 58.0 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 62.8 62.8 62.8 62.8 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 65.4 65.4 65.4 65.4 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 75.2 75.2 75.2 75.2 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 78.4 78.4 78.4 78.4 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 81.0 81.0 81.0 81.0 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 64.4 64.4 64.4 64.4 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 84.4 84.4 84.4 84.4 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 81.3 81.3 81.3 81.3 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 67.0 67.0 67.0 67.0 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > [10:24] line:~% mtr -w -c1 -s 1400 sbb.ch > Start: 2019-03-12T10:24:35+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 3.2 3.2 3.2 3.2 0.0 > 2.|-- 2a0a:e5c1:100::1 0.0% 1 69.0 69.0 69.0 69.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 74.7 74.7 74.7 74.7 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 69.9 69.9 69.9 69.9 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 60.5 60.5 60.5 60.5 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 75.3 75.3 75.3 75.3 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 70.7 70.7 70.7 70.7 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 69.1 69.1 69.1 69.1 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 54.6 54.6 54.6 54.6 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 75.9 75.9 75.9 75.9 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 78.8 78.8 78.8 78.8 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 79.8 79.8 79.8 79.8 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 69.9 69.9 69.9 69.9 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 77.5 77.5 77.5 77.5 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 59.3 59.3 59.3 59.3 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 70.1 70.1 70.1 70.1 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 18.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 19.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 20.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 21.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 22.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 23.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 24.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 25.|-- 2a00:4bc0:ffff:ffff::c296:f58e 0.0% 1 58.3 58.3 58.3 58.3 0.0 > [10:24] line:~% > > [10:25] line:~% mtr -w -c1 -s 1420 sbb.ch > Start: 2019-03-12T10:25:44+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 16.3 16.3 16.3 16.3 0.0 > 2.|-- 2a0a:e5c1:100::1 0.0% 1 77.0 77.0 77.0 77.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 67.0 67.0 67.0 67.0 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 66.7 66.7 66.7 66.7 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 78.8 78.8 78.8 78.8 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 64.5 64.5 64.5 64.5 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 68.3 68.3 68.3 68.3 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 74.9 74.9 74.9 74.9 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 73.6 73.6 73.6 73.6 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 62.2 62.2 62.2 62.2 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 74.3 74.3 74.3 74.3 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 63.6 63.6 63.6 63.6 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 69.1 69.1 69.1 69.1 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 77.4 77.4 77.4 77.4 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 78.8 78.8 78.8 78.8 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 75.7 75.7 75.7 75.7 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 18.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 19.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 20.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 21.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 22.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 23.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 24.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 25.|-- 2a00:4bc0:ffff:ffff::c296:f58e 0.0% 1 83.8 83.8 83.8 83.8 0.0 > [10:25] line:~% mtr -w -c1 -s 1430 sbb.ch > Start: 2019-03-12T10:25:55+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 7.3 7.3 7.3 7.3 0.0 > 2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 60.4 60.4 60.4 60.4 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 61.9 61.9 61.9 61.9 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 72.2 72.2 72.2 72.2 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 65.2 65.2 65.2 65.2 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 64.9 64.9 64.9 64.9 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 64.9 64.9 64.9 64.9 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 71.7 71.7 71.7 71.7 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 64.4 64.4 64.4 64.4 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 63.2 63.2 63.2 63.2 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 77.9 77.9 77.9 77.9 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 64.5 64.5 64.5 64.5 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 63.5 63.5 63.5 63.5 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 81.7 81.7 81.7 81.7 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 74.4 74.4 74.4 74.4 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > [10:26] line:~% > > > icmp6, frag works locally: > > 10:29:44.919328 IP6 2a0a:e5c1:111:111:3185:e802:6548:658c > > 2a00:4bc0:ffff:ffff::c296:f58e: frag (0|1368) ICMP6, echo request, seq > 33000, length 1368 > 10:29:44.919368 IP6 2a0a:e5c1:111:111:3185:e802:6548:658c > > 2a00:4bc0:ffff:ffff::c296:f58e: frag (1368|92) -- Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch. _______________________________________________ swinog mailing list swinog(a)lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

2 1

Swisscom operating Business Customer Mailservices from 'Mobile' IP Ranges?
by Benoit Panizzon 15 Mar '19

15 Mar '19

Hello List We have some issues with emails sent from the kpt.ch online plattform over Swisscom Mobile IP Range: inetnum: 138.188.0.0 - 138.188.255.255 netname: Swisscom-Mobile country: CH There is no SPF entry and the sending ip addresses are not listed by dnswl.org nor the Swinog Whitelist, causing greylisting to delay emails (containing login tokens valid for a couple of minutes only) from those potentially infected end customer ip ranges :-) Has Swisscom started to assign IP Addresses from this range to it's email sending platform? The hostname and swisscom's own SPF entry let's me suspect this is the case: mailout153.swisscom.com[138.188.176.153] spf.swisscom.com descriptive text "v=spf1 ip4:193.222.81.224/27 ip4:193.222.81.96/27 ip4:194.11.148.48/28 ip4:194.11.148.64/28 ip4:194.6.164.0/24 ip4:138.190.12.80/28 ip4:138.190.12.32/27 ip4:138.188.176.0/26 ip4:138.188.176.128/26 ip4:138.188.166.96/27 ~all" Well I guess I add those ranges to the SWINOG Whitelist. Mit freundlichen Grüssen -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 ______________________________________________________

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog