[capt_hotpants]

A thousand times yes.

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.

[Flimm]

Actually, even PGP is not fine for high security scenarios. For example, it doesn't encrypt headers, including the subject line, which I would say is just as important as an email's body.

[hannob]

Some people are trying to fix that: https://modernpgp.org/memoryhole/

[capt_hotpants]

Good point.

S/MIME might also have some dependencies on PKI that in some scenarios could make it unsuitable for high security scenarios?

[pjc50]

What is the 99% use case? Most people's email has one endpoint at either a big cloud provider or an employer, both of which are examining it at rest.

[capt_hotpants]

Good question!

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.)

[thrownaway2424]

For organizations that subscribe to these cloud services (like Google Apps, or hosted Exchange) there are settings to enforce the use of TLS on both inbound and outbound. For example https://support.google.com/a/answer/2520500

[capt_hotpants]

If you read the fine print in bullet #8, you'll discover that there is, per default, no validation of the presented certificate at all.

Without proper certificate validation, the encryption step is cryptographically worthless. Anyone can MITM the traffic just by presenting a random certificate to the sender.

[caf]

You are assuming that only one RCPT is being sent in the session.

(What does happen with your reverse-proxy when someone opens up a session and sends two mails, to two different customers?)

[capt_hotpants]

Currently, this happens:

   if hostname != target {
      downstream.Write([]byte("452 Different domain, please reconnect and deliver separately.\r\n"))
      continue
   } else {

As a side-effect, email to the secondary domain is slightly delayed.

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.

[capt_hotpants]

5) Slap a nice name on the feature-set, so products can advertise it. (An important step often forgotten by engineers ;-))