When configuring a mailgateway’s TLS Settings, should one stick to the same rules for Cipher Suites as in running a HTTPS Service (prefer EDCHE/DHE, disable SSLv3, not use stuff like RC4, etc.) or should one focus more on compatibility with other MTAs to prevent email getting sent unencrypted?

It seems to me that it’s a tradeoff. On the one hand, if I use only strong Cipher Suites I’m improving the security of a majority of mails transferred because you can’t downgrade to weak Cipher Suites or SSLv3. But on the other hand, I give up encryption for some mails altogether, because they get sent unencrypted (if the other MTA is extremly old and supports only RC4, for example).

  • Just don't send or accept anything unencrypted. The account holder will get a bounce notification and hopefully the bad sender/receiver will switch to a better provider.
    – Navin
    Mar 3, 2017 at 17:33
  • @Navin although I would love to "force" 3rd parties to send their emails TLS encrypted, at least in the countries the company I work for operates, there are way to many customers/business partners that would be affected by this for this to be a viable solution
    – architekt
    Mar 4, 2017 at 7:41

3 Answers 3


Even with ciphers using 3DES or RC4 an attacker is not able to crack the cipher with moderate costs. And even secret services would probably rather do DNS MX spoofing or simply strip the STARTTLS from the features of the receiving MTA because this is much cheaper than trying to crack such ciphers.

Therefore I recommend that you accept ciphers with RC4 and 3DES in case the peer MTA can have no better ciphers, because bad encryption is definitely better than plain text and in many cases also better than not delivering the mail at all. Of course you should put these weak ciphers only at the end of your list and prefer the strong ones. And you should not use way to weak ciphers like the EXPORT ciphers.

But, if you in an environment with higher security requirements you should configure your MTA to only use strong ciphers and to make TLS mandatory, i.e. no fallback to plain even if the peer does not seem to support TLS. And you should protect yourself against MX spoofing too, i.e. enforce DNSSec. Apart from that you better use end-to-end encryption (PGP, S/MIME) in such an environment anyway.

  • 2
    The Problem is that at the moment we don´t know if RC4/3DES/etc. is even used. As asked here serverfault.com/questions/836069/… is there any way to analyse which ciphers are used by openssl so I can make an evaluation of risk due to the cipher versus how often it is used (or if it is used at all)?
    – architekt
    Mar 3, 2017 at 10:56
  • 1
    @MartinFischer: Maybe you MTA is able to log these information. Or you can sniff traffic and check which ciphers are used in the handshake. Mar 3, 2017 at 11:20

That's a good question and I'm not sure there is one good answer.

So there are two types of attacks: active and passive. For a passive attacker, broken protocols might be fine as long as the attack requires some kind of traffic modification/injection. They can't do things like generating fake certificates and signing them with a collided md5 signature because, as a passive attacker, they can't inject them in the stream.

Active attackers can do things with the connection, such as making it appear as if the mail server on the other end doesn't support TLS at all.

So generally, unless you want to force TLS and disallow plain connections altogether, I think you should figure out which protocols are safe against passive attackers. Or at least attacks that are below your level of risk: e.g. if it would cost $2 million to crack a cipher (say, RSA with 1024-bit keys) and nation states are not an adversary you're worried about, that might be acceptable.

Sorry that I don't have the time to figure out which TLS versions and ciphers are okay to use against passive attackers, but I hope this helped.


I personally would enable strong ciphers (for example, using the suggestions from https://cipherli.st/).

RC4 is effectively broken (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2808), so enabling it is at best of dubious value (it may protect against a casual observer).

That said: how much of the email you receive would be affected? From my own experience, the argument is similar to that made with regards to web browsers; there are occasionally some compelling reasons from deviating from the high-grade crypto approach, but the default approach is to not do so. In my case, it turns out that a vanishingly small amount of the mail I care about would be impacted.

I do know MTAs are not browsers, and the picture is not quite so rosy, but I also suspect the picture is not as bad as many would think (managed mail providers help).

So on balance, I would land on the HTTPS approach, rather than on the side of supporting lower-quality crypto (which in some cases isn't up to the job of protecting the data in the first place).

  • 1
    I think you're underestimating the value of RC4. The known weaknesses in RC4 don't mean that it is useless (especially when each session uses a separate RC4 key and only involves sending a relatively small amount of data, and when the attacker doesn't have much known plaintext or chosen plaintext). The weakness you link to (the "Bar Mitzvah" attack) leaks partial information about the LSBs of the first 64 bytes of plaintext for one out of every 16 million TLS connections. Hardly something that renders RC4 useless.
    – D.W.
    Mar 3, 2017 at 16:46
  • 1
    totally fair point - thanks. In the context of email, known plaintext could be an issue though, but that is probably quibbling on my part. Mar 3, 2017 at 16:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .