- dane-users - list.sys4.de

Re: [pfx] The "danecheck" monitoring tool has been updated
by Viktor Dukhovni 10 Jun '26

10 Jun '26

On Wed, Jun 10, 2026 at 12:56:35AM +1000, Viktor Dukhovni wrote: > If interested, see > > https://github.com/vdukhovni/danecheck/blob/master/README.md > > for installation details. It was correctly pointed out to me that instructions that only cover piping the output of a "curl" command directly to a shell (even as a non-root user) look a bit dodgy. If that's not your cup of tea, more traditional installation methods are described at: https://www.haskell.org/ghcup/install/ https://www.haskell.org/ghcup/install/manual/#manual-installation though ultimately, one way or another, you're still obtaining an executable from a remote source. FWIW, also: - Fedora 43 has "ghc9.10-devel" and "ghc9.12-devel" meta packages that can obviate the need for "ghcup", and make it possible to build "ghcup" from source. - For MacOS "ghcup", "ghc(a)9.10" and "ghc(a)9.12" are available via "homebrew". I'll amend the README to cover the more traditional Haskell compiler toolchain installation methods. -- Viktor. 🇺🇦 Слава Україні!

1 0

The "danecheck" monitoring tool has been updated
by Viktor Dukhovni 09 Jun '26

09 Jun '26

After some perhaps benign neglect, the "danecheck" utility published at: <https://github.com/vdukhovni/danecheck> has been modernised. The source is in Haskell, and this update brings it up to date with recent progress in the Haskell toolchain as well improvements over the years added to its ancestor DANE survey codebase from which the one-shot "danecheck" is a spin-off. This version no longer depends on the external libicu library, so won't be broken when that's updated to a later version with a different SONAME. It now does a better job of presenting non-ASCII certificate issuer and common names. If interested, see https://github.com/vdukhovni/danecheck/blob/master/README.md for installation details. Sample output for "postfix.org" below my signature. I can match 2 out of the "3 1 1" records by specifying which of RSA-based or ECDSA-based signature algorithms to check (it is also possible to specify both in either order, though often the server chooses based on its preference order and client's order is ignored). The CA in the TLSA records isn't an issuer of either the ECDSA or the RSA certificate. Perhaps vestigial and should be removed? subject=C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2 issuer=C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2 notBefore=Aug 1 12:00:00 2013 GMT notAfter=Jan 15 12:00:00 2038 GMT -- Viktor. 🇺🇦 Слава Україні! ------------ ECDSA (client and/or server default) $ ~/.cabal/bin/danecheck postfix.org ; echo; echo $? postfix.org. IN MX 10 list.sys4.de. ; NoError AD=1 list.sys4.de. IN A 45.90.5.195 ; NoError AD=1 list.sys4.de. IN AAAA 2a03:4000:20:189::195 ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 2 1 1 8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 3 1 1 5a5cdb1f9438a36da11e33b31978c4fed0b8996edd2ea2ce206bf9c026c642ad ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 3 1 1 ac8c9eb13fcf4f8e9d1ea84b880007cb4ffbf9be30f335b57e5c5a509c5137e4 ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 3 1 1 e679f71454654354310785c811bfad1f8c4a2b6863410e4c13a40ab37cb744cf ; NoError AD=1 list.sys4.de[45.90.5.195]: pass: TLSA match: depth = 0, name = list.sys4.de TLS = TLS1.3 with TLS_AES_256_GCM_SHA384,X25519,PubKeyALG_EC name = list.sys4.de depth = 0 Issuer CommonName = E7 Issuer Organization = Let's Encrypt notBefore = 2026-05-18T02:23:49Z notAfter = 2026-08-16T02:23:48Z Subject CommonName = list.sys4.de pkey sha256 [matched] <- 3 1 1 e679f71454654354310785c811bfad1f8c4a2b6863410e4c13a40ab37cb744cf depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2024-03-13T00:00:00Z notAfter = 2027-03-12T23:59:59Z Subject CommonName = E7 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 list.sys4.de[2a03:4000:20:189::195]: pass: TLSA match: depth = 0, name = list.sys4.de TLS = TLS1.3 with TLS_AES_256_GCM_SHA384,X25519,PubKeyALG_EC name = list.sys4.de depth = 0 Issuer CommonName = E7 Issuer Organization = Let's Encrypt notBefore = 2026-05-18T02:23:49Z notAfter = 2026-08-16T02:23:48Z Subject CommonName = list.sys4.de pkey sha256 [matched] <- 3 1 1 e679f71454654354310785c811bfad1f8c4a2b6863410e4c13a40ab37cb744cf depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2024-03-13T00:00:00Z notAfter = 2027-03-12T23:59:59Z Subject CommonName = E7 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 0 ------------ RSA $ ~/.cabal/bin/danecheck --sigalgs rsa postfix.org ; echo; echo $? postfix.org. IN MX 10 list.sys4.de. ; NoError AD=1 list.sys4.de. IN A 45.90.5.195 ; NoError AD=1 list.sys4.de. IN AAAA 2a03:4000:20:189::195 ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 2 1 1 8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 3 1 1 5a5cdb1f9438a36da11e33b31978c4fed0b8996edd2ea2ce206bf9c026c642ad ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 3 1 1 ac8c9eb13fcf4f8e9d1ea84b880007cb4ffbf9be30f335b57e5c5a509c5137e4 ; NoError AD=1 _25._tcp.list.sys4.de. IN TLSA 3 1 1 e679f71454654354310785c811bfad1f8c4a2b6863410e4c13a40ab37cb744cf ; NoError AD=1 list.sys4.de[45.90.5.195]: pass: TLSA match: depth = 0, name = list.sys4.de TLS = TLS1.3 with TLS_AES_256_GCM_SHA384,X25519,PubKeyALG_RSA name = list.sys4.de depth = 0 Issuer CommonName = R12 Issuer Organization = Let's Encrypt notBefore = 2026-05-18T02:23:41Z notAfter = 2026-08-16T02:23:40Z Subject CommonName = list.sys4.de pkey sha256 [matched] <- 3 1 1 5a5cdb1f9438a36da11e33b31978c4fed0b8996edd2ea2ce206bf9c026c642ad depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2024-03-13T00:00:00Z notAfter = 2027-03-12T23:59:59Z Subject CommonName = R12 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 list.sys4.de[2a03:4000:20:189::195]: pass: TLSA match: depth = 0, name = list.sys4.de TLS = TLS1.3 with TLS_AES_256_GCM_SHA384,X25519,PubKeyALG_RSA name = list.sys4.de depth = 0 Issuer CommonName = R12 Issuer Organization = Let's Encrypt notBefore = 2026-05-18T02:23:41Z notAfter = 2026-08-16T02:23:40Z Subject CommonName = list.sys4.de pkey sha256 [matched] <- 3 1 1 5a5cdb1f9438a36da11e33b31978c4fed0b8996edd2ea2ce206bf9c026c642ad depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2024-03-13T00:00:00Z notAfter = 2027-03-12T23:59:59Z Subject CommonName = R12 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 0

1 0

Especially with DANE use default TLS settings
by Viktor Dukhovni 20 Apr '26

20 Apr '26

I've recently taken a closer look at some MX hosts that fail to interoperate with the DANE survey's choice of TLS parameters. The observed interoperability failures are easy to avoid, don't fall into the trap of: - On the one hand requiring DANE-capable clients to always use TLS when delivering to your MX host. - On the other hand choosing a narrow set of "secure" TLS parameters, that may well result in no shared "ciphers" with sensibly configured peers. - Also leaving your TLS stack unattened for a decade or more, with just outdated algorithms supported is not a good idea. If you're publishing DANE TLSA records, you need to make some effort to stay up to date. I've seen a few MX hosts with DANE TLSA records, but: - Only TLS 1.0, with neither TLS 1.2 nor 1.3 supported. - Only CBC ciphers, with no AEAD ciphers (AESGCM at least). - P521 (secp521r1) as the *only* supported key exchange group. ... This type of over-constrained TLS configuration risks interoperability failure and loss of ability to receive email from some senders. The DANE survey engine engine settings are fairly typical: - The underlying TLS software is a recent version of the Haskell's "tls" package, which has dropped support for TLS older than 1.2. This is not particularly atypical, even OpenSSL is no longer easily coaxed into doing a TLS 1.0 handshake. - The Haskell TLS library has also dropped support for CBC ciphers, which OpenSSL does support, and though I've now forward-ported support for CBC ciphers from an older release in my own build of that library, I expect that there are other senders whose TLS stacks no longer support (or will soon not support) CBC ciphers. - Choosing only the absolutely strongest options (e.g., P521 or bust) is a bad idea. It is not unreasable on the sending side to avoid unreasonably large RSA key sizes, unreasonably large FFDHE primes, and unreasonably strong EC curves) as these are quite wasteful of CPU resources to little security benefit. Make sure: * Your TLS group settings include at least one of: - X25519 or SecP256r1 (P256) - ffdhe2048 or ffdhe3072 * With RSA certificates, the key sizes is 2048 or 3072 bits * With ECDSA certificates use a P256 key. * Accept both AES128 and AES256 ciphers, and if posisble accept CBC ciphers. Better yet, as much as possible stick with default settings that are optimised for interoperability at sensible, rather tham maximal values in their various parameters. -- Viktor. 🇺🇦 Слава Україні!

4 7

Bug#1127461: ITP: python-smtp-dane-verify -- monitor and detect typical DANE related problems for DANE-enabled inbound SMTP services
by Joseph Nahmias 09 Feb '26

09 Feb '26

Package: wnpp Severity: wishlist Owner: Joseph Nahmias <joe(a)nahmias.net> X-Debbugs-Cc: debian-devel(a)lists.debian.org, info(a)uwekamper.de, dane-users(a)list.sys4.de, debian-python(a)lists.debian.org, joe(a)nahmias.net * Package name : python-smtp-dane-verify Version : 0.3.2 Upstream Contact: Uwe Kamper * URL : https://github.com/sys4/smtp-dane-verify? * License : AGPL3 Programming Lang: Python Description : monitor and detect DANE related problems for inbound SMTP services Integrated in a monitoring service SMTP DANE Verify will either walk a given domain and verify all MX hosts referred to are DANE compliant or it will verify a single host is DANE compliant. The service will do this add hoc when requested to do so using JSON via it’s REST API in a JSON formatted HTTP response and / or it will verify domains periodically when configured appropriately at startup and it will publish the verification results in an openmetrics compliant request / response call. I plan to maintain this as part of the Debian Python Team

1 0

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