From 20d1eb4b5075d7e7c8ff74cecba1ce0558852988 Mon Sep 17 00:00:00 2001 From: Jean-Denis Vauguet Date: Fri, 12 Jun 2020 06:36:30 +0200 Subject: [PATCH] Updated A mail server's 101 (markdown) --- docs/content/a-mail-server's-101.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/a-mail-server's-101.md b/docs/content/a-mail-server's-101.md index d174027c..d7200e14 100644 --- a/docs/content/a-mail-server's-101.md +++ b/docs/content/a-mail-server's-101.md @@ -116,7 +116,7 @@ The best practice as of 2020 would be to handle emails Submission using an _Impl 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. +In many implementations, the mail server doesn't enforce TLS encryption, for backwards compatibility. Clients are thus free to deny the TLS-upgrade proposal (or [misled by a hacker](https://certified-senders.org/wp-content/uploads/2020/02/Email-Transport-Encryption-STARTTLS-vs.-DANE-vs.-MTA-STS_updated.pdf) about STARTTLS not being available), 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.