Question is really simple. If I want to setup a mail server, do i have to have it or is it just a security issue? What kind of problems can it cause?
-
9_"Just"_ a security issue? What? – SLaks Jun 08 '12 at 21:55
-
3I meant is it _possible_ to have a mail server without SSL certificate. Are other mail servers let me to commumincate them if i do not have a certificate? – Jun 08 '12 at 21:59
-
It's probably more important that you have reverse DNS matching your server's hostname (your ISP owns your IP so you need to talk with them too arrange this). I've had mails refused because of a mismatch. – username Jun 09 '12 at 12:05
3 Answers
Do you want to prevent people from sniffing your password? This is especially easy on WiFi. Then use encryption (SSL).
Do you care about having a self-signed certificate (getting a warning about it)? If not, just self sign. But beware there are apps (outlook) that do not allow you to ignore that warning after having seen it once.
The thing with SSL is, that it incorporates encryption and identity checks in the same protocol. You don't need a certificate for the former, but you do for the latter. If you don't suspect someone is going to redirect your login attempts to another server, you don't need the identity check: so self-sign. And even then it is not really a problem. Because in most clients once you've accepted your own certificate, it will warn again when it changes.
If you do want a certificate (I like to have them), use Startcom SSL. They allow you to have a simple SSL certificate for free.
Edit: Startcom can now no longer be recommended, because they have been blacklisted by major browsers, because their new owner, WoSign, violated the rules.
![](../../users/profiles/31475.webp)
- 7,921
- 5
- 42
- 81
For mail retrieval (POP/IMAP) and MSA usage, although it's not necessary, it's definitely a good idea. Nowadays, many people access the e-mails from networks that cannot be trusted, typically from a mobile phone on an open WiFi network. Making your users connect via SSL/TLS is a good idea.
For MTA usage, you probably shouldn't expect SSL/TLS. It would be a good idea in principle, but few MTAs support SSL/TLS connections between themselves. (See this question for details.) There are multiple options here:
If you enable SSL/TLS only on your MTA (without any possibility of interaction without it enabled), you'll effectively cut yourself out of a number of other MTAs that wouldn't support it.
If you enable both SSL/TLS and plain text communications:
- It's fine for other MTAs that know that your server supports SSL/TLS and will only connect to it in secure mode. This can be useful in a few cases where they expect the connection between them and you to need to be secure, but they'd have to be explicitly configured to do so.
- If the other MTAs don't know that you support SSL/TLS, even if they try SSL/TLS in an opportunistic fashion, the fact that they would fall back to plain-text connections when SSL/TLS isn't available leaves them open to active MITM attacks. There's little point in using SSL/TLS at all in this case.
Remember that checking that SSL/TLS is used (and used correctly, including certificate verification) is solely the responsibility of the client, i.e. the other MTA here (nothing can be done on the server side in case of downgrading MITM attacks, unless client-certificates are also used, which is unlikely between MTAs).
If your server acts both as an MTA and an MSA (i.e. it expects direct connections from the user), I'd suggest enabling both with and without SSL/TLS, but tell your users to use the SSL/TLS option.
-
I disagree with the second point that MTAs "shouldn't use a certificate". Most MTAs can use TLS in an opportunistic fashion and with self-signed certs so there's no cost or significant hindrance to using it. – Mike B Jun 13 '12 at 17:12
-
@MikeB, sorry my wording wasn't clear. I meant that they shouldn't *only* use a certificate, since enabling SSL/TLS there isn't very useful. I've edited my answer. SSL/TLS in an opportunistic fashion isn't very useful, since it's open to downgrade attacks: either the client knows it must use SSL/TLS and doesn't fall back, or it doesn't care. (Similar reasons why [*"Use TLS if available"* in Thunderbird](https://bugzilla.mozilla.org/show_bug.cgi?id=473080) is close to useless, unless you know in advance that no one is going to tamper with the connection.) – Bruno Jun 13 '12 at 17:26
-
For 2.{1,2}: STARTTLs (And no, it isn't close to useless, you shouldn't really just randomly trust every cert, and even if you did it would be better than letting anyone read the emails) – remmy Jul 13 '14 at 00:39
-
@kyrias, I don't get your point about STARTTLS. Either you want to use SSL/TLS (upfront or via STARTTLS) and you make sure you use it, or you don't. Falling back without knowing only protects from passive eavesdropper, not MITM attackers. Of course, it's not necessarily a bad thing, better than nothing. It's just I'd guess attackers who are in a position to eavesdrop between MTAs are also very likely to be in a position to mount a MITM attacks: at that stage, the networks would tend to be within the hands of professionals exclusively, who'd certainly be in charge of the routers, etc. – Bruno Jul 13 '14 at 13:51
Well, you don’t specify the type of mailserver. For example, I have Microsoft Exchange which, as far as I know, can run without a cert, with a self-signed cert, or, of course, with an official certificate.
The user will notice the difference, of course, having to click through security warnings.
![](../../users/profiles/39133.webp)
- 1,167
- 2
- 13
- 30
![](../../users/profiles/123263.webp)
- 471
- 1
- 10
- 24