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.
Solution 5:
No, it's a very bad idea.
In fact, as it turns out, most STARTTLS servers/clients do not implement any sort of a retry algorithm without StartTLS should a TLS connection fail to negotiate.
As such, even advertising STARTTLS as an option already reduces your chances of getting (and sending) emails!
Just search, and you'll find many people not being able to send ANY email to Microsoft Outlook domains handled by *.protection.outlook.com cluster:
Sendmail messages rejected from Microsoft when using TLS
reason: 403 4.7.0 TLS handshake failed
To summarise issues presented in the above two posts:
- can send any mail to any host other than those handled by Outlook, with or without STARTTLS,
- can send mail without a client certificate and without STARTTLS to Outlook,
- or with a zero-length client certificate,
- but not with a certificate that Microsoft doesn't like, and upon failure, the clients (well, servers acting in client mode) don't attempt to re-send the message without STARTTLS if the recipient's server does advertise STARTTLS!
Likewise, when your host acts as a server, a similar situation may occur outside of your control if you decide to enable STARTTLS — when a client server sees that your server in server mode offer STARTTLS, they try to negotiate TLS, but if negotiation fails, they simply wait, and retry the same steps again, keep on failing until the message has to be bounced back to sender!
And this does happen pretty frequently with various domains in the STARTTLS land!
Sadly, as much as I used to be a STARTTLS supporter in the past, I'm now very disenfranchised that I was misled by the risk-free advertisement of what I thought was supposed to be opportunistic encryption.
Not only should you not require STARTTLS, but it may even be prudent to completely disable it, if you want to ensure the interoperability.