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-10 00:04:34 +02:00
parent b2d8f1b338
commit 645a9c63f2
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -38,7 +38,7 @@ For both Postfix and Dovecot need to be accessible from the outside to act as se
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.
**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). That SMTPS setup uses port 465 and _Implicit_ (aka. enforced) TLS encryption.
**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.
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.