New script build.sh is much more suitable for downstream packaging
(e.g. ./build.sh package) than hacked together package.sh wrapper for
get.sh while still being usable for "effort-less" installation.
Additionally, hostname setting in get.sh is flawed in many ways and is
not reimplemented in build.sh.
build.sh has proper command line options that allow to customize build
configuration and installation prefixes.
Documentation page get.sh is removed since all applicable environment
variables and flags are documented in ./build.sh --help.
build.sh can be called from the source directory to build maddy from
*this* source instead of forced 'go get' that was used in get.sh.
However, if build.sh is called not from the source directory, it clones
the repo and (optionally) uses the specified commit. This keeps build.sh
usable in curl|bash commands.
Due to the way source code is fetched, build.sh uses Git tags instead of
Go module versions as get.sh did.
It is only a good thing to use for simple stateless daemons. It is
possible to use StateDirectory to store state, but it is extremely
limited. Notably, only service processes and root can correctly access
the state directory. This makes up for a bad practice to run maddyctl as
root what in turn screws up permissions on files in messages directory
when imap-* subcommands are used.
Migration note: Users of systemd unit with DynamicUser enabled should
move /var/lib/private/maddy to /var/lib/maddy before starting maddy
after update.
Use of inotify and possibly other mechanisms poses portability risks.
Notably, "cross-platform" abstractions such as fsnotify library remove
access to certain features that are important to use it correctly in
some cases e.g. it is preferable to listen only for IN_CLOSE_WRITE on
Linux instead of IN_MODIFY to prevent races and unexpected failures.
Pooling approach avoids such problems by either running reload code at a
different time than actual renewal or retrying later if parse fails.
With certificates being renewed before expiry (e.g. 1 week before) delay
is not a signficiant problem.
Closes#160.
DANE is complex and requires its own (potentially lengthy) tutorial on
how to configure it properly. MTA-STS, on the other hand, is designed to
be simple to deploy so recommend to configure it in the Setting up
tutorial.
In some cases, such usage may be desired but it is not supported by the
default maddy configuration for security reasons.
This page replaces examples/remote-aliases.conf example as it provides a
much more detailed explanation.
