37

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?

comfreak
  • 1,451
  • 1
  • 21
  • 32

8 Answers8

35

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.

Alex Mazzariol
  • 148
  • 5
Matthew Ife
  • 22,927
  • 2
  • 54
  • 71
  • 7
    I don't think this is the best answer. It gets to the right bottom-line conclusion, but for the wrong reasons. It's "letting the perfect be the enemy of the good" kind of reasoning. I think the better answer is that if you require encryption, you'll prevent some legitimate email from getting through (because some SMTP servers can't encrypt). If it weren't for that factor, then enforcing encryption *would* be beneficial, even though for all the reasons you list it is not perfect -- it would be better than nothing, even if it isn't perfect. – D.W. Oct 19 '15 at 06:57
  • I tend to disagree on perfection by mere addition of subperfections; still I submitted an edit to the answer to emphasize the possible-technical-incompatibility of servers compliant to the RFC but not supporting TLS. – Alex Mazzariol Oct 19 '15 at 09:29
  • Thanks for your answer! At first I didn't think about what happens after my server sent the mail on to the next server or, as you said, where the message "has already been" before it reached me. Of course there is no sense in enforcing encryption, if the receiving side sends it on in plain text (maybe to a subserver of the same company but still over the internet). – comfreak Oct 19 '15 at 19:59
  • I picked this answer as the accepted one since it makes clear the best that enforcing encryption on my server will not guarantee a safe/encrypted transfer of the message from the sender to the recipient but only from my server to the next. – comfreak Oct 20 '15 at 19:29
  • I think this answer is good, but fails to mention that encryption is still desired considering that only in a limited number of cases would someone go to great lengths to intercept the sender's cleartext message in order to fool you. If you are hiding from the CIA/NSA sure that might not help you. But what would be better, enforcing encryption so that no one with explicit interest to read it/intercept the senders message and hiding it until a third party decides to try to snoop on you or having all of your messages stored at the NSA servers so that one day, they can not only start ... – mjs Jun 23 '17 at 18:41
  • However, the problem still lies in that people would still use email providers such as gmail and all send messages someone ever sent you from such services and their replies would basically be available either way. There needs to be a end-to-end encryption protocol, relying on something similar to the blockchain protocol of bitcoin. – mjs Jun 23 '17 at 18:46
20

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.

Ángel
  • 627
  • 3
  • 5
  • 4
    Thanks for the answer and for posting that link! This seems to be a good approach at solving the issue of a man-in-the-middle-attack downgrading the connection to an unencrypted conversation. – comfreak Oct 19 '15 at 19:47
11

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.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • I would argue that the best of both worlds would also allow you to see the difference, similar to the "lock" of an SSL page on the web, so you know which e-mails would* have been blocked had you forced TLS – user2813274 Oct 18 '15 at 15:47
  • @user2813274 I agree, and it does. Check your headers; they'll show you whether any given step of the transmission chain was performed with, or without, encryption. – MadHatter Oct 18 '15 at 15:52
  • @MadHatter unless those headers were totally forged by the hop prior to yours. – thrig Oct 18 '15 at 16:48
  • 8
    There *is* a difference between opportunistic and mandatory encryption. It's often possible for an active MITM to disrupt opportunistic encryption, causing the endpoints to fall back to no encryption, which can be monitored. With mandatory encryption, the connection would be dropped, causing a denial of service but not a breach of privacy. – cjm Oct 18 '15 at 19:29
  • @thrig I agree you can't reply on anything in the headers prior to interaction with your own systems, but this is Matthew's point above in favour of end-to-end encryption. – MadHatter Oct 18 '15 at 19:42
  • 4
    @cjm hence my point about threat models. If you're seriously trying to defend against MITM attacks, only end-to-end-encryption can help. Relying on SMTP encryption alone is pointless; a sophisticated MITM will simply masquerade as your server, then relay the mail onto you after reading it. Sure, your server may have a properly signed certificate (which is surprisingly rare), **but you can't control whether the system sending to you requires that**, so an MITM attack such as this will succeed despite any requirements you place on an encrypted connection. – MadHatter Oct 18 '15 at 19:46
  • Thanks for the answer! I like the part where you state that once everyone supports it, there is no difference anymore between enforcing it and just offering it (if you keep MITM out of the question). I also like the approach of the [EFF](https://www.eff.org/starttls-everywhere), where they want to keep a list of hosts that are known to support encryption and always force encryption there, especially to people/companies who you share private information with. – comfreak Oct 19 '15 at 19:50
  • @comfreak I'm glad you like the answers you've got! May I urge you to accept one of them, by clicking the tick outline next to it? This drives the SF reputation system for you and the author of the answer. It also stops the question floating around forever like a querulous albatross. My apologies if you already know this. – MadHatter Oct 19 '15 at 22:55
10

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.

MikeyB
  • 38,725
  • 10
  • 102
  • 186
3

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: Disabling Anonymous Diffie Hellman .

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.

Paul
  • 2,755
  • 6
  • 24
  • 35
Mce128
  • 31
  • 4
2

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.

Community
  • 1
cnst
  • 12,948
  • 7
  • 51
  • 75
0

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.

Scott
  • 9
  • 1
0

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

ERM
  • 1