Is enforcing encryption for SMTP a good idea (yet)?

Solution 1:

The practical problem is that not every SMTP-compliant (the RFC is quite old) server can speak TLS to your server, so you may miss receiving some email messages.

The philosophical problem with this is that its impossible to tell how the email gets relayed after (or before) it arrived at your server.

This means that the email may have already been transmitted in plain-text via a relay already.

Anyone serious about protecting the contents of their email should actually encrypt the body. With encryption en-route its always plausible its been transmitted in plain-text already.

So, to answer your question enforcing encryption at the SMTP layer is probably pointless, increases your chance of missing email and there is no guaranteed beneficial payoff.

Edit: This refers to SMTP enforcement for the purposes of relaying, not submission of email. In mail submissions encryption should be enforced since the SMTP conversation (not the actual email) possibly contains authentication credentials.

Solution 2:

No

RFC 821 is 33 years old. You will find emails relayed by programs notsupporting STARTTLS. Sometimes they will be stub email senders (eg. internal scripts), sometimes full fledged systems that are old, have TLS disabled/not compiled in, systems without enough entropy…

I witnessed not so long ago outbound emails failing because the receiving end had it configured to only allow SMTP over TLS. It was a problem in the sender (it shouldn't had been using that configuration), but shows that it does happen.

I would only restrict incoming messages from manually configured IP addresses. If your credit card processor fails to start STARTTLS, you probably prefer to abort the connection (and page the local admin so he can warn them!) rathen than receive that (potentially sensitive) data unencrypted. For outbound messages, if you connected to that host using STARTTLS previously, you may want not to do that insecurely again, treating it as a potential compromise instead. You may also have a list of known-to-always-use-STARTTLS hosts, such as gmail or yahoo.

There's https://www.eff.org/starttls-everywhere project providing a list of smtp servers for which you can (should?) confidently enforce starttls usage.

Solution 3:

It is completely pointless, and probably actively harmful, to refuse email from encryption-incapable peers.

As long as your server is set up to do opportunistic encryption with any peer that offers it, you get the best of both worlds: encryption when it's available, and email over plaintext when it isn't.

As long as there are servers who don't support encryption, mandating it simply means they can't talk to you; that's bad. Once everyone does support it, there's no difference between opportunistic and mandatory encryption.

And as others have pointed out, encryption on-the-wire and end-to-end encryption are two completely different things, addressing different threat models. Don't confuse the two.

Solution 4:

This is a policy matter.

Generally when TLS is enforced for inbound & outbound, it's done for a limited set of domains which are agreed upon by parties to fulfill a need (for example, business partners might have an agreement to encrypt all mail between their companies).

Unless such an agreement is in place, don't turn on enforcing mode.