From ietf-dane at dukhovni.org Mon Jan 1 22:49:00 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Jan 2018 21:49:00 +0000 Subject: Update on stats 2017-12 Message-ID: <20180101214900.GL29327@mournblade.imrryr.org> [ Happy New Year! May 2018 see major advances in DANE adoption and even fewer operational issues. ] Summary: The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 125 to 127 The total domain count has increased from 173857 to 176079. The number DNSSEC domains in the survey stands at 5096318, thus DANE TLSA is deployed on 3.46% of domains with DNSSEC. Many DNSSEC domains use third-party MX hosts, that don't have DNSSEC, so they can't benefit from DANE until their providers secure the MX hosts. Please ask your provider to enable DNSSEC and DANE on their MX hosts. [ It would be especially significant if "redirect.ovh.net" were to implement DNSSEC+DANE, if someone personally knows the right people to gently nudge at ovh.net, please do. ] As of today I count 176079 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected the bulk of the DANE domains are hosted by the handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 68824 domeneshop.no 63076 transip.nl 18510 udmedia.de 6318 bhosted.nl 1767 nederhost.nl 1265 yourdomainprovider.net 1003 ec-elements.com 516 core-networks.de 395 omc-mail.com 370 mailbox.org The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1277 GeoIP Country Edition: DE, Germany 770 GeoIP Country Edition: US, United States 450 GeoIP Country Edition: NL, Netherlands 321 GeoIP Country Edition: FR, France 149 GeoIP Country Edition: GB, United Kingdom 102 GeoIP Country Edition: CZ, Czech Republic 74 GeoIP Country Edition: CA, Canada 62 GeoIP Country Edition: CH, Switzerland 60 GeoIP Country Edition: SE, Sweden 58 GeoIP Country Edition: BR, Brazil IPv6 is still comparatively rare for MX hosts, and the top 11 countries by DANE MX host IPv6 GeoIP are: 212 GeoIP Country V6 Edition: DE, Germany 103 GeoIP Country V6 Edition: US, United States 100 GeoIP Country V6 Edition: NL, Netherlands 56 GeoIP Country V6 Edition: FR, France 29 GeoIP Country V6 Edition: GB, United Kingdom 23 GeoIP Country V6 Edition: CZ, Czech Republic 8 GeoIP Country V6 Edition: SE, Sweden 7 GeoIP Country V6 Edition: SG, Singapore 7 GeoIP Country V6 Edition: NO, Norway 7 GeoIP Country V6 Edition: ID, Indonesia 7 GeoIP Country V6 Edition: CH, Switzerland There are 3018 unique zones in which the underlying MX hosts are found, this counts each of the above providers as just one zone, so is a measure of the breadth of adoption in terms of servers deployed. The number of published MX host TLSA RRsets found is 4652. These cover 4742 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 128 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 73 are in recent reports: gmx.at lrz.de ouderportaal.nl travelbirdbelgie.be mail.de overheid.nl travelbirdbelgique.be posteo.de pathe.nl nic.br ruhr-uni-bochum.de uvt.nl registro.br tum.de xs4all.nl gmx.ch uni-erlangen.de domeneshop.no open.ch unitybox.de handelsbanken.no switch.ch unitymedia.de webcruitermail.no anubisnetworks.com web.de aegee.org gmx.com egmontpublishing.dk debian.org isavedialogue.com netic.dk freebsd.org mail.com tilburguniversity.edu gentoo.org solvinity.com octopuce.fr ietf.org t-2.com comcast.net isc.org trashmail.com dd24.net netbsd.org xfinity.com dns-oarc.net openssl.org xfinityhomesecurity.com gmx.net samba.org xfinitymobile.com hr-manager.net torproject.org nic.cz mpssec.net asf.com.pt bayern.de t-2.net handelsbanken.se bund.de xs4all.net t-2.si fau.de bhosted.nl mail.co.uk freenet.de boozyshop.nl govtrack.us gmx.de hierinloggen.nl jpberlin.de otvi.nl Of the ~176000 domains, 785 have "partial" TLSA records, that cover only a subset of the MX hosts. While this protects traffic to some of the MX hosts, such domains are still vulnerable to the usual active attacks via the remaining MX hosts. The number of domains with incorrect TLSA records or failure to advertise STARTTLS (even though TLSA records are published) stands today at 192. Below is a list of the 102 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: white.agoracon.at mx2.pfp.de mail.diejanssens.net mail.dipietro.id.au mail.rleh.de mail.efflam.net mx.krb.srv.pique.net.au mail.schwaho.de mail.lnaze.net zebulon.pique.net.au mx1.spam-sponge.de mail.misbegotten.net eufront.stansoft.bg mx2.spam-sponge.de wfbrace.net eumembers.stansoft.bg mx3.spam-sponge.de mx2.wfbrace.net mail.advokatur4a.ch mx1.spamsponge.de mx2.cbrace.nl andbraiz.com mx2.spamsponge.de mx3.cbrace.nl mail.digitalwebpros.com mx3.spamsponge.de mail.fscker.nl mail.dnsmadefree.com mx10.timotoups.de smtp1.lococensus.nl smtp-1.httrack.com fsck.email smtp2.lococensus.nl mail.i-bible.com mail.0pc.eu mail.myzt.nl demo.liveconfig.com mail2.cesidianroot.eu nuj-netherlands.nl mx01.mykolab.com gamepixel.eu mx2.nuj-netherlands.nl mx02.mykolab.com webmail.kassoft.eu bounder.steelyard.nl mx04.mykolab.com smtp.skolovi.eu mail.abanto-zierbena.org srv2.noneuclideanconcepts.com mail2.subse.eu smtp2.briaeros007.org ma.qbitnet.com smtp.vdlaken.eu eumembers.datacentrix.org stmics01.smia-automotive.com mx.quentindavid.fr genius.konundrum.org stmics02.smia-automotive.com servmail.fr smtps.planchon.org romulus.wittsend.com mail.demongeot.info smtp2.amadigi.ovh mail.zx.com mail.nonoserver.info smtp3.amadigi.ovh mx.bels.cz mx1.email.youwerehere.info mail.bacrau.ro mail.davidbodnar.cz mx2.email.youwerehere.info mail.itconnect.ro mail1.dolnipodluzi.cz mail.rapidfuse.io mx.itconnect.ro mail.machkovi.cz mail2.galax.is mail.pasion.ro gaia.nfx.cz mail.lsd.is mail.familie-sander.rocks petg.cz mx.datenknoten.me mx1.shevaldin.ru mail.zionbit.cz mx.giesen.me halon.gislaved.se mail.absynth.de rootbox.me halon02.gislaved.se mail.all4.de mail.amsx.net mail.labbrack.se mx2.mindrun.de mail.castleturing.net mail1.puggan.se www.mtg.de mail.culm.net mail.rostit.se mail.ocmenzel.de anubis.delphij.net mail.xn----ymcadjpj1at5o.xn--wgbh Some recently notified, but the number of long-term problem MX hosts has been slowly creeping up... Please make sure to monitor the validity of your TLSA records, and implement a reliable key rotation procedure. Let's Encrypt users in particular tend to forget that by default Let's Encrypt certificate renewal replaces both the key and certificate, please read: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 When updating the certificate chain you need to temporarily pre-publish multiple TLSA records matching the current and future certificate: https://dane.sys4.de/common_mistakes#3 However, with "3 1 1" + "2 1 1", the rollover process can be substantially simplified: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://www.ietf.org/mail-archive/web/uta/current/msg01498.html After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 116. The top 6 (the rest have too few domains to include in a top 10) name server operators with problem domains are: 24 firstfind.nl 7 active24.cz 5 tse.jus.br 4 ignum.com 4 glbns.com 4 army.mil Only 2 DNS-broken domains have no working nameservers and also appear in historical Google Email transparency reports: tiviths.com.br trtrj.jus.br The problem DNS queries are: _25._tcp.mx.tiviths.com.br _25._tcp.mx1.trtrj.jus.br [ See , Much of the TLSA non-response issue seems to be related to a "feature" of some firewalls, that enables droping of DNS requests for all but the most common RRtypes. Do not make the mistake of enabling this firewall "feature". ] The oldest outstanding DNS issue is an SOA signature issue at truman.edu dating back to Nov/2014: http://dnsviz.net/d/_25._tcp.barracuda.truman.edu/VGzORw/dnssec/ I hope some day soon they'll start missing email they care about and take the time to resolve the problem. -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security. From bart.knubben at gmail.com Fri Jan 12 15:05:35 2018 From: bart.knubben at gmail.com (Bart Knubben) Date: Fri, 12 Jan 2018 15:05:35 +0100 Subject: EU Commission formally recognizes DANE Message-ID: Hi, "The European multi-stakeholder platform on ICT standardisation evaluated and gave a positive advice to the identification of the following technical specifications for referencing in public procurement: 'SPF-Sender Policy Framework for Authorizing Use of Domains in Email' ('SPF'), 'STARTTLS-SMTP Service Extension for Secure SMTP over Transport Layer Security' ('STARTTLS-SMTP') and 'DANE-SMTP Security via Opportunistic DNS-Based Authentication of Named Entities Transport Layer Security' ('DANE-SMTP') developed by Internet Engineering Task Force (IETF); [...] The evaluation and advice of the platform was subsequently submitted to consultation of sectoral experts who confirmed the positive advice to its identification." "THE EUROPEAN COMMISSION, [...] HAS ADOPTED THIS DECISION: Article 1, The technical specifications listed in the Annex are eligible for referencing in public procurement." For more details please see: http://eur-lex.europa.eu/ legal-content/EN/TXT/?qid=1515759784644&uri=CELEX:32017D2288 -- Best regards, Bart Knubben -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.schulze at datev.de Wed Jan 17 11:10:00 2018 From: andreas.schulze at datev.de (Andreas Schulze) Date: Wed, 17 Jan 2018 11:10:00 +0100 Subject: http://dnsviz.net/d/_25._tcp.sisim1.systemec.nl/dnssec/ Message-ID: <37c4e375-b670-b329-3d45-5cedfde645f8@datev.de> Hello, we found messages to MONTAGEBEDRIJFVANDERPLUIJM.NL undeliverable because postfix/unbound could not fetch _25._tcp.sisim1.systemec.nl The nameservers deny the existence of _tcp.$MXhost.systemec.nl. As our unbound uses QNAME minimization that result in _25._tcp.$MXhost.systemec.nl. also fail. dig @ns.systemec.NL. _tcp.sisim2.systemec.NL any +dnssec ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.9.6-P1 <<>> @ns.systemec.NL. _tcp.sisim2.systemec.NL any +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 769 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1680 ;; QUESTION SECTION: ;_tcp.sisim2.systemec.NL. IN ANY ;; AUTHORITY SECTION: systemec.NL. 3600 IN SOA ns.systemec.NL. postmaster.systemec.NL. 2017113006 28800 7200 604800 3600 systemec.NL. 3600 IN RRSIG SOA 14 2 3600 20180125000000 20180104000000 39248 systemec.nl. mtn3UO0IJXb1WA+2qEp7kYTlqaOAU7qrUcizVJCLQ6Tuda4qgd7fPAO5 qZY9FBQdiP/l4YEEeooZJyMtQilHlLiDK7MBIarIjdNSF2qQrk5hfo1a LJzs5pNW1upEdR51 sisim2.systemec.NL. 3600 IN NSEC _25._tcp.sisim2.systemec.nl. A RRSIG NSEC sisim2.systemec.NL. 3600 IN RRSIG NSEC 14 3 3600 20180125000000 20180104000000 39248 systemec.nl. UUcvXFNUVhyOUHka2Md64YKUNVownhfBsly32lqxHYKJ62JV4/x1XXV/ ckROX7CmON8MvNyVAB8FC1p1qGdjOo+Df1jpJ7oduukbEOqCeOVWdQbO 29CrRHe+84Wl/6iz ;; Query time: 18 msec ;; SERVER: 89.20.90.102#53(89.20.90.102) ;; WHEN: Wed Jan 17 11:03:38 CET 2018 ;; MSG SIZE rcvd: 429 The expected answer is "NOERROR" because the are no valid RRs for that label bit there exist childs ( _25. ) Is the correct term for that "ENT" "Empty non terminal" ??? Maybe someone can relay that information to systemec.nl DNS admins. We implemented a workaround via smtp_tls_policy_maps: "$DOMAIN -> may" until that is fixed. -- A. Schulze DATEV eG From andreas.schulze at datev.de Wed Jan 17 15:56:30 2018 From: andreas.schulze at datev.de (Andreas Schulze) Date: Wed, 17 Jan 2018 15:56:30 +0100 Subject: http://dnsviz.net/d/_25._tcp.sisim1.systemec.nl/dnssec/ In-Reply-To: <37c4e375-b670-b329-3d45-5cedfde645f8@datev.de> References: <37c4e375-b670-b329-3d45-5cedfde645f8@datev.de> Message-ID: <37cf8bf5-c638-3239-05c7-cbe08b16ced0@datev.de> Am 17.01.2018 um 11:10 schrieb Andreas Schulze: > Maybe someone can relay that information to systemec.nl DNS admins. They fixed that issue just today... -- A. Schulze DATEV eG From karol at augustin.pl Sat Jan 20 13:34:58 2018 From: karol at augustin.pl (Karol Augustin) Date: Sat, 20 Jan 2018 12:34:58 +0000 Subject: dane.sys4.net IPv6 problem Message-ID: Hi, Until recently I was using HE tunnel as IPv6 provider until AWS enabled native IPv6 support in my region and everything was working without problems. Since I have enabled native IPv6 on my mail server and have problem with DANE tester site https://dane.sys4.de/smtp/augustin.pl It always times out on IPv6 address and I am confident that everything is configured properly as I receive lots of connections by IPv6 including gmail, Debian and Postfix mailing lists etc. Jan 20 06:32:38 mail postfix/postscreen[17537]: CONNECT from [2604:8d00:0:1::4]:54406 to [2a05:d018:76d:5af6:d050:9b30:6bf7:df98]:25 Jan 20 06:32:38 mail postfix/postscreen[17537]: WHITELISTED [2604:8d00:0:1::4]:54406 Jan 20 06:32:38 mail postfix/smtpd[17538]: connect from russian-caravan.cloud9.net[2604:8d00:0:1::4] Jan 20 06:32:39 mail postfix/smtpd[17538]: Trusted TLS connection established from russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) You can see test results here: https://network-tools.webwiz.net/email-test.htm?email=augustin%2Epl&connectionType=sslexplicit25&TLSProtocol=tls1%2E2&allmx=true&rdns=true&IPv6=true Is there any known problem with DANE tester IPv6 configuration? I appreciate your help. Karol -- Karol Augustin karol at augustin.pl http://karolaugustin.pl/ From karol at augustin.pl Sat Jan 20 13:45:58 2018 From: karol at augustin.pl (Karol Augustin) Date: Sat, 20 Jan 2018 12:45:58 +0000 Subject: dane.sys4.net IPv6 problem In-Reply-To: References: Message-ID: <90074c3aec69132ed8938caeb072f97c@augustin.pl> On 2018-01-20 12:34, Karol Augustin wrote: > Hi, > > > Until recently I was using HE tunnel as IPv6 provider until AWS enabled > native IPv6 support in my region and everything was working without > problems. > Since I have enabled native IPv6 on my mail server and have problem with > DANE tester site https://dane.sys4.de/smtp/augustin.pl > > It always times out on IPv6 address and I am confident that everything > is configured properly as I receive lots of connections by IPv6 > including gmail, Debian and Postfix mailing lists etc. Ok, it looks like I am hitting firewall on mail.sys4.de: Jan 20 12:35:00 mail postfix/smtp[29506]: connect to mail.sys4.de[2001:1578:400:111::7]:25: Permission denied Jan 20 12:35:06 mail postfix/smtp[29506]: Verified TLS connection established to mail.sys4.de[194.126.158.132]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) ping 2001:1578:400:111::7 PING 2001:1578:400:111::7(2001:1578:400:111::7) 56 data bytes >From 2001:1578:0:ff::1:2 icmp_seq=2 Destination unreachable: Administratively prohibited >From 2001:1578:0:ff::1:2 icmp_seq=3 Destination unreachable: Administratively prohibited >From 2001:1578:0:ff::1:2 icmp_seq=8 Destination unreachable: Administratively prohibited Is there any reason for blocking AWS IPv6? > > Jan 20 06:32:38 mail postfix/postscreen[17537]: CONNECT from > [2604:8d00:0:1::4]:54406 to [2a05:d018:76d:5af6:d050:9b30:6bf7:df98]:25 > Jan 20 06:32:38 mail postfix/postscreen[17537]: WHITELISTED > [2604:8d00:0:1::4]:54406 > Jan 20 06:32:38 mail postfix/smtpd[17538]: connect from > russian-caravan.cloud9.net[2604:8d00:0:1::4] > Jan 20 06:32:39 mail postfix/smtpd[17538]: Trusted TLS connection > established from russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 > with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) > > You can see test results here: > https://network-tools.webwiz.net/email-test.htm?email=augustin%2Epl&connectionType=sslexplicit25&TLSProtocol=tls1%2E2&allmx=true&rdns=true&IPv6=true > > Is there any known problem with DANE tester IPv6 configuration? > > I appreciate your help. > > Karol -- Karol Augustin karol at augustin.pl http://karolaugustin.pl/ +353 85 775 5312 From lists at quux.de Sat Jan 20 14:16:20 2018 From: lists at quux.de (Jens Link) Date: Sat, 20 Jan 2018 14:16:20 +0100 Subject: dane.sys4.net IPv6 problem In-Reply-To: <90074c3aec69132ed8938caeb072f97c@augustin.pl> (Karol Augustin's message of "Sat, 20 Jan 2018 12:45:58 +0000") References: <90074c3aec69132ed8938caeb072f97c@augustin.pl> Message-ID: <87wp0c4qmz.fsf@pc8.berlin.quux.de> > Is there any reason for blocking AWS IPv6? I don't think that AWS is blocked but IPv6 prefixes > 32 are. I have the same problem with my mail server which is an /48 PI. Your IP is announced by AWS in a /38: # sh ipv6 route 2a05:d018:76d:5af6:d050:9b30:6bf7:df98 Routing entry for 2a05:d018:400::/38 Known via "bgp", distance 20, metric 0, best Last update 04w0d01h ago * fe80::e6aa:5dff:fe82:e001, via eth0 And as a general tip: Use a TCP variant of traceropute, newer version have -T option for this and also try tracepath(6) so see if there are any MTU issuse. Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From karol at augustin.pl Sat Jan 20 14:56:20 2018 From: karol at augustin.pl (Karol Augustin) Date: Sat, 20 Jan 2018 13:56:20 +0000 Subject: dane.sys4.net IPv6 problem In-Reply-To: <87wp0c4qmz.fsf@pc8.berlin.quux.de> References: <90074c3aec69132ed8938caeb072f97c@augustin.pl> <87wp0c4qmz.fsf@pc8.berlin.quux.de> Message-ID: <890d2b6ef9b6b659e606d5cbfce23eee@augustin.pl> On 2018-01-20 13:16, Jens Link wrote: >> Is there any reason for blocking AWS IPv6? > > I don't think that AWS is blocked but IPv6 prefixes > 32 are. I have the > same problem with my mail server which is an /48 PI. Thanks, it explains it. I was using HE tunnel before and it was working fine. Anyway that seems weird to me to block >32 prefixes especially if the biggest cloud provider in the world is hit by that. Karol > > Your IP is announced by AWS in a /38: > > # sh ipv6 route 2a05:d018:76d:5af6:d050:9b30:6bf7:df98 > Routing entry for 2a05:d018:400::/38 > Known via "bgp", distance 20, metric 0, best > Last update 04w0d01h ago > * fe80::e6aa:5dff:fe82:e001, via eth0 > > And as a general tip: > > Use a TCP variant of traceropute, newer version have -T option for > this and also try tracepath(6) so see if there are any MTU issuse. Yeah, it was the first thing I have checked and there is no problems with MTU. > > Jens -- Karol Augustin karol at augustin.pl http://karolaugustin.pl/ +353 85 775 5312 From bjorn at mork.no Sat Jan 20 15:14:29 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sat, 20 Jan 2018 15:14:29 +0100 Subject: dane.sys4.net IPv6 problem In-Reply-To: <87wp0c4qmz.fsf@pc8.berlin.quux.de> (Jens Link's message of "Sat, 20 Jan 2018 14:16:20 +0100") References: <90074c3aec69132ed8938caeb072f97c@augustin.pl> <87wp0c4qmz.fsf@pc8.berlin.quux.de> Message-ID: <87o9lod3cq.fsf@miraculix.mork.no> Jens Link writes: >> Is there any reason for blocking AWS IPv6? > > I don't think that AWS is blocked but IPv6 prefixes > 32 are. I have the > same problem with my mail server which is an /48 PI. > > Your IP is announced by AWS in a /38: > > # sh ipv6 route 2a05:d018:76d:5af6:d050:9b30:6bf7:df98 > Routing entry for 2a05:d018:400::/38 > Known via "bgp", distance 20, metric 0, best > Last update 04w0d01h ago > * fe80::e6aa:5dff:fe82:e001, via eth0 I don't think that is it. One of my mail servers is fine (in a /32 prefix), but the other one (in a /24 prefix) is not. See https://dane.sys4.de/smtp/mork.no Bj?rn From lists at quux.de Sat Jan 20 15:36:55 2018 From: lists at quux.de (Jens Link) Date: Sat, 20 Jan 2018 15:36:55 +0100 Subject: dane.sys4.net IPv6 problem In-Reply-To: <87o9lod3cq.fsf@miraculix.mork.no> (=?utf-8?Q?=22Bj=C3=B8rn?= Mork"'s message of "Sat, 20 Jan 2018 15:14:29 +0100") References: <90074c3aec69132ed8938caeb072f97c@augustin.pl> <87wp0c4qmz.fsf@pc8.berlin.quux.de> <87o9lod3cq.fsf@miraculix.mork.no> Message-ID: <87shb04mwo.fsf@pc8.berlin.quux.de> Bj?rn Mork writes: Hi, > I don't think that is it. One of my mail servers is fine (in a /32 > prefix), but the other one (in a /24 prefix) is not. just talked to the provider, looks like a wired routing issue, they are working on a fix. Jens, Hm, I somehow sound like all the provider hotline I talked to in the last couple of weeks ;-=) -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From lists at quux.de Mon Jan 22 10:34:03 2018 From: lists at quux.de (Jens Link) Date: Mon, 22 Jan 2018 10:34:03 +0100 Subject: dane.sys4.net IPv6 problem In-Reply-To: <87shb04mwo.fsf@pc8.berlin.quux.de> (Jens Link's message of "Sat, 20 Jan 2018 15:36:55 +0100") References: <90074c3aec69132ed8938caeb072f97c@augustin.pl> <87wp0c4qmz.fsf@pc8.berlin.quux.de> <87o9lod3cq.fsf@miraculix.mork.no> <87shb04mwo.fsf@pc8.berlin.quux.de> Message-ID: <87y3kq2q5w.fsf@pc8.berlin.quux.de> Jens Link writes: > just talked to the provider, looks like a wired routing issue, they > are working on a fix. okay, at least for me it's working now. Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From karol at augustin.pl Mon Jan 22 10:40:35 2018 From: karol at augustin.pl (Karol Augustin) Date: Mon, 22 Jan 2018 09:40:35 +0000 Subject: dane.sys4.net IPv6 problem In-Reply-To: <87y3kq2q5w.fsf@pc8.berlin.quux.de> References: <90074c3aec69132ed8938caeb072f97c@augustin.pl> <87wp0c4qmz.fsf@pc8.berlin.quux.de> <87o9lod3cq.fsf@miraculix.mork.no> <87shb04mwo.fsf@pc8.berlin.quux.de> <87y3kq2q5w.fsf@pc8.berlin.quux.de> Message-ID: <067f9d6d5f9630b28b50027c2ccbdcd8@augustin.pl> On 2018-01-22 9:34, Jens Link wrote: > Jens Link writes: > >> just talked to the provider, looks like a wired routing issue, they >> are working on a fix. > > okay, at least for me it's working now. It's working for me as well. Thanks for looking into that! Karol -- Karol Augustin karol at augustin.pl http://karolaugustin.pl/ +353 85 775 5312