Exim config file refactoring

[rimas-kudelis]

I have downloaded the current default configuration file from Exim git repo, and am currently trying to merge in our specifics, reviewing it and getting rid of some unnecessary stuff at the same time.

I have another (alternative) idea as well though: we could split our config file into more chunks and and use more .include statements, although according to the documentation, such files would be read more often than is necessary, which is probably why Debian doesn't use split config at runtime, but instead concats all files into a single one under /var/lib/exim4/.

[rimas-kudelis]

First thing I've stumbled upon:

# Uncomment the next line if you want to be able to authenticate over unsecure
# connections (without using SSL or TLS). Note that this is highly discouraged!
#AUTH_SERVER_ALLOW_NOTLS_PASSWORDS = true

I think we should drop support for this. This is absolutely discouraged. Why would we keep this feature?

[Udera]

First thing I've stumbled upon:

# Uncomment the next line if you want to be able to authenticate over unsecure
# connections (without using SSL or TLS). Note that this is highly discouraged!
#AUTH_SERVER_ALLOW_NOTLS_PASSWORDS = true

I wanted to keep that for the first migration. There might be still some clients that haven't switched so you can easily change that back. I had the problem with some clients on routers or copy machines who can't really handle TLS (or only very old, unsecure ciphers). Most of them can do it with firmware upgrades. For one exception, I use a different port where they can send mails over unencrypted connections (not sure if we should provide any documentation of this or only on request).

After the transition from vexim2.2 -> vexim2.3, we can remove this option in future releases.

[rimas-kudelis]

I see.

Possible workaround: adding the IP addresses of these copy machines as relay hosts. If these machines are in a private network, either have a network interface in that network as well, or set up a "proxying" SMTP server to serve just these copy machines

[Udera]

I see.

Possible workaround: adding the IP addresses of these copy machines as relay hosts. If these machines are in a private network, either have a network interface in that network as well, or set up a "proxying" SMTP server to serve just these copy machines

There could be some routers which send reports as well. With fixed IP this is not problem but often dynamic ips are used (you can of course restrict the ip range as well). To relay mails with a tls-compatible service is the cleanest solution but you need an extra device for that.

[rimas-kudelis]

We could point them to a Raspberry Pi shop. 😄

[Udera]

I'm not a huge fan of these splitted configuration files. Especially
that you have to regenerate the configuration file after changes, is not
very handy.

A nice thing is to keep the parts that need to be edited by the user
together, either in a separate file or at the beginning of the
config-file. I have even seen a webinterface (don't remember which one)
that generated the config-files itself depending on the system.

If it is only to get the debian-config thing automated, we could also
comment break-points in the config file where the specific
conf.d/*-files are extracted.

On 2016-08-30 19:39, Rimas Kudelis wrote:

I have downloaded the current default configuration file from Exim git
repo, and am currently trying to merge in our specifics, reviewing it
and getting rid of some unnecessary stuff at the same time.

I have another (alternative) idea as well though: we could split our
config file into more chunks and and use more .include statements,
although according to the documentation, such files would be read more
often than is necessary, which is probably why Debian doesn't use
split config at runtime, but instead concats all files into a single
one under /var/lib/exim4/.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1] #210
[2]
https://github.com/notifications/unsubscribe-auth/AGCFFGFdIezuEXFDzVxfkg-gD9huXNpjks5qlGq3gaJpZM4JwyN6

[rimas-kudelis]

Regarding split config: I thought it might be easier to manage such files. But I'm OK with leaving it as a single file as well.

Regarding AUTH_SERVER_ALLOW_NOTLS_PASSWORDS: let's move this discussion to #217.

[rimas-kudelis]

Another batch of lines I don't like:

tls_dhparam = /etc/exim4/dhparam.pem

# A list of secure ciphers for GnuTLS which is used in Debian/Ubuntu
tls_require_ciphers = ${if =={$received_port}{25}\
    {NORMAL:%COMPAT:-ARCFOUR-128:-ARCFOUR-40:-MD5:-VERS-SSL3.0}\
    {SECURE128:+AES-256-CBC:+CAMELLIA-256-CBC:-ARCFOUR-128:-ARCFOUR-40:-MD5:-VERS-SSL3.0}}

# If OpenSSL is used (CentOS, FreeBSD), comment the previous block (tls_require_ciphers)
# and uncomment the following line
# openssl_options = +all +no_sslv2 +no_sslv3 +no_compression +cipher_server_preference

Honestly, the discussion in #45 hasn't convinced me that we should do this. Like I said previously, I believe this should be done by distribution vendors and if they don't do this, administrators themselves. The ciphers that are "secure" by todays standards won't necessarily be seen as such tomorrow, and we will surely not be releasing "hotfix versions" of Vexim just to updated the cipher list.

I suggest we consistently follow the advice from BetterCrypto instead of reinventing our own wheel and cluttering our configuration files with lists of ciphers for GnuTLS and options for OpenSSL, which then have to be enabled/disabled depending on what you use. And here's what BetterCrypto has to say:

It is not advisable to restrict the default cipher list for opportunistic encryption as used by SMTP. Do not use cipher lists recommended for HTTPS! If you still want to define one please consult the Exim documentation or ask on the exim-users mailinglist.

Interestingly though, they don't mind restricting the list for Dovecot and other servers. Maybe we could just point our users to BetterCrypto?

[Udera]

Like I said previously, I believe this should be done by distribution vendors and if they don't do this, administrators themselves.

Which distribution does it at all? It seems to me that they mostly configure it to run as a default local mailserver, which can perhaps forward some mails to other mail servers. Neither the default debian nor the FreeBSD settings have anything where you can specify the ciphers. We want people to use TLS and do enforce it for authenticated connections. And which part of the debian-config would you actually copy at what place in the config? Or don't specify the ciphers at all and hope the system will use some standard values?

For this postfix solutions, they give recommendations:
http://arstechnica.com/information-technology/2014/03/taking-e-mail-back-part-2-arming-your-server-with-postfix-dovecot/3/
https://github.com/mail-in-a-box/mailinabox

We are no encryption experts but with the settings in place I find it much easier to update the current settings with the latest recommendations from linked sources.

[rimas-kudelis]

Which distribution does it at all? It seems to me that they mostly configure it to run as a default local mailserver, which can perhaps forward some mails to other mail servers. Neither the default debian nor the FreeBSD settings have anything where you can specify the ciphers. We want people to use TLS and do enforce it for authenticated connections. And which part of the debian-config would you actually copy at what place in the config? Or don't specify the ciphers at all and hope the system will use some standard values?

I'm talking about ciphers only. Shipping standard values (no manual selection) seems fine by me. I don't expect many admins to keep upgrading Vexim, but not the underlying OS it runs on, and if that assumption is correct, then whatever ciphers we specify in the config today will stay there until the next server upgrade, and some of these ciphers might "become" insecure along the run, yet our changes in the repository won't matter. On the other hand, ciphers that are considered insecure at the time of OS release will most likely be disabled by the OS vendor in that release already.

For this postfix solutions, they give recommendations:
http://arstechnica.com/information-technology/2014/03/taking-e-mail-back-part-2-arming-your-server-with-postfix-dovecot/3/
https://github.com/mail-in-a-box/mailinabox

I see a big difference between smtp_tls_ciphers = high (mentioned in the arstechnica article) and tls_require_ciphers = SECURE128:+AES-256-CBC:+CAMELLIA-256-CBC:-ARCFOUR-128:-ARCFOUR-40:-MD5:-VERS-SSL3.0, the latter being just half of our GnuTLS-specific setting.

We are no encryption experts but with the settings in place I find it much easier to update the current settings with the latest recommendations from linked sources.

It certainly is, I just don't think that approach is maintainable. On the other hand, we can keep these settings and see whether that's true or not.

[Udera]

With openssl compiled, you could use tls_require_ciphers as well:
tls_require_ciphers = HIGH:!SSLv2:!SSLv3
But this is not compatible with GnuTLS. It would be nice to automatically detect, if the system uses GnuTLS or openssl.

We could remove the different cipher settings for port 25 and other ports. Over the last years, most mail providers switched to encrypted connections and reviewed their encryption settings. On my server, most connections use TLSv1.2.