docker
/
docker-mailserver
mirror of https://github.com/tomav/docker-mailserver.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Updated A mail server's 101 (markdown)

This commit is contained in:
Jean-Denis Vauguet 2020-06-10 03:14:21 +02:00
parent 3987a8638f
commit 66203427db
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/content/a-mail-server's-101.md
View File

@ -78,8 +78,14 @@ When talking about emails, the following applies:
As a _batteries included_ Docker image, docker-mailserver provides you with all the required components and a default configuration to run a mail server. On top of that, the [env-mailserver](https://github.com/tomav/docker-mailserver/blob/master/env-mailserver.dist) configuration file (and some other optional, advanced files!) allow you to tweak your setup extensively. You may even derive your own image from docker-mailserver for a complete control!
When it comes to security, one may consider docker-mailserver's default configuration to _not_ be 100% secure, as it uses _opportunistic_ connections using STARTTLS instead of _enforcing_ TLS-encrypted connection (SMTPS, IMAPS). That choice has been consciously made for the project aims at supporting, _by default and without custom configuration required_, all kinds of clients, including ones not able (== not configured) to use enforced/implicit TLS-encrypted connections, but still capable of handling opportunistic TLS. Please note though that _no plain text exchange will occur_ in case a client denies a STARTTLS offer, for docker-mailserver is using a [strict offer](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level) (`encrypt`) by default and will drop the client unencrypted request :relieved:
When it comes to security, one may consider docker-mailserver's **default** configuration to _not_ be 100% secure:
We believe docker-mailserver's default configuration (enforcing TLS, either opportunistic or implicit) to be a good middle ground: it goes beyond [RFC 2487](https://tools.ietf.org/html/rfc2487) "old" (1999) recommandation and abides by the "newest" (2018) [RFC 8314](https://tools.ietf.org/html/rfc8314), under the assumption that most MUA (clients) nowadays support TLS. It does mean clients without support for TLS are not supported by default though. Eventually, it is up to you deciding which kind of transportation encryption to use / enforce, and customize your instance accordingly (looser or stricter security), with the help of the project's documentation.
- it supports port 25 (unencrypted trafic by design)
- it enforces [strict opportunistic](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level) TLS-encrypted connections on ports 110 (POP3), 143 (IMAP) and 587 (SMTP) using STARTTLS
- it does _not_ support enforced TLS-encrypted connections (POP3S, IMAPS, SMTPS)
That default setup has been consciously chosen, for the project aims at supporting _by default and without custom configuration required_ all kinds of clients, including ones not supporting TLS, or ones not able (== not configured) to use enforced/implicit TLS-encrypted connections but still capable of handling opportunistic TLS.
We believe docker-mailserver's default configuration (enforcing TLS, either opportunistic or implicit) to be a good middle ground: it goes beyond [RFC 2487](https://tools.ietf.org/html/rfc2487) "old" (1999) recommandation and abides by the "newest" (2018) [RFC 8314](https://tools.ietf.org/html/rfc8314), under the assumption that most MUA (clients) nowadays support TLS; while still supporting unencrypted exchange on port 25. Eventually, it is up to you deciding exactly what kind of transportation encryption to use and/or enforce, and to customize your instance accordingly (looser or stricter security); with the help of the project's documentation.
The [README](https://github.com/tomav/docker-mailserver) is the best starting point in configuring and running your mail server. You may then explore this wiki to cover additional topics, including but not limited to, security.