I am running an email server which is currently set up to use TLS if possible, when sending and receiving emails.
When you read in the documentation about this, there is also the option to enforce TLS and not accept plain text transmission of emails. It also warns you that some mail servers might not support encryption yet and enforcing encryption could block these servers.
But is this still an issue one should think about or is it safe to say that enforcing encryption won't be a problem anymore?
Is there possibly some big provider who is already doing this or what do you consider best practice these days?
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.
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.
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.
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.
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:
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.
I do have to concur on the idea of using opportunistic TLS. Although, I do have some to add to the idea as well. Some will likely be disturbed by the suggestions, however, as my suggestions here are not made lightly and without due consideration, before casting judgment, I ask that you please read the full discussion from the attached link.
Using opportunistic TLS is by far and wide the best solution. The MITM angle as an argument against it is a red herring. After all, as MH mentioned in a comment, even a "legit" SMTP with TLS connection can be MITM'd and the end user be none the wiser due to the vast majority of mail client's not bothering to validate certificates coupled with the vast majority of MTAs out there doing TLS are using self-signed certificates (at least if yiur not using DNSSEC and TLSA/DANE.) As a result of this and possibly other factors, it is even arguable that until both you and the rest of the world has implemented DANE/TLSA and DNSSEC, that while running opportunistic TLS it is better than not to also have anonymous diffie-hellman (while also using PFS) enabled as well. Due at least partly if not mostly to the fact that it will still encrypt the traffic protecting against the casual observer. In further support of this configuration (with a much more elaborate explanation than mine,) please see the comments by Viktor Dukhovni in this post in a postfix forum: http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html
As to why one might take Viktor's suggestions over that of others, well, he wrote the TLS code as well as the DNSSEC, TLSA/DANE code for the Postfix MTA in addition to having been the one to have written the IETF drafts on both DNSSEC and TLSA/DANE. As such, I would say that his words on the matter carry quite a lot of weight, probably more than those of most.
Hope this helps.
We enforce SMTP (TLS) encryption on our public mail-server for two years now. We have learned that 99,99% of all 'missed' communications originated from spammers, phishers and known exploited hosts (we check each IP address). We had only issues with two legitimate companies that tried to deliver emails as plain-text which was refused. After we notified them they changed their server or provider to fix that issue.
Enforcing TSL on email-servers makes the world safer and it practically makes the use of a spam-filter obsolete because no spammer or phisher will ever use an certificate to send messages encrypted. It keeps our mail-server clean and fast.
Before we did this, at least 96% of all received mail was marked as spam by our filter, now more than 99% of incoming mails is legitimate. Only spammers would advice against it.
From an email marketing perspective, the use of TLS is good practice and secure when you know that it is implemented through the entire chain of delivery. However if security is your top requirement then encrypting the email itself before sending it is the most secure option (for example with PGP).