github-com-docker-mailserver/docker-mailserver
1
0
Fork 0
mirror of https://github.com/docker-mailserver/docker-mailserver.git synced 2024-01-19 02:48:50 +00:00
Code Issues Projects Releases Wiki Activity

Updated A mail server's 101 (markdown)

Browse source
This commit is contained in:
Jean-Denis Vauguet 2020-06-12 05:48:11 +02:00
parent f5de8197f8
commit cbfe8425bc
1 changed files with 123 additions and 47 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

170
docs/content/a-mail-server's-101.md
View file

@ -3,91 +3,167 @@ Here's an introduction to the field that covers everything you need to know to g
## Anatomy of a mail server
A mail server is only a part of a [client-server relationship](https://en.wikipedia.org/wiki/Client%E2%80%93server_model) aimed at exchanging information in the form of emails. Exchanging emails requires using specific means (programs and protocols).
A mail server is only a part of a [client-server relationship](https://en.wikipedia.org/wiki/Client%E2%80%93server_model) aimed at exchanging information in the form of [emails](https://en.wikipedia.org/wiki/Email). Exchanging emails requires using specific means (programs and protocols).
This project provides with the server portion, whereas "the" client can be anything from a console, text-only software (eg. [Mutt](https://en.wikipedia.org/wiki/Mutt_(email_client))) to a fully-fledged desktop application (eg. [Mozilla Thunderbird](https://en.wikipedia.org/wiki/Mozilla_Thunderbird), [Microsoft Outlook](https://en.wikipedia.org/wiki/Microsoft_Outlook)…), to a webmail, etc.
docker-mailserver provides you with the server portion, whereas "the" client can be anything from a console, text-only software (eg. [Mutt](https://en.wikipedia.org/wiki/Mutt_(email_client))) to a fully-fledged desktop application (eg. [Mozilla Thunderbird](https://en.wikipedia.org/wiki/Mozilla_Thunderbird), [Microsoft Outlook](https://en.wikipedia.org/wiki/Microsoft_Outlook)…), to a webmail, etc.
Unlike the client side where usually a single program is used, there are many components making up the server. Specialized piece of software handle atomic tasks, such as receiving emails, dropping emails into mailboxes, sending emails to other mail servers, filtering emails, exposing emails to authorized clients, etc.
Unlike the client side where usually a single program is used to perform retrieval and reading of emails, the server side is composed of many specialized components. "The" mail server is capable of accepting, forwarding, delivering, storing and overall exchanging messages, but each one of those tasks is actually handled by a specific piece of software, which must be integrated with one another.
The docker-mailserver project has made some informed choices about those components and offers a comprehensive platform to run a feature-full mail server.
docker-mailserver has made some informed choices about those components and their (default) configuration. It offers a comprehensive platform to run a feature-full mail server in no time!
## Components
The following components are required to create a [complete delivery chain](https://en.wikipedia.org/wiki/Email_agent_(infrastructure)):
- MUA: a [Mail User Agent](https://en.wikipedia.org/wiki/Email_client) is basically any client/program capable of sending emails to arbitrary mail servers; and most of the times, capable of fetching emails from such mail servers.
- MTA: a [Mail Transfer Agent](https://en.wikipedia.org/wiki/Message_transfer_agent) is the so-called "mail server" as seen from the MUA's perspective. It's a piece of software dedicated to accepting emails: either from MUAs or from other MTA (the latter task being symmetrical, meaning a MTA is also is capable of sending/transferring emails to other MTA, hence the name).
- MDA: a [Mail Delivery Agent](https://en.wikipedia.org/wiki/Mail_delivery_agent) is responsible for accepting emails from an MTA, but instead of forwarding it, it is capable of dropping those emails into their recipients' mailboxes, whichever the form.
- MUA: a [Mail User Agent](https://en.wikipedia.org/wiki/Email_client) is basically any client/program capable of sending emails to arbitrary mail servers; and most of the times, capable of fetching emails from such mail servers and presenting them to the end users.
- MTA: a [Mail Transfer Agent](https://en.wikipedia.org/wiki/Message_transfer_agent) is the so-called "mail server" as seen from the MUA's perspective. More specifically, it's a piece of software dedicated to accepting, and in some cases, transfering/relaying emails. A MTA may accept incoming emails either from MUAs or from other MTAs. It may then relay emails to either other MTAs or, eventually, an MDA.
- MDA: a [Mail Delivery Agent](https://en.wikipedia.org/wiki/Mail_delivery_agent) is responsible for accepting emails from a MTA, but instead of forwarding it to another MTA, it is responsible for dropping emails into their recipients' mailboxes, whichever the form.
There may be other moving parts or sub-divisions. For instance, at several point specialized programs may be filtering, bouncing, editing… exchanged emails.
Here's a schematic view of mail delivery:
In a nutshell, docker-mailserver provides you with the following agents:
```txt
Sending an email: MUA ---> MTA ---> MTA ---> ... ---> MTA ---> MDA
Fetching an email: MUA <--------------------------------------- MDA
```
- MTA: Postfix
- MDA: Dovecot
There may be other moving parts or sub-divisions (for instance, at several point along the chain, specialized programs may be analyzing, filtering, bouncing, editing… the exchanged emails).
and with some specialized, companion programs to form a complete delivery chain (minus the MUA of course).
In a nutshell, docker-mailserver provides you with the following components:
> One important thing to know is that both the MTA and MDA programs actually handle _multiple_ tasks. For instance, Postfix is both an SMTP server (accepting email) and an MTA (transfering email); Dovecot is both an MDA (delivering emails in mailboxes) and an IMAP server (allowing MUAs to fetch emails from the so-called mail server). On top of that, Postfix may rely on Dovecot's authentication capabilities. The exact relationship between all the components and their respective or, sometimes, shared responsibilities is beyond the scope of this document. Explore the wiki to get more insights about the toolchain.
- MTA: [Postfix](http://www.postfix.org/)
- MDA: [Dovecot](https://dovecot.org/)
- a bunch of additional programs to improve security and emails processing
## About security, ports…
Here's where docker-mailserver's toochain fits within the delivery chain:
For both Postfix and Dovecot need to be accessible from the outside to act as servers, they expose themselves through TCP ports, which may be secured using different schemes.
```txt
docker-mailserver is here:
┏━━━━━━━┓
Sending an email: MUA ---> MTA ---> MTA ---> ... ---> ┫ MTA ╮ ┃
Fetching an email: MUA <------------------------------ ┫ MDA ╯ ┃
┗━━━━━━━┛
```
### SMTP
By default, docker-mailserver does not act as a relay nor does it accept emails from relays. It only handles direct email trafic, bound to a specific hostname. Thus our schema can be further simplified to look like this:
A MUA sending an email to a [SMTP](https://en.wikipedia.org/wiki/SMTP) server communicates using data packets exchanged over a network that both the client and the server are part of. In the case of docker-mailserver, the server is Postfix. The MUA may be anything, and its submission/request is (most frequently!) performed as [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) packets sent over the _public_ internet. This exchange of information may, or may not, be secured in order to counter eavesdropping.
```txt
docker-mailserver is here:
┏━━━━━━━┓
Sending an email: MUA ---> ┫ MTA ╮ ┃
Fetching an email: MUA <--- ┫ MDA ╯ ┃
┗━━━━━━━┛
```
**The best practice as of 2020 would be [SMTPS](https://en.wikipedia.org/wiki/SMTPS) over port 465**. It has the server _enforce_ the client into using an encrypted TCP connection, using [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) (see [RFC 8314](https://tools.ietf.org/html/rfc8314)). With this setup, the mail server should deny any client attempting at submitting emails in plain text; it should require a TLS-encrypted exchange to exist from the get go (no connection upgrade using an opt-in STARTTLS mechanism, see next paragraph). That SMTPS setup is said to _Implicit_ (aka. enforced) TLS encryption.
> Of course the MUA and docker-mailserver's MTA may be located in distant (network-wise) places, so don't expect a _direct_ connection between MUAs and your mail server. It is very likely email trafic will hop through many relaying HTTP servers (simply not MTA servers).
Another well-documented, extensively used mail submission setup is SMTP+STARTTLS. It uses _Explicit_ (aka. opportunistic) TLS over port 587, with an opt-in TLS upgrade of the client-to-server connection using using [STARTTLS](https://en.wikipedia.org/wiki/Opportunistic_TLS). With this setup, the mail server should accept unencrypted requests but should automatically respond to the client with an "offer" to upgrade the connection to a TLS-encrypted one; but it also should allow the client to deny that proposal and eventually still accept unencrypted mail exchange (although some servers may eventually deny unencrypted trafic). Overall, this setup requires more configuration and is less secure by design (hence the name "opportunistic"). As of 2020, it is recommended by RFC 8314 for mail servers to support it, but as a to-be-deprecated protocol and to encourage clients to switch to SMTPS.
One important thing to note is that MTA and MDA programs may actually handle _multiple_ tasks (which is the case with docker-mailserver's Postfix and Dovecot).
A final setup exists and is akin SMTP+STARTTLS, but over port 25. That port has historically been reserved specifically for plain text mail exchange. One may upgrade the connection on port 25 to a TLS-encrypted one, but that should be considered a non-normative usage. It's better reserving port 25 for plain text trafic in order to support older clients, and inter-MTA exchange (although obviously non-secure).
For instance, Postfix is both a SMTP server (accepting emails) and a relaying MTA (transfering ie. sending emails to other MTA/MDA); Dovecot is both a MDA (delivering emails in mailboxes) and an IMAP server (allowing MUAs to fetch emails from the so-called "mail server"). On top of that, Postfix may rely on Dovecot's authentication capabilities!
### IMAP
The exact relationship between all the components and their respective (and sometimes, shared) responsibilities is beyond the scope of this document. Please explore this wiki & the web to get more insights about docker-mailserver's toolchain.
A MUA reading emails from an [IMAP](https://en.wikipedia.org/wiki/IMAP) server communicates using data packets exchanged over a network that both the client and the server are part of. In the case of docker-mailserver, the server is Dovecot. The MUA may be anything, and its retrieval request is (most frequently!) performed as [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) packets sent over the _public_ internet. This exchange of information may, or may not, be secured in order to counter eavesdropping.
## About security & ports
As with SMTP (described above), the IMAP protocol may be secured with either: _Implicit_ (enforced) TLS (aka. [IMAPS](https://en.wikipedia.org/wiki/IMAPS), sometimes written IMAP4S); or _Explicit_ (opportunistic) TLS using STARTTLS.
In the previous section, different components were outlined. Each one of those is responsible for a specific task, it has a specific purpose.
**The best practice as of 2020 would be IMAPS over port 993**, rather than IMAP+STARTTLS over port 143 (see [RFC 8314](https://tools.ietf.org/html/rfc8314)).
Three main purposes exist when it comes to exchanging emails:
### POP3
- _Submission_: for a MUA (client), the act of sending actual email data over the network, toward a MTA (server).
- _Transfer_ (aka. _Relay_): for a MTA, the act of sending actual email data over the network, toward another MTA (server) closer to the final destination (where a MTA will forward data to a MDA).
- _Retrieval_: for a MUA (client), the act of fetching actual email data over the network, from a MDA.
Similarly to IMAP, POP3 may be secured with either: _Implicit_ (enforced) TLS (aka. POP3S); or _Explicit_ (opportunistic) TLS using STARTTLS.
Postfix handles Submission (and might handle Relay), whereas Dovecot handles Retrieval. They both need to be accessible by MUAs in order to act as servers, therefore they expose public endpoints on specific TCP ports. Those endpoints _may_ be secured, using an encryption scheme.
**The best practice as of 2020 would be [POP3S](https://en.wikipedia.org/wiki/POP3S) over port 995**, rather than [POP3](https://en.wikipedia.org/wiki/POP3)+STARTTLS over port 110 (see [RFC 8314](https://tools.ietf.org/html/rfc8314)).
When it comes to the specifics of email exchange, we have to look at protocols and ports enabled to support all the identified purposes. There are several valid options and they've been evolving overtime.
### Summary of ports/security setups
**Here's docker-mailserver's _default_ configuration:**
When talking about emails, the following applies:
| Purpose | Protocol | TCP port / encryption |
|----------------|----------|--------------------------------|
| Transfer/Relay | SMTP | 25 (unencrypted) |
| Submission | ESMTP | 587 (encrypted using STARTTLS) |
| Retrieval | IMAP4 | 143 (encrypted using STARTTLS) + 993 (TLS) |
| Retrieval | POP3 | _Not activated_ |
| Protocol | Purpose | Default port w/ opt-in Encryption<sup>1</sup> | Enforced Encryption |
|----------|----------------------|-----------------------------------------------|------------------------|
| SMTP | Transfer<sup>2</sup> | 25 | N/A |
| ESMTP | Submission | 587 _(deprecated<sup>4</sup>)_ | SMTPS 465<sup>3</sup> |
| POP3 | Retrieval | 110 _(deprecated<sup>4</sup>)_ | POP3S 995 |
| IMAP4 | Retrieval | 143 _(deprecated<sup>4</sup>)_ | IMAPS 993 |
If you're new to the field, that table may be confusing.
Read on to gain insights about docker-mailserver's configuration and how you may customize it.
1. An insecure, unencrypted connection *may* be upgraded to a secured one (over TLS) when _both_ ends support the `STARTTLS` mechanism. On ports 110, 143 and 587, `docker-mailserver` *will* reject a connection that cannot be secured with STARTTLS (_preventing [MITM attacks](https://stackoverflow.com/questions/15796530/what-is-the-difference-between-ports-465-and-587/32460763#32460763) trough a downgrading_). Note that port 25 is [required](https://serverfault.com/questions/623692/is-it-still-wrong-to-require-starttls-on-incoming-smtp-messages) to support insecure connections; whereas other ports are not and may be limited to STARTTLS (which docker-mailserver enforces).
2. Port 25 is for _incoming_ mail transfer_, ie. it receives email and may filter for spam and viruses upon reception. For transferring _outgoing_ mail (eg. sending emails from within docker-mailserver to another mail server), you should prefer the submission ports (465, 587), which require authentication in docker-mailserver. Unless a relay host is configured, outgoing email will _leave_ the server via port 25 (thus outbound traffic must not be blocked by your provider or firewall).
3. Port 465 is a submission port again since 2018, see [RFC 8314](https://tools.ietf.org/html/rfc8314). Originally a secure variant of port 25, it is now dedicated to SMTPS.
4. [RFC 8314](https://tools.ietf.org/html/rfc8314) is recommending that clear text exchanges to be abandoned and that all three common IETF mail protocols to be used only in implicit mode (no STARTTLS).
On a final note, here's what docker-mailserver's default configuration provides you with (feel free to skip this schema for now):
```txt
┏━━━━━━━━ Submission ━━━━━━━━┓┏━━━━━━━━━━━━ Transfer/Relay ━━━━━━━━━━━━┓
┌────────────────────┐ ┌┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
Sending an email: MUA --- STARTTLS --> ┤(587) MTA ╮ (25)├ <-- plain text --> ┊ Third-party MTA ┊
|┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄| └┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
Fetching an email: MUA <-- STARTTLS --- ┤(143) MDA ╯ |
<---- TLS ------ ┤(993) |
└────────────────────┘
┗━━━━━━━━━ Retrieval ━━━━━━━━━┛
```
### Submission - SMTP
A MUA willing to send an email to a MTA needs to establish a connection with that server, then push data packets over a network that both the MUA (client) and the MTA (server) are connected to. The server implements the [SMTP](https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol) protocol, which makes it capable of handling _Submission_.
In the case of docker-mailserver, the MTA (SMTP server) is Postfix. The MUA (client) may vary, yet its Submission request is performed as [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) packets sent over the _public_ internet. This exchange of information may be secured in order to counter eavesdropping.
The best practice as of 2020 would be to handle emails Submission using an _Implicit TLS connection with an ESMTP server on port 465_ (see [RFC 8314](https://tools.ietf.org/html/rfc8314)). Let's break it down.
- Implicit TLS means the server _enforces_ the client into using an encrypted TCP connection, using [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security). With this kind of connection, the MUA _has_ to establish a TLS-encrypted connection from the get go. The mail server would deny any client attempting at submitting emails in plain text (== not secure) or requesting a plain text connection to be upgraded to a TLS-encrypted one (== eventually secure). It is also known as Enforced TLS.
- [ESMTP](https://en.wikipedia.org/wiki/ESMTP) is [SMTP](https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol) + extensions. It's the version of the SMTP protocol that most mail servers speak nowadays. For the purpose of this documentation, ESMTP and SMTP are synonymous.
- Port 465 is _de facto_ the TCP port that's reserved for Implicit TLS SMTP connections. There is a boisterus history to it, but let's keep it simple.
> Note: this Submission setup is sometimes refered to as [SMTPS](https://en.wikipedia.org/wiki/SMTPS). Long story short: this is incorrect and should be avoided.
Although a very satisfactory setup, Implicit TLS on port 465 is somewhat "cutting edge". There exists another well established mail Submission setup that must be supported as well, SMTP+STARTTLS on port 587. It uses Explicit TLS: the client starts with a plain text connection, then the server informs a TLS-encrypted "upgraded" connection may be established, and the client _may_ eventually decide to establish it prior to the Submission. Basically it's an opportunistic, opt-in TLS upgrade of the connection between the client and the server, at the client's discretion, using a mechanism known as [STARTTLS](https://en.wikipedia.org/wiki/Opportunistic_TLS) that both ends need to implement.
In many implementations, the mail server doesn't enforce TLS encryption, for backwards compatibility. Clients are thus free to deny the TLS-upgrade proposal, and the server eventually accepts unencrypted (plain text) mail exchange, which poses a confidentiality threat and, to some extent, spam issues. [RFC 8314 (section 3.3)](https://tools.ietf.org/html/rfc8314) recommends for mail servers to support both Implicit and Explicit TLS for Submission, _and_ to enforce TLS-encryption on ports 587 (Explicit TLS) and 465 (Implicit TLS). That's exactly docker-mailserver's default configuration: abiding by RFC 8314, it [enforces a strict (`encrypt`) STARTTLS policy](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level), where a denied TLS upgrade terminates the connection thus preventing unencrypted (plain text) Submission by the client.
- **docker-mailserver's default configuration enables and _requires_ Explicit TLS (STARTTLS) for Submission on port 587.**
- It does not enable Implicit TLS Submission on port 465 by default. One may enable it through simple custom configuration, either as a replacement or (better!) supplementary mean of secure Submission.
- It does not support old MUAs (clients) not supporting TLS encryption. One may relax that constraint through advanced custom configuration, for backwards compatibility.
A final Submission setup exists and is akin SMTP+STARTTLS on port 587, but on port 25. That port has historically been reserved specifically for unencrypted (plain text) mail exchange though, making STARTTLS a bit of a misusage. As is expected by [RFC 5321](https://tools.ietf.org/html/rfc5321), docker-mailserver uses port 25 for unencrypted Submission in order to support older clients (Submission), but most importantly for unencrypted Transfer/Relay between MTAs.
- **docker-mailserver's default configuration enables unencrypted (plain text) for Transfer/Relay on port 25.**
- It does not enable Explicit TLS (STARTTLS) Transfer/Relay on port 25 by default. One may enable it through advanced custom configuration, either as a replacement (bad!) or as a supplementary mean of secure Transfer/Relay.
- One may also secure Transfer/Relay on port 25 using advanced encryption scheme, such as DANE and/or MTA-STS.
### Retrieval - IMAP
A MUA willing to fetch an email from a mail server will most likely communicate with its [IMAP](https://en.wikipedia.org/wiki/IMAP) server. As with SMTP described earlier, communication will take place in the form of data packets exchanged over a network that both the client and the server are connected to. The IMAP protocol makes the server capable of handling _Retrieval_.
In the case of docker-mailserver, the IMAP server is Dovecot. The MUA (client) may vary, yet its Retrieval request is performed as [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) packets sent over the _public_ internet. This exchange of information may be secured in order to counter eavesdropping.
Again, as with SMTP described earlier, the IMAP protocol may be secured with either Implicit TLS (aka. [IMAPS](https://en.wikipedia.org/wiki/IMAPS)/IMAP4S) or Explicit TLS (using STARTTLS).
The best practice as of 2020 is to enforce IMAPS on port 993, rather than IMAP+STARTTLS on port 143 (see [RFC 8314](https://tools.ietf.org/html/rfc8314)); yet the latter is usually provided for backwards compatibility.
**docker-mailserver's default configuration enables both Implicit and Explicit TLS for Retrievial, on ports 993 and 143 respectively.**
### Retrieval - POP3
Similarly to IMAP, the older POP3 protocol may be secured with either Implicit or Explicit TLS.
The best practice as of 2020 would be [POP3S](https://en.wikipedia.org/wiki/POP3S) on port 995, rather than [POP3](https://en.wikipedia.org/wiki/POP3)+STARTTLS on port 110 (see [RFC 8314](https://tools.ietf.org/html/rfc8314)).
**docker-mailserver's default configuration disables POP3 altogether.** One should expect MUAs to use TLS-encrypted IMAP for Retrieval.
## How does docker-mailserver help with setting everything up?
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!
As a _batteries included_ Docker image, docker-mailserver provides you with all the required components and a default configuration, to run a decent and secure mail server.
When it comes to security, one may consider docker-mailserver's **default** configuration to _not_ be 100% secure:
One may customize all aspects of internal components.
- Simple customization is supported through [docker-compose configuration](https://github.com/tomav/docker-mailserver/blob/master/docker-compose.yml.dist) and the [env-mailserver](https://github.com/tomav/docker-mailserver/blob/master/env-mailserver.dist) configuration file.
- Advanced customization is supported through providing "monkey-patching" configuration files and/or [deriving your own image](https://github.com/tomav/docker-mailserver/blob/master/Dockerfile) from docker-mailserver's upstream, for a complete control over how things run!
- it supports port 25 (unencrypted trafic by design)
- it enforces [strict (`encrypt`) 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)
On the subject of security, one might consider docker-mailserver's **default** configuration to _not_ be 100% secure:
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.
- it enables unencrypted trafic on port 25 for Transfer/Relay (between MTAs for MX service)
- it enables Explicit TLS (STARTTLS) on port 587 for SMTP, instead of Implicit TLS on port 465
We believe docker-mailserver's default configuration (enforcing TLS, either opportunistic or implicit) to be a good middle ground: it goes slightly beyond [RFC 2487](https://tools.ietf.org/html/rfc2487) "old" (1999) recommandation, and with developper-friendly configuration settings, makes it pretty easy to abide by the "newest" (2018) [RFC 8314](https://tools.ietf.org/html/rfc8314) by exposing POP3S/IMAPS/SMTPS.
We believe docker-mailserver's default configuration to be a good middle ground: it goes slightly beyond "old" (1999) [RFC 2487](https://tools.ietf.org/html/rfc2487); and with developper-friendly configuration settings, it makes it pretty easy to abide by the "newest" (2018) [RFC 8314](https://tools.ietf.org/html/rfc8314).
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.
Eventually, it is up to _you_ deciding exactly what kind of transportation/encryption to use and/or enforce, and to customize your instance accordingly (with looser or stricter security).
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.