mirror of
https://github.com/Mailu/Mailu.git
synced 2024-12-12 10:45:38 +02:00
71 lines
2.9 KiB
ReStructuredText
71 lines
2.9 KiB
ReStructuredText
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
|
|
-----------------------
|
|
|
|
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
|
|
[Setup your DNS](dns).
|
|
|
|
Pick a Mailu version
|
|
--------------------
|
|
|
|
Mailu is shipped in multiple versions.
|
|
|
|
- ``stable`` is the default version and features a stable server, it gets bugfixes
|
|
and patches but features are included every month or so after a couple weeks of
|
|
testing. This is the default setting and should match most requirements.
|
|
|
|
- ``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 `mailradar`_
|
|
to ensure you're not contributing to the spam problem on the internet.
|
|
All tests there should result in "Relay denied".
|
|
- 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.
|
|
|
|
.. _mailradar: http://www.mailradar.com/openrelay/
|