Set of flow restrictions is represented as a "limits" module instance
that can be either created inline via "limits" directive in some modules
(including "remote" target and "smtp" endpoint) or defined globally and
referenced in configuration of modules mentioned above.
This permits a variety of use cases, including shared and separate
counters for various endpoints and also "modules group" style sharing
described in #195.
Allows pipeline routing to be used in places where a regular target is
required. Also allows to share parts of pipeline configurations on the
semantical level (instead of lexical level as it goes with config
snippets), see #195.
It is pretty much not that simple as e.g WildDuck and not at all magical
like caddy.
It is (going to be) as powerful as Postfix & Dovecot combo. Except that
it is not tainted by 20 years of maintaining compatibility while adding
features, not tainted by defaults that were reasonable two decades ago
and so on.
maddy is locking in users by using a custom storage format, though. So
saying "GTFO, use a different server if you need that" is not a very
reasonable path to take.
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.
This commit replaces two variants borrowed from caddy with {env:name}
syntax that is consistent with value placeholder syntax used in several
other places in maddy.
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.
maddy(1) was incorrect calling them 'statedir' and 'runtimedir'.
Name with 'dir' is preferred since it is more explicit. Use of
underscores is consistent with other directives.
Similar to global scoring system that was removed before, but works only
for DNSBL. It is simplier and only actually useful for BLs, since
rejecting/quarantining messages based on a single listing is usually bad
idea and leads to a high false positives rate.
Previous approach consisted of multiple independent options with unknown
interaction between each other and not offering enough flexibility for
local policy configuration.
Additionally, it was not possible to implement downgrade protection
mentioned in #178 because it was not clear what is "downgrade" since
options were not related in any linear order, this commit makes it
explicit via the "security levels" system:
MX: DNSSEC > MTA-STS > Nothing
TLS: Authenticated+Encrypted > Encrypted > Plaintext
Note DNSSEC and MTA-STS being different levels, they provide different
security guarantees. Keeping them together under "authenticated" level
would not provide enough granularity for levels-based downgrade
protection and local policies.
'common_domain' MX authentication option is removed. It was offering no
real protection and therefore is was problematic to use together with
planned downgrade protection.
All security level errors are marked as temporary to force requeueing
and allow local admin to troubleshoot them without losing messages.
'remote' tests are changed to use testTarget function to initialize
tested module instance, since security levels mapping requires some
pre-initialization.
Support for IP literals in address domain-part is disabled because it
is incompatible with the new verification logic and was broken anyway
(#176).
Allow to override DNS resolver address via the -debug.dnsoverride flag
and SMTP port via -debug.smtpport.
All flags are not available unless maddy is built using the 'debugflags'
tag.
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.
