A friend just told me that Cybernet told him there is a Switzerlandwide Internet Problem.
Does anybody know something?
Online Consulting AG, Michele Capobianco, System Administrator, Weststrasse 38, CH-9500 Wil
Phone +41 (0)71 913 31 31, Fax +41 (0)71 913 31 32
SWITCH is organising a one day DNSSEC training together with PowerDNS
The training will be given at the following dates:
9.4. Zurich, SWITCH
10.4. Bern, Uni
11.4. Carouge HESGE
The one day training will give you an introduction into DNSSEC and show you how to sign DNS zones on an autoritative DNS server.
We will use PowerDNS for the practical and hands on part. PowerDNS contains support for DNSSEC, enabling the easy serving of DNSSEC secured data, with minimal administrative overhead.
• Short introduction to DNSSEC
• how DNSSEC works
• keys / signatures / NSEC / NSEC3
• Working with DNSSEC and the PowerDNS Authoritative server
• Short overview over PowerDNS Authoritative server backends (MySQL, PostgreSQL, BIND, pipe, ...)
• DNSSEC signing
• Pre-signed zones
• Zone transfers
• Utilities (pdnsutil)
• The PowerDNS ALIAS record (and its future)
Required skills: Unix system administrator skills and DNS server know how.
The training will be delivered in english.
More information and registration here:
Michael Hausding, Competence Lead DNS & Domain Abuse
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 77, incident phone +41 44 268 15 40
I've just come across a weird mail reception problem of some mails from Microsoft. Our servers insist that
a specified MAIL FROM address can be resolved correctly, and this usually boils down to the following checks
on the domain-part of the email-address specified:
- is there an MX? Does the target resolve using an A record (not a CNAME), and does it resolve to a publically
reachable address (not RFC1918 or localhost etc)
- if there is no MX, is there an A record that fulfils the same criteria as the MX target above?
- if none of these are true, the address is considered to be invalid and mail is rejected
Since about Feb 15, I've now come across mails from account-security-noreply(a)accountprotection.microsoft.com that
get rejected. When I manually perform the above steps, I can see why, and I also see a first: the domain part is
actually a CNAME, something I've not encountered mentioned in standards as being a legal way to perform address
resolution when delivering email. But, I also don't recall reading about rules that explicitly deny this, contrary
to the very explicit rules that for example deny having MX point to CNAME. The domain setup here is borked in multiple
$ host -t mx accountprotection.microsoft.com
Host accountprotection.microsoft.com not found: 3(NXDOMAIN)
$ host -t a accountprotection.microsoft.com
Host accountprotection.microsoft.com not found: 3(NXDOMAIN)
$ host -t cname accountprotection.microsoft.comaccountprotection.microsoft.com is an alias for mail.msa.msidentity.com.
and even if we should allow use of a CNAME here, we'd have to apply the same rules as stated initially on the
CNAME target, and these fail as well:
$ host -t mx mail.msa.msidentity.com.
Host mail.msa.msidentity.com not found: 3(NXDOMAIN)
$ host -t a mail.msa.msidentity.com.
Host mail.msa.msidentity.com not found: 3(NXDOMAIN)
So, what's your take on this? Does someone see a legal way to resolv this sender, that I've missed? Am I right in
considering these addresses to be unresolvable and thus reject these mails? Who would I have to report this to at
Microsoft to have any chance of a human person looking at the issue?
Please find the CFP for RIPE 76 below or at:
The deadline for submissions is *11 March 2018*.
Please also note that speakers do not receive any extra reduction or
funding towards the meeting fee at the RIPE Meetings, see the "Speakers"
paragraph in CFP for more information.
RIPE PC Member
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 76 will take place from 14-18 May in Marseille, France.
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 76.
See the full descriptions of the different presentation formats,
Proposals for plenary sessions, BoFs, panels, workshops and tutorials
must be submitted for full consideration no later than *11 March 2018*.
Proposals submitted after this date will be considered depending on the
remaining available space in the programme.
The PC is looking for presentations covering 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)
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.
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. Also note that, on an individual basis, participants
can apply for a RIPE Fellowship to develop their professional or
academic career. For more information, please visit:
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:
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 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
- Tutorials: up to two hours (Monday morning)
- Workshops: one hour (during evening sessions) to two hours (Monday
- BoFs: approximately one hour (during evening sessions)
- Lightning talks: 10 minutes total for both presentation and any
The following general requirements apply:
- Proposals must be submitted using the meeting submission system,
- Lightning talks should also be submitted using the meeting submission
system (https://ripe76.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
- 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.
If you have any questions or requests concerning content submissions,
please email pc(a)ripe.net.
Franziska Lichtblau, M.A. building MAR, 4th floor, room 4.004
Fachgebiet INET - Sekr. MAR 4-4 phone: +49 30 314 757 33
Technische Universität Berlin gpg-fp: 4FA0 F1BC 8B9A 7F64 797C
Marchstrasse 23 - 10587 Berlin 221C C6C6 2786 91EC 5CD5
Hello fellow Swinogers
To exchange emails containing potentially sensitive customer
information with swisscom, we agreed to use PGP encrytped emails.
Now when swisscom is sending an encrypted attachment to us, we get
those MIME Headers:
Content-Type: application/octet-stream; name=Attachment1.asc
X-Content-PGP-Universal-Saved-Content-Type: application/pdf; name=Attachment1.asc
X-Content-PGP-Universal-Saved-Content-Disposition: attachment; filename=Attachment1.asc; size=143718;
creation-date="Tue, 13 Feb 2018 14:56:05 GMT";
modification-date="Tue, 13 Feb 2018 14:56:05 GMT"
Content-Disposition: attachment; filename=Attachment1.asc
-----BEGIN PGP MESSAGE-----
Version: OpenPGP totemomail
Comment: totemomail OpenPGP - http://www.totemo.com
Well, Neither Claws-Mail nor Firefox with Enigma Plugin do understand
those X-Content-PGP Emails which would specify the correct content type
and file name and just merely show a binary "Attachment1.asc" attachement.
Of course, as experienced user reading the email source, you can save
this to disk and then open it with a PDF reader, but using encrypted email
should be easier than that :-)
So I contacted the totemo support and they told me, that every PGP enabled
email client should be able to correctly extract mime-type and filename from
the X-Content-PGP Headers.
Well I have found:
Well, I know no clients which support RFC4880 when generating or decoding PGP
encrypted emails. How about the SWINOG Community?
Mit freundlichen Grüssen
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
We have some issue with sending email to @bluewin.ch. Since a few
months, all Emails sent to bluewin.ch recipients are marked as junk. L
That what we can see:
X-Bluewin-Spam-Analysis: v=2.1 cv=eusSttdX c=1 sm=1 tr=0
a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=Op4juWPpsa0A:10
a=r77TgQKjGQsHNAKrUKIA:9 a=tmi9kOqBNXXKSUpxMQ4A:9 a=CjuIK1q_8ugA:10
a=ZsvHfuFSAAAA:8 a=DGG8EIu7HUducKyVYroA:9 a=IzkmhS4iMz_GUfKi:21
a=QEXdDO2ut3YA:10 a=SJFCsYi-t6UA:10 a=iZBDQVmU8otq4hDR5MHx:22
X-FXIT-IP: IPv4[188.8.131.52] Epoch
If anybody from bluewin/Swisscom, please contact me off list
The RIPE NCC would like to invite you to participate in its Global IPv6
Survey 2018. The goal of the survey is to get an overview IPv6
deployment across the world, and to assess how this is seen from the
perspective of ISPs and Enterprise users.
The 2018 survey is a follow up to similar surveys run between 2008 and
2013, and will serve as a
comparison with the data acquired back then.
You can find the survey at the following address:
Responses can be submitted until 31 March 2018.
We will then collect the data with the aim of presenting the preliminary
results during the upcoming RIPE 76 meeting in Marseille.
If you have any question about the survey, please feel free to email us
Thank you very much in advance for your participation!
IPv6 Programme Manager
Follow us on Twitter for the fastest and latest RIPE NCC Training news!
Good afternoon from AS3303 (Swisscom/IP-Plus).
This e-mail is intended as help information for those of you who operate
IPv4 PI addresses within the following ranges:
for historical reasons, these ranges used to have a status of ALLOCATED
UNSPECIFIED in the RIPE data base and were managed by the ch.unisource
In 2016 the RIPE-NCC has received a mandate from the RIPE Address Policy
working group to transfer these addresses into standard ALLOCATED PA
and ALLOCATED PI addresses, managed by the RIPE-NCC; if interested in
the details, please see
The transfer of these three ranges has been completed recently.
This includes the management responsibility of the related PI
assignments, although, for practical reasons, the Swisscom maintainer
CH-UNISOURCE-MNT has not been removed from some objects yet.
Please find enclosed below the guidelines we received from the RIPE-NCC
with respect to the administration of the related RIPE data base objects.
Thanks for your attention and understanding,
Following the re-organisation of ALLOCATED UNSPECIFIED addresses blocks
formerly managed by CH-UNISOURCE-MNT, the management of the PI assignments
has been transferred to the RIPE-NCC.
Each PI assignment will need to have a "Sponsoring LIR" (a RIPE NCC member
responsible for maintenance, accuracy and communication with regards to a
specific assignment). Please see http://www.ripe.net/ripe/docs/ripe-637#20
Please contact your Sponsoring LIR if you have one. If not, please contact
RIPE NCC, <ncc(a)ripe.net>
Good morning Swinog,
we are planning our first IPv6 focused event this year.
The main topic of the event is, how well the IPv6 deployment of
Switzerland has come and to discuss the action points to reach
100% IPv6 coverage.
Thus I would like to invite you to join and...
... showcase how and where you enabled sites with IPv6
... show difficulties and solutions for IPv6 only networks
... meet players from industry to discuss your needs with others
... get a tasty Adler Bräu beer
We are at an early planning stage, but wanted to begin to spread the
word already (i.e. date to be defined, Website & CfP coming in the next
The format will likely be a 1-2 day event, with talks during the day,
discussion in the late afternoon and a networking event in the evening.
To decide on the exact format, I would like to ask you to give me a
heads up, if you are interested in this event and if you are interested
in showcasing something.
A simple "+1" or "+1 +talk_about_x" suffices.
Depending on the feedback, we will plan for either a 1 or 2 day event.
Thanks a lot and have a great snowy Sunday,
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
I get these errors:
| TLS is required, but was not offered by host mx1.datacomm.ch[184.108.40.206]
| TLS is required, but was not offered by host relay.kfsb.ch[220.127.116.11]
Since I've made TLS for SMTP mandatory. The respective admins of these servers
might want finally at least enable voluntary TLS; some of their customers
apparently would like to receive mails from my server.
And by the way, RFC 2487 that is referred to for instance in the postfix manpage
and stated that one must not make TLS mandatory has been obsoleted by RFC 3207.
"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." -- Benjamin Franklin
"It's also true that those who would give up privacy for security are
likely to end up with neither." -- Bruce Schneier