On Fri, May 23, 2025 at 2:48 AM Eliot Lear <lear@lear.ch> wrote:
It's not that hypothetical. I bring to your attention draft-halen-fedae, which has been deployed in Sweden to create trust within a federation of private CAs.
Using a client TLS cert with SMTP is an option within the TLS protocol, and some clients do. Some servers may expect to verify this client cert. I have already seen non-theoretical cases where some internet domain refuses all non-TLS SMTP traffic at their MX hosts by design; they may in addition consider traffic with fully valid mutual TLS differently. Mail servers can take into account whether a valid client cert was presented during an incoming TLS connection as one of many factors which affects herustic spam filter scores. Even when a failure is not considered as equal to a SPF fail or hard drop. You can also look at Office 365 and Certificate-based connectors often used in Hybrid deployments with Microsoft Exchange. Cert-based connectors are especially required for cases where you can't know or guarantee what the IP address of the SMTP client will be beforehand. For example your on-premise environment has a dynamic IP address. You require a cert-based connector to authenticate your On-premise server's access to route mail to outside domains through the 365 service's public SMTP relay hosts which rely on mTLS for authentication. When your SMTP client connects to their public relay servers; a client certificate is presented at the TLS helo. As far as I know Microsoft does not allow you to import any actual certificates into their servers. Neither do you have options of using your own private PKI; the config involves setting details to match the certificate. The cert has to be signed by a CA and contain specified domain names belonging to your org in the subjectAltNames in order to verify your authority over the domains for public relay (Sending email to their public SMTP relay servers which has a Rcpt To: address outside of your organization). -- -JA