- dane-users - list.sys4.de

ANN: SMTP DANE Verify - self-monitor your DANE policy
by Patrick Ben Koetter 24 Dec '25

24 Dec '25

Greetings! Our this year's Christmas gift to the community is a service that let’s you monitor and detect typical DANE related problems for DANE-enabled inbound SMTP services. You can integrate the service in your own service environment or run it as a docker container and poll it for test results from a monitoring service. ## Why? We believe every platform should enable and use DANE. DANE is the missing piece in TLS or as Wietse Venema once put it: „Encryption without authentication is not 'security'. It just gives some privacy.“ DANE adds the missing authentication bit. But DANE enforces strict policy and if your platform fails inbound DANE-verification you will not receive email from those platforms that enforce outbound DANE-verification. A failing DANE policy imposes a production risk. ## Why would your platform fail DANE verification? From discussions with Viktor about the statistics he generates at <https://stats.dnssec-tools.org/#/> we know that in most cases, when DANE-enabled platforms fail DANE-verification, it is because the published TLSA resource record(s) in DNS do not match one of the x509 certificate's fingerprint. We want everybody to benefit from the security DANE adds to TLS and not have people look at it as a production risk! This is why we built the SMTP DANE Verify service. It will test and detect common DANE policy problems. Using SMTP DANE Verify everybody will be able to monitor their own (and other) domains and raise an alarm in case the tested domain fails DANE verification. ## How would you use SMTP DANE Verify? If you think SMTP DANE Verify is for you check out the project at <https://github.com/sys4/smtp-dane-verify>. The project's README should give you all the information you need to setup, run and integrate SMTP DANE Verify on your platform. On a sidenote: In case you are still in doubt if anyone should be using DANE at all: the EU has launched a Multi-Stakeholder Working Group for Internet Standards in the EU and DANE is a major item on the groups roadmap. Follow this link to read more: <https://digital-strategy.ec.europa.eu/en/news/european-commission-seeks-par…> And that's it! We hope you will find it as useful as we do. Season greetings to all of you. Peace on earth to all of us. o:) p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

1 0

New Let's Encrypt intermediate issuer CAs activated
by Viktor Dukhovni 02 Dec '25

02 Dec '25

It appears that starting a couple of days ago, newly issued/renewed Let's Encrypt (LE) certificates will be signed by R12, R13, E7 and E8, rather than the previously active R10, R11, E5 and E6. See the announcement at: https://community.letsencrypt.org/t/switching-issuance-to-new-intermediates… and the associated advice on the DANE survey site: https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html Of course everyone who includes LE issuer CA public key or cert hashes in their TLSA records should already be covered by including all of R10-R14 and/or E5-E9, but sadly many are not, because the DANE survey shows that the MX host counts for the various LE CAs are skewed in favour of the previously active issuers: # | CA -----+----- 63 | X3 -- Long obsolete should not be used 12 | X4 -- Long obsolete should not be used 370 | R3 -- Long obsolete should not be used 119 | R4 -- Long obsolete should not be used 116 | E1 -- Long obsolete should not be used 91 | E2 -- Long obsolete should not be used 773 | E5 803 | E6 392 | E7 391 | E8 382 | E9 813 | R10 806 | R11 466 | R12 469 | R13 462 | R14 608 | ISRG X1 root 246 | ISRG X2 root If you still want to rely on TLSA records tied to the LE issuers, and haven't published the appropriate full set of hashes, better late than never. You'll need to do so now. And of course you'll need to keep up with the news from LE and make additional timely changes in the future as the CAs used by LE evolve. -- Viktor. 🇺🇦 Слава Україні!

1 2

Please ensure your servers can handle "post-quantum" STARTTLS
by Viktor Dukhovni 26 Oct '25

26 Oct '25

Recent releases of various TLS libraries are enabling support for "post-quantum" key agreement. For example, in OpenSSL 3.5 the default client behaviour is to send TLS 1.3 "keyshares" for both the hybrid "post-quantum" X25519MLKEM768 and for the "classical" X25519. The size of the resulting TLS Client Hello message is close to 1500 bytes and it often splits across multiple TCP segments. This may run into friction with "middlebox" TLS inspection, or with server TLS stack implementations, resulting in failure (often timeouts) to complete the TLS handshake, which hangs or aborts are the TLS Client Hello. It is expected that use of these algorithms by TLS clients will continue to grow and it is best to take action now and not wait for problems to become urgent. If you have access to a computer with OpenSSL 3.5 (or later) you can check your server with: $ host=your.server-fqdn.example $ (sleep 2; printf 'QUIT\r\n') | openssl s_client -starttls smtp -connect $host:25 \ -groups "*X25519MLKEM768:*X25519:P-256:ffdhe3072" -state -brief If this hangs after printing "SSL_connect:SSLv3/TLS write client hello", you likely have a problem, to confirm, you can try again with: $ host=your.server-fqdn.example $ (sleep 2; printf 'QUIT\r\n') | openssl s_client -starttls smtp -connect $host:25 \ -groups "X25519MLKEM768:*X25519:P-256:ffdhe3072" -state -brief and if that succeeds promptly, it is appropriate to take action to find out what's causing the problem, and take steps to remediate it. -- Viktor. 🇺🇦 Слава Україні!

1 0

Pruning outdated TLSA DANE-EE(3) records
by Viktor Dukhovni 23 Jun '25

23 Jun '25

Some MTA operators neglect to prune outdated TLSA records with "usage" DANE-EE(3). As keys or certificates are replaced, they add new matching TLSA records, never dropping the records matching the outdated keys. This largely defeats the purpose of key or certificate rollover, since it blesses (at least in the context of DANE) ongoing misuse of any past compromise of the old key. And it results in ever growing TLSA records DNS payload sizes, resulting initially in needlessly large UDP payloads, and ultimately failover to TCP for every lookup. It is best to avoid this pattern and prune outdated TLSA records once the corresponding key (3 1 X) or certificate (3 0 X) is no longer in use. Example (current DANE-EE(3) count record holder): _25._tcp.mail.evocat.net TLSA 3 1 1 83037f6a136945f50dbc4e4cb65d0c154b726992eafb55ba5b3b4e4bcbde9715 ; 2022-05-27 - present _25._tcp.mail.evocat.net TLSA 3 1 1 379f309bff870568b06756c3ccb321692fdde8e970950ca0cbae3b4595e5b538 ; 2022-07-27 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a31fdc67764edc9e7bc734b907bd8b514f4616d2e8e2dfbcb01c8dc557acea34 ; 2022-09-25 - present _25._tcp.mail.evocat.net TLSA 3 1 1 21e1d9438b6528948794244cf1caf5802c6edb5a3415d33d7299c7daadee3834 ; 2022-11-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 c7be1ef02c2556cf4f421cb724b0327676d2d144790042a3aa603dfc96fb4a5a ; 2023-01-23 - present _25._tcp.mail.evocat.net TLSA 3 1 1 8115a64ccf2aa3b7e06c2e0cab0b972ca98eb83c707b68fc725c02195ce8d47f ; 2023-03-25 - present _25._tcp.mail.evocat.net TLSA 3 1 1 37c12ea11d4cd88c756768308a13587ebdd4fe626f7dc2512e37c85d1fe20d14 ; 2023-05-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 196d17a19f5dc1c0ad4a58eb8afff5e07b92ba72cd6d776b941e4233856c0636 ; 2023-07-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 3b3ee102ccb95a75ca73b337b4ba88d33b3cff3b1a2309227d71ccd808144482 ; 2023-09-22 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e896a20362f25d49a869f12ff99878b86e37dc86af38c04c29ab8992a6502f30 ; 2023-11-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 7475c707cdf5137eea74ea02f23b81ede7a1b4d2edb65af08c8cc1749a3f5c99 ; 2024-01-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e5949d3fb74344210439161d7bf2fb53e0bc68fe74a1e21a870c8881fbcd5901 ; 2024-03-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 31ea43c1733770793b157aa8963a2fc3dfc969ad3c6849c31d33e14ff643615e ; 2024-05-20 - present _25._tcp.mail.evocat.net TLSA 3 1 1 87e19f49bf9fae3273509940f27931dcf2edd3fc132eb1f2ddbe56e2bc2e0410 ; 2024-07-19 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a0c849a30b9cf92c206a28723324ed40318a7e2a82e56104959588a795db3669 ; 2024-09-19 - present _25._tcp.mail.evocat.net TLSA 3 1 1 468e0e2e119ea97bc8ab3c34792fa479dd8ea2d47e62a868020e06dc3d25c304 ; 2024-11-17 - present _25._tcp.mail.evocat.net TLSA 3 1 1 d6fffb71e83fcec0dde93edbbc1c50b0fdff21dffc78390c309c1cf3dd350370 ; 2025-01-16 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a2cb82878da95d9bae063340e6312ab7fe85100671899bf13793dc8893e42ac9 ; 2025-03-17 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e4ccf3f074a06cd30722fc42df127ef8e682136b40116e6bb77adf9679140f2f ; 2025-05-16 - present The authoritative DNS server returns a truncated (TC=1) response, leading to TCP fallback and high, from my vantage point, latency: $ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t tlsa _25._tcp.mail.evocat.net ;; Query time: 1014 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (TCP) ;; WHEN: Mon Jun 23 04:03:04 UTC 2025 ;; MSG SIZE rcvd: 2886 By way of comparison, the "A" RRset response fits in UDP and the latency I see is 5x lower: $ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t a mail.evocat.net ;; Query time: 201 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (UDP) ;; WHEN: Mon Jun 23 04:04:55 UTC 2025 ;; MSG SIZE rcvd: 1106 -- Viktor.

2 3

TLSA record hygiene for Let's Encrypt issuer CAs
by Viktor Dukhovni 15 Jun '25

15 Jun '25

[ Please read carefully, this post covers multiple Let's Encrypt-related topics ] Some SMTP server operators have chosen to publish DANE TLSA records for their MX hosts that match one or more of the Let's Encrypt issuer CAs: https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html#cas The "2 1 1" RRset to match one of R10–R14 should list them all, because certificate renewal randomly chooses of the active CAs (currently R10 and R11, but could as needed be one of the R12–R14 backups): _25._tcp.mx.some.example. 2 1 1 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba ; R10 _25._tcp.mx.some.example. 2 1 1 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 ; R11 _25._tcp.mx.some.example. 2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 ; R12 _25._tcp.mx.some.example. 2 1 1 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d ; R13 _25._tcp.mx.some.example. 2 1 1 f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 ; R14 The "2 1 1" RRset to match one of E5–E9 should list them all, because certificate renewal randomly chooses of the active CAs (currently E5 and E6, but could as needed be one of the E7–E9 backups): _25._tcp.mx.some.example. 2 1 1 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ; E5 _25._tcp.mx.some.example. 2 1 1 d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7 ; E6 _25._tcp.mx.some.example. 2 1 1 cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 ; E7 _25._tcp.mx.some.example. 2 1 1 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5 ; E8 _25._tcp.mx.some.example. 2 1 1 f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2 ; E9 Users whose MX hosts have both ECDSA and RSA certificates from Let's Encrypt, or who are switching between RSA and ECDSA keys (unclear to me whether or under what conditions this can happen automatically) may need to list all 10 intermediate CA RRs. Some operators have chosen to publish TLSA records matching the ISRG Root CAs that are the issuers of the above intermediate certs. The "2 1 1" records for these are: 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 ; ISRG X1 (RSA 4096-bit) 2 1 1 762195c225586ee6c0237456e2107dc54f1efc21f61a792ebd515913cce68332 ; ISRG X2 (ECDSA P384) The R10–R14 intermediate CA certificates are issued by "ISRG X1", while the E5–E9 intermediate CA certificates are issued by "ISRG X2". Though the root issuer is presently stable for a given server key type (RSA or ECDSA), I still recommend listing them both when listing either. More critically, when listing the root CAs, the operator MUST make sure to include the root CA certificate in the server's configured chain file. Listing just the EE + intermediate cert (or sometimes just the EE cert) is not sufficient. See: https://datatracker.ietf.org/doc/html/rfc7671#section-5.2.2 https://datatracker.ietf.org/doc/html/rfc7671#section-5.2.3 And of course when using "DANE-TA(2) X X" TLSA records, the server's EE certificate MUST be part of a chain with at least the intermediate CA certs. It is also essential to keep track of periodic changes in the set of CAs used by the Let's Encrypt. As currently listed at: https://letsencrypt.org/certificates/ and periodically announced on their blog, e.g.: https://letsencrypt.org/2024/04/12/changes-to-issuance-chains/ In relation to keep track, I want to mention that a small, but non-trivial fraction of DANE MTA operators have failed to remove already long-retired CAs from their TLSA records (or, in a few cases, even switch from these to the active CAs!). These records SHOULD be removed. See https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html#mxhosts These include: - 1 MX hosts publishing X1 (DST root): IN TLSA 2 0 1 7fdce3bf4103c2684b3adbb5792884bd45c75094c217788863950346f79c90a3 subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1 issuer=O=Digital Signature Trust Co., CN=DST Root CA X3 notBefore=Oct 19 22:33:36 2015 GMT notAfter=Oct 19 22:33:36 2020 GMT - 14 MX hosts publishing X3 (DST root): IN TLSA 2 0 1 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 issuer=O=Digital Signature Trust Co., CN=DST Root CA X3 notBefore=Mar 17 16:40:46 2016 GMT notAfter=Mar 17 16:40:46 2021 GMT - 57 MX hosts publishing X3: IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 IN TLSA 2 1 2 774fad8c9a6afc2bdb44faba8390d213ae592fb0d56c5dfab152284e334d7cd6abd05799236e7aa6266edf81907c60404c57ee54c10a3a82fcc2a9146629b140 subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Oct 6 15:43:55 2016 GMT notAfter=Oct 6 15:43:55 2021 GMT - 14 MX hosts publishing X4: IN TLSA 2 1 1 b111dd8a1c2091a89bd4fd60c57f0716cce50feeff8137cdbee0326e02cf362b subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X4 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Oct 6 15:44:34 2016 GMT notAfter=Oct 6 15:44:34 2021 GMT - 398 MX hosts publishing R3: IN TLSA 2 0 1 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd IN TLSA 2 0 2 96c5793b2b57d8df5891c94015720960e0da4c2cf8ce1fc5707a0b46e5db8ce3761fb5fdb430f619d1579f13e80fbdd973ef6a024129ed039aa193273158fcad IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d IN TLSA 2 1 2 0f644c9a1dcb8c04be6b385a60dbe4fdf7e2b81e335c9ad8c7cd0abe2ff9e7e5bbfbb68b38dd0216f17808f48bdf6af8c6347659c1f41a9858032c31f436d12c subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X4 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Oct 6 15:44:34 2016 GMT notAfter=Oct 6 15:44:34 2021 GMT - 134 MX hosts publishing R4: IN TLSA 2 0 1 1a07529a8b3f01d231dfad2abdf71899200bb65cd7e03c59fa82272533355b74 IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 IN TLSA 2 1 2 59a91d97d81980951d0ef3c6d849b31606af9ab2b0f7dcfac93a53ae3263eb8902c3b7c564f33ff496f2d07c750b1b6924968c243882af9e3532797eef596f27 subject=C=US, O=Let's Encrypt, CN=R4 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Sep 4 00:00:00 2020 GMT notAfter=Sep 15 16:00:00 2025 GMT - 125 MX hosts publishing E1 IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 IN TLSA 2 1 2 3561540fbf182bce7749acc131b421e691f083569c053e78f20274714c5e801226ff6edb60641ddf70e71bd3a90dfe25ddd6464be78106b77dece4f6a3bff13d subject=C=US, O=Let's Encrypt, CN=E1 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X2 notBefore=Sep 4 00:00:00 2020 GMT notAfter=Sep 15 16:00:00 2025 GMT - 100 MX hosts publishing E2 IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 IN TLSA 2 1 2 23a30bd3b617652e97224e1faf673c4e09f1c197e4994274e676f2490893e9560d99f00a8859e399b2c65219ce2eb9b76784a0ec775ab4973a14fc1437ac7d9f subject=C=US, O=Let's Encrypt, CN=E2 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X2 notBefore=Sep 4 00:00:00 2020 GMT notAfter=Sep 15 16:00:00 2025 GMT - 2 MX hosts publishing the long expired cross-signed by DST ISRG Root X1: IN TLSA 2 0 1 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f subject=C=US, O=Internet Security Research Group, CN=ISRG Root X1 issuer=O=Digital Signature Trust Co., CN=DST Root CA X3 notBefore=Jan 20 19:14:03 2021 GMT notAfter=Sep 30 18:14:03 2024 GMT -- Viktor.

1 0

DANE vs. TLS shedding of legacy/obsolete features
by Viktor Dukhovni 23 Oct '24

23 Oct '24

Time marches on, and various TLS stacks are gradually disabling obsolete and legacy TLS features. This affects DANE SMTP users, because when you publish TLSA records you are effectively commiting to sufficiently interoperable TLS support with no fallback to cleartext SMTP transmission. If your server's TLS stack is substantially behind the times, you risk losing mail, as gradually more sending systems are unable to complete TLS connections to your server. I was reminded of this today, after upgrading the software stack on the DANE survey server. The latest Haskell TLS library has: - Removed TLS 1.0 and TLS 1.1 support - By default now requires that TLS 1.2 stacks support the Extended Master Secret (EMS) extension. The first of these only affects a few MX hosts, for under 10 domains, and as of today, the server will assess these hosts to not support TLS. For the second, ~300k domains were affected, so I've made a code change in the survey to override the new default, and EMS is for now optional. However, this does not mean that it is a good idea to stay with outdated TLS server libraries that lack the last decade of TLS security improvements. At some point you'll run into increasing interoperability issues. Therefore, please make sure that your server TLS stacks are of a reasonably recent vintage, support TLS 1.3, and TLS 1.2 with EMS, and various other up-to-date protocol features. Below my signature is a list of 681 MX hosts that support TLS 1.2 only without EMS. If you're operating one of these, you may want to consider a software update, or reach out to your vendor re their future plans if on the latest available software. -- Viktor. mail.ismail.app mail.cambium.at mail.core.at mx2.core.at mail1.dialog-on.at mailex.graz4u.at mxirl.kurios.at smail.bancfirst.bank smail2.bancfirst.bank mail.dierenplanet.be mail.kevinscheerlinck.be mail7.uzgent.be mail8.uzgent.be ip1.nra.bg box.credazulbh.com.br digidocsolucoes.com.br digitalnext.com.br divulgabrasilpublicidade.com.br erpacademy.com.br webmail.grsolucoestelecom.com.br localizarfacil.com.br paulohendrix.com.br mail.purplehost.com.br rminet.com.br somcast.com.br agent.aneel.gov.br coulomb.aneel.gov.br mailsrv.aneel.gov.br master.aneel.gov.br silicio.defesa.gov.br aadh.org.br carteiradeestudanteonline.org.br mx.nohats.ca mm.eggy.cc mail.weel.cc mx.aha-informatik.ch mx2.aha-informatik.ch sr2.alfahost.ch linux3.buerki-hosting.ch linux4.buerki-hosting.ch sr621.firestorm.ch mail.houbi.ch mail2.houbi.ch mail.jardon.ch mail.kupferschmid.ch mx1.logging.ch mx2.logging.ch mx3.logging.ch mail.lumatron.ch mcagx.mathconsult.ch www.versicherungen-verwalten.ch wq-control03.web-quality.ch mailing.osst.cl dmzserv.osste.cl mail.buchtic.cloud box.castellino.cloud mail.heinzelmann.co mail.2d-computers.com mta01.zh01.4synergy.com box.aaronware.com mail.ajsuarez.com mail.arvidp.com mail.atsnappic.com server1.bootletech.com mail.brunston.com mail.bysnappic.com smtp1.cacdsp.com smtp2.cacdsp.com smtp2b.cacdsp.com box.certicommco.com mail.cfd-berlin.com mail.chamberlain1875.com mx10.coosto.com mx20.coosto.com db1.countermail.com mail.darev.com mx01.dcvc.com mx02.dcvc.com box.disarrayinc.com mail.djadaro.com box.donaldbordner.com mail.dsx-networks.com mail.getrocksolidoutbound.com box.globaldataconnections.com mail01.globexec.com mail02.globexec.com box.googdaddy.com mail.gozubuyukoglu.com box.graabek.com mail.growthsnappic.com filter.hattink.com relay-6.headbird.com relay-7.headbird.com smtp.heimdal31.com mail.hepsibulutta.com mail.hisnappic.com box.infoprospector.com box.intelligencespubliques.com mail.istar-link.com mail.joinsnappic.com mail.justsnappic.com mail.khecorp.com maple.killian.com mail.kinderfestival.com mx.lavabit.com mx.leonhard-ip.com mx.lmax-kr.com mail.macskorlari.com mail.magmadaemon.com box.mailcbclub.com mx.mandjes.com mail.me2digital.com mx.mine-inc.com box.misitio-mailserver.com box.mossprogramming.com box.mygp-server.com box.mymaildns.com mail.mysnappic.com mail.noveldatasolutions.com box.oakleg.com mx.ontvdesign.com mail.ordoz.com cloud.orshost.com box.p1xl.com box.paprbit.com mail.phardata.com mbox.proabcmail.com box.redmaplere.com rot13.romab.com mail.secura.com smtp.semperen.com mail.siem-hosting.com mx.simply.com mail.slackonly.com postfach.slogh.com box.sns-corp.com mail.startoutreach-wizards.com sweeper.stater.com mx.statpro.com mx.sunhaochen.com mail.sysdra.com box.tessamcdonald.com mail.theoutreach-wizards.com box.thepcw.com mail.thesnappic.com mx3.threenorth.com mail.topoutreach-wizards.com mail.ubogdan.com mail.undergopher.com box.viewnimail.com mail.vkilin.com smtp.vkilin.com volcanoclient.com calife.wilkushka.com mail.withsnappic.com mx1.wsheffield.com mx2.wsheffield.com box.wuzzlr.com cloud4.xeeor.com mx01.your-site.com mail.yoursnappic.com brightrain.aerifal.cx mx.aerohosting.cz mail.bsys.cz mail.ceskearchivy.cz mx2.cesnet.cz mail.digitalbox.cz mail.dobruskanet.cz mail.dtvm.cz mail.dubina.cz gate.ecompany.cz mail2.eurosat.cz mx3.fastline.cz smtp1.fnusa.cz mail.cbu.gov.cz mail.kraj-jihocesky.gov.cz smtp-bis.gov.cz smtp-cms.gov.cz smtp-czp.gov.cz smtp-kpr.gov.cz smtp-mdcr.gov.cz smtp-mmr.gov.cz smtp-mvcr.gov.cz smtp-mze.gov.cz smtp-pcr.gov.cz smtp-soap.gov.cz smtp-sshr.gov.cz smtp-szif.gov.cz mail.grada.cz mail.intimkontakt.cz mailbackup.intimkontakt.cz arachne.itcomputers.cz mail.janpetrik.cz mail1n.kb.cz mail2v.kb.cz nse.kraj-jihocesky.cz mail.kuthani.cz spindle.m104.cz mail1.fs.mfcr.cz mail2.fs.mfcr.cz mail-gw.mfcr.cz mail-gw2.mfcr.cz smtp.mza.cz mzvczemta05.mzv.cz mzvczemta06.mzv.cz mail.pivovardobruska.cz smtp01.ppfbanka.cz emas1.pre.cz emas3.pre.cz smg2.psp.cz anakin.rtscs.cz rtsdrake.rtscs.cz mail.stebau.cz mail.stranskyapetrzik.cz posta.studio-kiara.cz mail.terrasan.cz rhine.tocc.cz asms1.uzsvm.cz asms2.uzsvm.cz mail.vibrom.cz mail.xsc.cz mail.xtgsystems.cz mx1.zpskoda.cz mx2.zpskoda.cz mail.1of16.de mail.augusta.de mail.azf-gruppe.de relay.ccitm.de mx1.denic.de mx2.denic.de mx.devtig.de mail.gcd.de mail.heinzelmann-it.de avalon.iks-jena.de mail.infonline.de mail2.infonline.de kolab.inhaltsfrei.de mx1.linuxheilbronn.de mx2.linuxheilbronn.de mx3.linuxheilbronn.de mx4.linuxheilbronn.de mx1.mxspamfilter.de mx2.mxspamfilter.de mx3.mxspamfilter.de vh.petricoral.de mail.ropa-maschinenbau.de mail.schoenwald-net.de mx1.siliconhome.de mx3.stute.de mail.sys4.de kolab.sysadm24.de relay.tkue-bayern.de mx1.top24-webhosting.de mx2.top24-webhosting.de mx3.top24-webhosting.de mx4.top24-webhosting.de smtp3.rz.tu-harburg.de smtp4.rz.tu-harburg.de smtp5.rz.tu-harburg.de mailgate1.uni-kl.de mailgate2.uni-kl.de mail.unitedcall.de mx1.unitedcall.de mx2.unitedcall.de mx3.unitedcall.de mx4.unitedcall.de mail.vivell.de smtp1.cacdsp.dev mail.bigbear.dk privatemail.cmcs.dk mail.dlx.dk mailinan.emptybox.dk frontmta.hostedsepo.dk mx1.sit-test.dk mx2.sit-test.dk mail.svanberg.dk mail.umit.dk mail1.just.ee mail2.rik.ee box.3kings.email box.bookingdesigner.email box.enron.email smtp.tink.email webreus.email mx1.ergo-segurosdeviaje.es mail.2d-computers.eu bhmail.bernhardtmtm.eu mail.bindr.eu mailx2.dg-i.eu mail.directhost.eu mail.eurosatcs.eu mail.lexmedia.eu mail.libraoptima.eu mail.mikr.eu khitomer.mortis.eu mail.mtct.eu trbsmtp1.tes.eu mail.tmatejka.eu letter.wolfhugel.eu pobox.wolfhugel.eu mail.wsch.eu lounea-somerofw-01.somero.fi lounea-somerofw-02.somero.fi somerofw-01.somero.fi somerofw-02.somero.fi mx.media-horizon.fr mx03.o2-graphics.fr mx0.jmt.gr tidamg1.tid.gov.hk tidamg2.tid.gov.hk tidamg3.tid.gov.hk web50.i24.host web51.i24.host web52.i24.host web55.i24.host mail.jip.host h4-da.mijn.host h5-da.mijn.host mx.domain.mil.id mail.cliffclav.in box.nstar.in mail.bezorgo.info mail.royalaffiliate.info mail.royalmedia.info box.samuel-drapeau.info box.dspro.io minerva.solas.is saga.solas.is sia.solas.is uce.solas.is mail.matteomarescotti.it mail.laukas.lt mail.starspace.lv box.oolong.me mailgate3.darpa.mil mailgate4.darpa.mil mailgate5.darpa.mil mailgate6.darpa.mil mx01.nhg.name mx02.nhg.name antispam1.7lan.net awnews.aztgrp.net mail2.aztgrp.net relay1.aztgrp.net mailx1.dg-i.net mx1.dotxs.net dubrovskiy.net emailpreneurs.net mail.exesus.net d01.fidela.net d02.fidela.net mail.fobul.net viper.genos.net hostingbarato.net ops.hzdmail.net box.inonso.net mail1.is-bg.net mailf.is-bg.net mail.kerrycze.net smtp.lbcfree.net lechiennoir.net punt1.lrhosting.net punt2.lrhosting.net mx.mailanyone.net ca.mx1.mailanyone.net dk.mx1.mailanyone.net se.mx1.mailanyone.net uk.mx1.mailanyone.net mail3.marcant.net ca.mx2.mx25.net eu.mx2.mx25.net se.mx2.mx25.net backupmail.neessen.net mail.neessen.net mail.no-sense.net mailhost.onetrail.net box.periodoctors.net box.prospertech.net box.prymail.net server03.reb-server.net mx1.rezel.net noname.rula.net mx00.schnied.net mx20.schnied.net mx21.schnied.net dublin.sinnekram.net hawser.sinnekram.net box.soleconnect.net mail.system23.net mx1.t-2.net mx2.t-2.net mx1.tachtler.net vps01.tim427.net box.tristanmcdonald.net mail.vanhard.net virteck.net mx1.vos-systems.net mx2.vos-systems.net mx3.vos-systems.net mx4.vos-systems.net swh5.zylon.net swh6.zylon.net swh7.zylon.net swh8.zylon.net box.myemail.ninja mail.2d-computers.nl mail.accent.nl mail.acm.nl mail.acore.nl mail.beetjevreemd.nl mail.bertrutjenstimmerwerken.nl mail.boerskashandelsonderneming.nl mail.bootsma-advies.nl mail.bprieshof.nl mail.buildingconversation.nl fallback.businessconnect.nl mx1.businessconnect.nl mail.cardialysis.nl mx.cardialysis.nl mail.climax-atletiek.nl clubredders.nl mail.controlink.nl mail.costor.nl mail.covra.nl mail.cyberweerbaarheidnetwerk.nl mail.dekerkvantoen.nl smtp.denhaag.nl mail.denotificatiedienst.nl mail.dentmail.nl mail.derukbunker.nl mail.ditmar-guashatherapie.nl dommelstein.nl mail.dozy-portretten.nl mail.elit.nl mail.enigmaresearch.nl mail.fcfoto.nl mail.fernandokuipers.nl mail.ffsnelchecken.nl mail.galerie-delft.nl mailserver1.go2ubl.nl mx1.groningen.nl mx2.groningen.nl mail.grry.nl mail.hannahsmit.nl mail.honkheerenveen.nl mail.hostedbyjohan.nl hosting2go-server134.nl mail.hostingindustries.nl mail.huureenviool.nl imk-p-mta1.i-mike.nl spamfilter1-secure.ict-net.nl spamfilter2-secure.ict-net.nl mail.in-deco.nl isatiscybersecurity.nl itthuis.nl mail.jobgenius.nl mail.joeyvanmelis.nl mail.josnelissenbv.nl mx.khonraad-ip4-networks.nl mail.klok-eco.nl mail.klokhuis.nl mail.klusbedrijftimmer.nl mail.koldeweij.nl mail.kookhandel.nl mail.kpjmontfoort.nl mail.kuss.nl mail.kynosoft.nl lifeguardcollege.nl mail.lifestylefunnels.nl mail.lightcodealchemy.nl mail.lokalepartijborsele.nl mail.ltcdewestkaap.nl mail.luxespeelkaarten.nl mail.maakjebrood.nl filter1.maq2.nl smt.p.meneeraart.nl mail.meneerjop.nl mail.meteowallie.nl antispam.mica.nl antispam.mica-it.nl spamstraat1.mica-it.nl box.mijn-email-service.nl mail.millerdigital.nl mx.mindef.nl mirfotografeert.nl mail.motorep.nl www.musquetier.nl mx1.netwerkplan.nl mx2.netwerkplan.nl dcmx2.nevb.nl mail.nicknick.nl mail.noormannen.nl mail.opfrisbeurt.nl mx.otadef.nl smtp.otys.nl smtp1.mijn.overheid.nl smtp2.mijn.overheid.nl mail1.parlement.nl mail2.parlement.nl mailrelay.pcextreme.nl mail.photographicdreams.nl mail.pixelein.nl mailgw.pol-it.nl mail.postenwolk.nl mail.praktijkbrandnewme.nl mail.prelution.nl mail.privva.nl mail.progressiefbeek.nl oxygen.proos.nl mail.pure-connect.nl mail.quantora.nl mx1.rdw.nl mail.reapers-delight.nl mail.reclamefotografie.nl mail.redirecter.nl mail.rijkscloud.nl mail.rijles040.nl ruudadviseert.nl mx1.saxion.nl mx2.saxion.nl mail.schildersbedrijfjohn.nl mail.scpocahontas.nl mail.scryption.nl mail.shebiohacks.nl mx3.solutive.nl ispc01.sonad.nl mail-prod.standaardplatform.nl mail.stopumts.nl mx.supportatoffice.nl mail.teatime.nl rtm0.the-net.nl webmail.theijn.nl mail.tijinkeibergen.nl mail.tollercoaster.nl relay.transip.nl relay0.transip.nl relay1.transip.nl mail.ttyl.nl mail.tyrna.nl uwvsmtp05.uwv.nl uwvsmtp06.uwv.nl mail.vakantiewoningeijsden.nl mx1.vancis.nl mx2.vancis.nl mx3.vancis.nl vanderbeekonline.nl mail.veiligthuisgroningen.nl mailhopper.velthovengdw.nl mail.vitaminenaturel.nl mail.vlamingschaap.nl fallback.waversveld.nl ms.waversveld.nl mx-in-1.webreus.nl mx-in-2.webreus.nl mx-in-3.webreus.nl mx-in-4.webreus.nl mx-in-5.webreus.nl webspinnerij.nl mail.westkappelserv.nl mail.x-6.nl smtpf03.xcons.nl mail.xonlineserver.nl mail.web101.your-webhost.nl mail.web102.your-webhost.nl mail.web103.your-webhost.nl mail.web104.your-webhost.nl mail.web105.your-webhost.nl mail.web106.your-webhost.nl mail.web107.your-webhost.nl mail.web108.your-webhost.nl mail.web109.your-webhost.nl mail.web123.your-webhost.nl mail.web201.your-webhost.nl mail.web202.your-webhost.nl mail.web205.your-webhost.nl mail.web206.your-webhost.nl mail.web207.your-webhost.nl mail.web208.your-webhost.nl mail.web209.your-webhost.nl mail.web210.your-webhost.nl mail.web301.your-webhost.nl mail.web302.your-webhost.nl mail.web304.your-webhost.nl mail.web305.your-webhost.nl mail.web306.your-webhost.nl mail.web307.your-webhost.nl mail.web401.your-webhost.nl mail.web402.your-webhost.nl relay.zorgmail.nl fallbackmail.zxcs.nl mailpod01.zxcs.nl spamrelay.zxcs.nl spamrelay03.zxcs.nl smtp2.cryp.no mailgate.h4y.no alfons.uib.no rolf.uib.no tim.bkb.nrw box.siebert.nrw ns.airy.org merlino.alchemistowl.org box.bkmedia.org corz.org mail.ifcat.org mx.lanlos.org magmadaemon.org mail.mdevries.org mail.myicare.org mx1.nausch.org mail.photistic.org mail.razorsedge.org mx1.slackbuilds.org mx2.slackbuilds.org email.titmus.org mail.vanmastrigt.org volcanoclient.org mail.waher.org mail.ferreira.ovh mail.zcservices.ovh mx.biuroskeda.pl war01mail1.brebank.com.pl war01mail2.brebank.com.pl alfa.drama.pl smtp.drama.pl mxin-ta11.psgaz.pl mxin-ta12.psgaz.pl mxin-za11.psgaz.pl mxin-za12.psgaz.pl exchange.tele-car.pl interchange.tele-car.pl dubrovskiy.pro mxout.vangest.pt mail.lexmedia.ro mail.pasion.ro mx5.transsped.ro mx6.transsped.ro mail.geoartefact.ru mail.itnet33.ru relay0.melenky.ru mx01.mosinzhproekt.ru mx02.mosinzhproekt.ru amber.mobily.com.sa garnet.mobily.com.sa opal.mobily.com.sa pearl.mobily.com.sa mail.daemonic.se mx-50.mil.se mx-60.mil.se mx-70.mil.se mx-80.mil.se mx02.specialfastigheter.se mx03.specialfastigheter.se box.zayenz.se mx.go6lab.si protector.rajmax.si smtp-bad-in-2.t-2.si smtp-good-in-2.t-2.si posta.lubosillit.sk mail1.nafta.sk mail2.nafta.sk mail.rup.sk mx1.energymeteo.systems mx2.energymeteo.systems jrg.systems mail.ict-pros.co.tz box.clientnews1.co.uk box.clientnews2.co.uk box.clientnews3.co.uk box.clientnews4.co.uk filter2.maq2.us box.mqgroup.us mx3.nodns4.us mx4.nodns4.us mail.zugz.wang box.two.wtf mail.0mail.xyz box.alete.xyz mail.ebzao.xyz box.mojomailer.xyz box.qsmail.xyz box.todimail.xyz

1 0

Best to not outright refuse non-TLS incoming mail...
by Viktor Dukhovni 12 Oct '24

12 Oct '24

The DANE survey (https://stat.dnssec-tools.org) turns up a few domains a day that botch their cert rollovers or fail to offer STARTTLS despite publishing DANE TLSA records. I try to send notices to the relevant contacts, but sometimes they shoot themselves in the foot: - Private WHOIS - No contact data at the website - Published contacts don't work (no such user, ...). - Reject earnest notices of technical problems as spam Yesterday, for the first time, I ran into someone whose MTA stopped offering STARTTLS, despite the TLSA records still being in place, but attempts to deliver a notice are rejected: posttls-finger: < 220-mail.<censored>.dk ESMTP Postcow ... brief pause... posttls-finger: < 220 mail.<censored>.dk ESMTP Postcow posttls-finger: > EHLO <...> posttls-finger: < 250-mail.<censored>.dk posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 104857600 posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH PLAIN LOGIN CRAM-MD5 posttls-finger: < 250-AUTH=PLAIN LOGIN CRAM-MD5 posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250-DSN posttls-finger: < 250 CHUNKING posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye The notice bounced with: 550 5.7.1 Session encryption is required (in reply to RCPT TO command) As commendable as it may be to encourage use of TLS, it is not a good practice to outright refuse cleartext mail. -- Viktor.

4 3

DANE monitoring building block: "danesmtp" shell function
by Viktor Dukhovni 05 Sep '24

05 Sep '24

As you're may be aware, I actively promote adoption of DANE SMTP, many thanks to everyone who's moved forward with DANE SMTP deployment! That said, I also always stress that, when deploying DANE SMTP, *monitoring* must come first, and publishing of DANE TLSA records second. If your DANE TLSA deployment is unmonitored, it will some day fail, with you being the last to know that something is wrong when some email fails to arrive on time or at all. Unmonitored security is a ticking time-bomb. Please implement monitoring of your DANE TLSA records vs. the live certificate chain through regular probing of your MX hosts (I'd suggest hourly if not more often for more critical servers). Of course you also need to have good automation of the certificate rollover process so that normally TLSA records aren't out sync with the certificates even during a rollover. If you don't yet have monitoring in place, the below could be a useful building block for your monitoring scripts. The "danesmtp" shell (bash) function can take an optional explicit IP address to connect to, so you can test each of the IP addresses of a host in turn: danesmtp () { local OPTIND=1 opt local -a rrs sslopts local rr i=0 host addr while getopts a: opt; do case $opt in a) addr=$OPTARG case $addr in *:*) addr="[$addr]";; esac;; *) printf 'usage: danesmtp [-a addr] host [ssloption ...]\n' return 1;; esac done shift $((OPTIND - 1)) host=$1 shift if [[ -z "$addr" ]]; then addr="$host" fi sslopts=(-starttls smtp -connect "$addr:25" -verify 9 -verify_return_error -dane_ee_no_namechecks -dane_tlsa_domain "$host") rrs=( $(dig +short +nosplit -t tlsa "_25._tcp.$host" | grep -Ei '^[23] [01] [012] [0-9a-f]+$') ) while (( i < ${#rrs[@]} - 3 )); do rr=${rrs[@]:$i:4} i=$((i+4)) sslopts=("${sslopts[@]}" "-dane_tlsa_rrdata" "$rr") done ( sleep 1; printf "QUIT\r\n" ) | openssl s_client -brief "${sslopts[@]}" "$@" } -- Viktor.

4 7

Let's Encrypt retired and new issuer CAs
by Viktor Dukhovni 03 Sep '24

03 Sep '24

The major changes in the Let's Encrypt issuer CA lineup noted in my previous post: https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/ZTM3XQ… are now largely completed. Of the ~46000 domains with working DANE-TA(2) TLSA records matching a Let's Encrypt intermediate issuer, just 62 are still based on R3, and none on X3, X4, R4, E1 or E2. These last few R3 issued certificates will either be renewed or will expire by September 4th. Therefore, if you haven't done so already, please read the fine advice in: https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html and switch to R10..R14 or E5..E9 (or rarely both) as appropriate. If you prefer to instead pin the ISRG root CAs, you MUST ensure that your SMTP server's chain file also includes the ISRG X1 or ISRG X2 root (whichever happened to issue the intermediate CA cert), and then you can publish TLSA records matching these roots. https://dane.sys4.de/common_mistakes#4 https://github.com/Mailu/Mailu/issues/2138 https://datatracker.ietf.org/doc/html/rfc7671#section-5.2.3 Note that some MTA operators have made the mistake of listing just R10 or R11 (similary just E5 or E6), whichever was the first new issuer they saw, without understanding that the issuer will randomly rotate between these, and may in an emergency be one of their backups. DO NOT be tempted to skimp on the list of published TAs, if you're keen on using DANE-TA(2) with Let's Encrypt, publish the full set, and keep track of periodic Let's Encrypt service announcements. An of course, DO NOT neglect monitoring, perhaps based on: https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/thread/NKDBQAB… And of course, it may be simplest to stop playing Let's Encrypt TA whack-a-mole, and switch to "3 1 1" records: https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html Perhaps with the aid of: https://github.com/tlsaware/danebot or similar/equivalent. Best of luck, but, if can you pay attention to detail, you should not need it. -- Viktor. Слава Україні!

3 12

Microsoft inbound DANE live
by Viktor Dukhovni 22 Jun '24

22 Jun '24

Microsoft's inbound DANE service is showing signs of life: https://x.com/VDukhovni/status/1804324326633783696 The first two customers appear to be the Danish Defence Intelligence Service and the Czech Office for Personal Data Protection! https://stats.dnssec-tools.org/explore/?ddis.dk https://stats.dnssec-tools.org/explore/?fe-ddis.dk https://stats.dnssec-tools.org/explore/?fe-mail.dk https://stats.dnssec-tools.org/explore/?uoou.cz Looking forward to many more... -- Viktor.

1 0