For Better or For Worse: Proposed mail infrastructure changes

For Better or For Worse: Proposed mail infrastructure changes

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 4543 bytes --]

Hello infrastructure team,
hello development list,

for various reasons, I would like to propose some changes
to the mail infrastructure of ipfire.org . Since some of them
will affect MUA settings for people who have a mail account
at this domain, I am trying to announce this as broadly as
possible.

(1) Separate Mailman VM from MX VM
Currently, _any_ mail traffic related to the project is handled
by mail01.ipfire.org, including the mailing lists. Especially
for the latter, it is difficult to determine the origin of
a message which is why things like ARC signing are currently
not working.

This can be solved by moving Mailman to another VM, which
should not have any direct user impact at all. Michael agreed to
this and prepared some infrastructure - thank you.


(2) Use dedicated IMAP/Submission DNS labels for MUAs
mail01.ipfire.org is the hardcoded FQDN for sending and
receiving mails via a MUA. This has been grown over time,
and while there is no need to change something for technical
reasons here, separating MUA labels from MX hosts and actual
machine FQDNs is BCP.

I propose
	submissions.ipfire.org		as FQDN for authenticated mail submission and
	imaps.ipfire.org		as FQDN for IMAP access.


(3) RFC 8314 deprecates explicit TLS connections for MUA connections
Currently, we use explicit TLS (aka STARTTLS for most protocols)
for both submitting and retrieving messages. There are a number
of reasons why this is deprecated, primarily being plaintext
traffic prior to encryption.

I propose to use implicit TLS only on port 465 (submissions)
and 993 (IMAPS) and discontinue support for explicit TLS channels,
and POP3 in general.


(3) Use only AEAD ciphers for authenticated TLS connections
As mentioned in a patch the other day, CBC ciphers have some
known vulnerabilities and should be avoided. Since we require
TLS 1.2 for nearly all TLS services already, enforcing GCM/AEAD
ciphers should not break too much.

As far as I am concerned,
	openssl ciphers -v 'ECDHE+AESGCM:ECDHE+CHACHA20:@STRENGTH'
provides a set of secure and fast ciphers suitable for modern
TLS connections - talking about HTTPS here as well. These are
as follows:

TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD

This cipher policy will be active on the ports mentioned in (3),
and hopefully for our websites some day as well. In case any
setup is known to break with this change, please let me know.


(4) Moving to DMARC reject policy
In case ARC signing is sufficiently working after (1), changing
our DMARC policy to "reject" makes sense to me. There is little
to no legitimate mail traffic from other MXs than mail01.ipfire.org.

Mail forwardings are a known exception to this, and since they
happen on some other systems, we cannot do anything in favour
or against it.


(5) postmaster.ipfire.org
We have a defined Acceptable Use Policy for both receiving and
sending mail without authentication. However, it is not documented
for the public, yet, and there have been some questions and/or
complaints about it in the past.

Setting up a dedicated website containing this policy (probably
a read-only wiki page) might help here, but should not have
serious technical impact.


According to the current state and local knowledge, no other bigger
infrastructure changes are necessary in medium terms. If the ones
above will be approved, I plan to shut down legacy MUA ports if
everybody adjusted his configuration or at the 1st December 2019
(whichever comes first).

I will be happy to answer questions or comments.

Thanks, and best regards,
Peter Müller

P.S.: If anyone asks: The subject phrase refers to the comic
strip written by Lynn Johnston. :-)
-- 
The road to Hades is easy to travel.
	-- Bion of Borysthenes