On Thu, Oct 30, 2025 at 08:00:37PM +0200, Edmund Lodewijks via mailop wrote:
> On 2025/10/30 18:56, Viktor Dukhovni via mailop wrote:
> > There is a non-trivial minority of SMTP servers that have self-signed
> > certificates. Barring some reason to expect otherwise (MTA-STS policy?),
> > SMTP clients broadly tolerate unvalidatable server certificates,
> > including self-signed as one of many ways that can happen. That's just
> > basic unauthenticated opportunistic TLS.
>
> I do have an mta-sts policy, which would be causing the havoc with Gmail
> (I never thought of that!).
>
> Considering that some big players (e.g. Gmail and Fastmail) only use
> mta-sts (and don't want to go near DANE[0]), it would not make sense to
> not use mta-sts? In which case a CA cert would be required.
>
> I see. So, a CA signed certificate would be the way to go then.
Yes, for MTA-STS you need a certificate from a CA that the all the
MTA-STS-capable senders trust, in other words, you do your best lemming
immitation and choose one of the "mainstream" CAs.
> Not sure why Protonmail also drops mails to my server, but I have
> reached out to their support and hope to receive an explanation.
It looks like on the inbound side Protonmail have both DANE and MTA-STS:
$ dig +noall +ans +nottl -t txt _mta-sts.protonmail.ch. | sed -E 's/[ \t]+/
/g'
_mta-sts.protonmail.ch. IN TXT "v=STSv1; id=190906205100Z;"
$ curl -sLo - https://mta-sts.protonmail.ch/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.protonmail.ch
mx: mailsec.protonmail.ch
max_age: 604800
They likely also support MTA-STS outbound, just like GMail, and may,
RFC8461 notwithstanding, enforce MTA-STS rather than DANE when both are
in scope.
> > For example, the backup MX of the Armenian NIC, "isoc.amnic.net" has
> > a self-signed cert and matching TLSA records:
>
> I can't see that they have an mta-sts policy.
If you at numbers of covered domains, MTA-STS is *very* thinly deployed
in comparison with DANE, but the MTA-STS deployment is concentrated at
many of the largest providers, so the number of covered users is perhaps
greater on the MTA-STS side. Microsoft haven't yet rolled out DANE for
outlook.com, but "hotmail.cz" and "hotmail.nl" are already DNSSEC-signed
and have TLSA records for their "[...].mx.microsoft" MX hosts.
> > Likewise both MX hosts of a Czech health insurance provider:
> >
> > cpzp.cz. IN MX 10 posta.cpzp.cz.
> > cpzp.cz. IN MX 30 postc.cpzp.cz.
>
> Nor do they have a mta-sts policy that I could find.
Not surprising, for a random domain, MTA-STS ~2 orders of magnitude more
rare than DANE.
> > So you should be able to field a DANE-validatable self-signed cert and
> > not have trouble receiving mail from either non-DANE SMTP clients or
> > DANE-enabled SMTP clients (provided the TLSA records match that cert or
> > its public key).
>
> If I understand correctly, a mta-sts policy would be in the way of this
> working. I suppose the process would be (from such a server's point of
> view):
Yes, as noted above.
> > name = protonmail.com
> > depth = 0
> > Issuer CommonName = R13
> > Issuer Organization = Let's Encrypt
>
> So, there we go. Protonmail could then, if I understand correctly,
> receive emails from Gmail, Fastmail etc (no DANE, but MTA-STS) because
> they have a CA cert.
>
> If I understand all this correctly, then that would mean that I would
> need to either drop mta-sts (seems counter-productive), or use a CA
> certificate.
Because they also have an MTA-STS policy published, they need a
lemming-favoured (not to be confused with lemon-flavoured) CA-signed
certificate. :-)
> And, in the latter case, if memory serves me well, if I re-use the same
> private key for the certificate generation, together with a "3 1 1" tlsa
> record, then I won't have to change the tlsa record every time the
> certificate is renewed (which would be a pain, especially with even
> shorter turnaround times for LE certs next year).
Yes, renew with a fixed key by default, and deploy keys much less
frequently, manually, with the matching "3 1 1" pre-published (along
with the still active "3 1 1") *before* the key+certificate in question
is deployed.
> I also seem to remember a tool called 'danebot' by you, Viktor (if I
> may address you so), as a wrapper around certbot to preserve the
> private key.
Yes, and also supports staged rotation. There's a similar tool that may
be more polished:
- https://github.com/raforg/danectl
- https://github.com/tlsaware/danebot
Take a look at both, share your feedback.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
