On Oct 16, 2019, at 1:43 PM, Дилян Палаузов
What happens to MTAs, that are so smart to understand MTA-STS or DANE, but
offer only weak ciphers?
MTA-STS specifies at least TLS 1.2:
So operators who enable MTA-STS, but only TLS 1.0 are negligent, and will
DANE (~3 years earlier) specifies at least TLS 1.0 and SHOULD TLS 1.2:
The Postfix TLS implementation does not allow enable ciphers
when TLS is mandatory, and these are rapidly disappearing
entirely from TLS stacks.
Does somebody offer both EC and RSA certificates on its smtp:25 server and
had this ever caused problems?
This generally just works.
Does somebody offer both EC and RSA certificates with DANE on its smtp:25
server and had this ever caused problems?
Yes, there are such sites. This just works with MTA-STS and DANE-TA(2)
trust-anchor TLSA RRs, as only the name in the certificate matters, the
algorithm is not so important. With DANE-EE(3), the TLSA RR becomes
public-key-dependent, and multiple TLSA RRs are needed when fielding
certs for multiple algorithms. See
But multi-cert MTAs are uncommon, and this is not actually difficult
to get right, single-cert rollover blunders account for almost all
How much bits shall DH params have to support acceptable amount of mailhosts?
I don't know of any MTAs that will refuse 1024-bit DH, but better to
use 2048 and better still ECDHE with P-256.
Do too big DH params break some clients?
What elliptic curves shall be offered, so that the communication works with
acceptable amount of hosts?
The "market consensus" is NIST P256, everything else is rare,
but you need to enable negotiation, and also support P384,
just in case. There is also non-trivial use of X25519 these
days, but systems that use it, can also use P256 as needed.
ietf-smtp mailing list