Mailu/docs/setup.rst

Setup a new Mailu server
========================

Things to consider
------------------

Mailu is working, it has been powering hundreds of e-mail accounts
since around January 2016, and has delivered over a million emails.
It is still not massively tested however and
you should not run any critical mail server until you have properly tested
every feature.

Also, the idea behind Mailu is based on the work by folks from Poste.io.
If free software is not the reason you chose Mailu or if you are seeking
long-term professional support, you should probably turn to them instead.

Prepare the environment
-----------------------

Mailu images are designed to work on x86 or equivalent hardware, so it
should run on pretty much any cloud server as long as enough power is
provided. If you find yourself running Mailu on small hardware, e.g.
Raspberry Pi or other platforms based on ARM, you will probably find
some support from `MFAshby's fork`_.

You are free to choose any operating system that runs Docker (>= 1.11),
then chose between various flavors including Docker Compose, Kubernetes
and Rancher.

Compose is the most tested flavor and should be used by any unexperimented
user. Make sure you complete the requirements for the flavor you chose.

You should also have at least a DNS hostname and a DNS name for receiving
emails. Some instructions are provided on the matter in the article
:ref:`dns_setup`.

.. _`MFAshby's fork`: https://github.com/MFAshby/Mailu

Pick a Mailu version
--------------------

Mailu is shipped in multiple versions.

- ``1.5`` features the most recent stable version for Mailu. This is the
  recommended build for new setups, old setups should migrate when possible.

- ``1.0``, ``1.1``, and other version branches feature old versions of Mailu
  they will not receive any more patches (except for the stable one) and you should
  not remain forever on one of those branches; you could however setup the stable
  branch by number to avoid introducing unexpected new feature until you read the
  changelog properly. This is the most conservative option.

- ``latest`` points at the latest build from the master
  development branch. It will most likely contain many more bugs, also you should
  never use it for a production server. You are more than welcome to run a testing
  server however and report bugs.

Perform the specific setup steps
--------------------------------

Specific setup steps are described per flavor (Compose, Kubernetes, etc.)
and you should follow the steps after completing the requirements.

Make sure that you test properly before going live!

- Try to send an email to an external service
- On the external service, verify that DKIM and SPF are listed as passing
- Try to receive an email from an external service
- Check the logs (``docker-compose logs -f servicenamehere``) to look for
  warnings or errors
- Use an open relay checker like `mxtoolbox`_
  to ensure you're not contributing to the spam problem on the internet.
- If using DMARC, be sure to check the reports you get to verify that legitimate
  email is getting through and forgeries are being properly blocked.

  .. _mxtoolbox: https://mxtoolbox.com/diagnostic.aspx