S/MIME might also have some dependencies on PKI that in some scenarios could make it unsuitable for high security scenarios?
For me personally, I'm not too worried about the NSA. But I do think it is quite silly that Gmail and Outlook has a little lock icon to indicate that security is ON, while the first thing that happens when you click Send is that your email is whizzed over half the internet in plaintext.
For organizations and corporations, I imagine they would very much like to be able to verify the identity of the receiving organization before delivering possibly sensitive email.
(The sender identity is already authenticated via DKIM.)
Without proper certificate validation, the encryption step is cryptographically worthless. Anyone can MITM the traffic just by presenting a random certificate to the sender.
(What does happen with your reverse-proxy when someone opens up a session and sends two mails, to two different customers?)
if hostname != target {
downstream.Write([]byte("452 Different domain, please reconnect and deliver separately.\r\n"))
continue
} else {
It is a full proxy, in the sense that it sees all of the traffic, so technically it could de-multiplex and spool to two different targets at the same time for the duration of the current email.. Hasn't been a noticeable problem so far. But it would be nice to add at a later point in time. If/when someone complains, probably.
PGP and SMIME is perfectly fine for high security scenarios (whistleblowing and such), in other words for the 0.000001% use case.
For the 99.9% use case, all that regular folks need is for the sending MX to verify that the recipient MX owns the domain before delivery.
PGP and SMIME with their key-signing parties, government-owned PKI et cetera, is either wild overkill or so utterly complex that it defeats the purpose for the 99.9% use case.
---
That said, you are going to break some of my software with this.
Specifically a SMTP reverse proxy, that looks at the domain part of RCPT TO, and transparently forwards the SMTP connection to the correct customer's MX for processing.
It could easily be unbroken again - BUT that would require that Postfix get their software together and add SNI support to their TLS stack (like all? other MX software does).
---
Implementation proposal:
1) Use RCPT domain-part for the SNI hostname.
2) Always try SMTPS port before SMTP port. Always try STARTTLS before plaintext.
3) Actually verify the certificate, duh.
4) Support a new EHLO header that mimics Strict-Transport-Security exactly.