Allow custom paths for certificates

[bcardiff]

With this changes using external certificates files is simplified.

The environment variables CERTIFICATE_PUBLIC and CERTIFICATE_PRIVATE defines the path. The treatment of the certificate has not changed, ie: they will be generated as self signed if the files do not exist.

With those variables the user is able to mount the certificates at any place. The integration with letsencrypt wont need a copy step that bothers when the certificate needs to be renewed (every 3 months). Using a symlink could be used as a workaround for sure, but in some scenarios where the access to the host is not available it's a bit problematic.

A dependency to https://github.com/jwilder/dockerize is added to expand the configuration file template to the actual configuration on start up. It's a handy mechanism in many docker images. It could be changed to something simpler, but it works neat. In the expansion of the template the -no-overwrite helps the user to tweak manually the file if needed.

[bcardiff]

@nelfer you might like this change if you still use the container.

[bcardiff]

Hi, @zixia I exposed some concerns regarding your requested changes. Let me know if those thoughts make sense to you.

[huan]

Hi @bcardiff, sorry for my late reply because I'm kind of busy these days.

Before the reply, I think it's better to share my ideas of why I create this SMF project.

The goal of SMF project is to make setting up an email forwarder server death easy, as easy as to just set one environment variable and only set one.

This variable is named SMF_CONFIG. I use an env var instead of a config file is because:

1. I want a fileless mode, so I can run the container at any Docker host server, without the care of any local files.
2. The environment variable can be easily set on Docker Cloud, which is very convenient to use.

When we want to support SSL, it's better to just update the certificate files from letsencrypt inside the container right after start, and renew it inside the container, without any additional settings from us.

Now if we want to support the custom certificate files, I'm ok with adding the additional environment variables, however, I'd like to keep the fileless mode, we'd better not support a file path in the environment variable because that would break the fileless mode and make the SMF becomes complicated.

At last, I believe we have to trust the docker cloud service if we are using it because it has the root privileges of our docker host, and certainly, they can read any of the data in our containers without any difficulty.

[bcardiff]

No worries for the delay @zixia .

I understand the original idea of SMF and to be fileless. With this PR that changes slightly due to the expansion of the config file (yet the email queue is also stored in files).

Regarding the usage of letsencrypt or other tool generate/renew the certificate automatically, precisely I think this changes are ideal for that. Either in docker cloud or rancher I've used certbot or other docker images with letsencrypt with a mounted volume to store the certificate. The letsencrypt image decides the naming of the final files. So with this PR one is able to mount the same shared volume and specify where to look those certificate files.

I don't fully understand how you would use the letsencrypt image in other way without user intervention upon certificate renewal.

If you still think the edition of the certifcate content is mandatory to accept the PR and cannot be deferred, lets discus the design since is not something I would actually use (I proposed one here)

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}