1. Clarify that you need to manually create the user and group
when building from source. ./build.sh does not do that since
it is a packaging tool, not system configuration one.
2. Do not require "go" command to be present when running
./build.sh install. go installation may be user-specific and
unavailable when running with sudo.
3. Ease UMask restrictions. Allow group access.
This allows CLI commands to be run by any user in maddy group.
See #569.
This increases the isolation of Maddy service. Maddy capabilities can be
bound to only CAP_NET_BIND_SERVICE. This also restricts the service to
only use Unix sockets, IPv4 and IPv6.
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.
The intention is to keep to repo root clean while the list of packages
is slowly growing.
Additionally, a bunch of small (~30 LoC) files in the repo root is
merged into a single maddy.go file, for the same reason.
Most of the internal code is moved into the internal/ directory. Go
toolchain will make it impossible to import these packages from external
applications.
Some packages are renamed and moved into the pkg/ directory in the root.
According to https://github.com/golang-standards/project-layout this is
the de-facto standard to place "library code that's ok to use by
external applications" in.
To clearly define the purpose of top-level directories, README.md files
are added to each.
We don't want to clutter /usr/bin/ with internal helpers, do we?
On start-up, the libexec directory is added to the PATH environment
variale. This allows reusing exec.LookPath logic, notably, to check
whether the script is executable.
It is separate from the PREFIX variable which specifies the path use
*within* the system tree whereas DESTDIR specifies the path to the
system tree itself. For get.sh-based installation, DESTDIR=""
PREFIX=/usr/local. For package.sh DESTDIR is a temporary directory and
PREFIx=/usr.
With that change it is now possible to set the default libexec directory
to a correct value depending on the PREFIX variable.
It has all sorts of benefits due to the service manager being aware of
the starting/running/stopping state, see systemd.service(5)
On top of that, start-up errors are reported using STATUS= key, so they
will be easier to see in the 'systemctl status' output.
The user is generally expected to be aware of its existence before using
it. Notably, the default fail2ban installation does not have any jails
enabled, so follow that convention.
These files specify handling behavior only for local authentication.
Separate configurations will be added for filtering on other conditions
(such as email address dictonary attack).
Typically, bots messing with email servers do so for quite a lot of time
before stopping attempts so it makes sense to ban them for longer than the
system default (e.g. 10 minutes on Debian). 96 hours (4 days) seems to
be a reasonable compromise between size of the fail2ban DB and ban
usefulness.
filter.d/maddy.conf was using old message format.
Additionally, jail.d/maddy.conf now specifies backend = systemd which
matches the standard configuration with maddy logging to
systemd-journald.
Despite being incomplete, it can be still be useful and provide
protection for users.
The missing part is the report generation, which is defined as a part of
a minimal implementation by RFC 7489, though.
-- Problem
The way module references are implemented was a big source of confusion,
mainly because in most cases there are at least two possible ways they
are handled. Additionally, for some modules (checks and modifiers) there
is the third way, what doesn't help either.
Consider the following cases of confiugraiton directives:
```
deliver_to smtp_downstream
```
This directive refers to the existing configuration block named
smtp_downstream. It doesn't have to be the instance of the
smtp_downstream module, though.
```
deliver_to smtp_downstream tcp://127.0.0.1:1125
```
This magically turns "reference to an existing block" into an inline
definition. And suddenly the first argument is not an configuration
block name, now it is a module name. Same "sudden" change happens when
the block is added:
```
deliver_to smtp_downstream { ... }
```
For modules having an "implicitly defined" config block, there's
another source of confusion:
```
deliver_to smtp_downstream
```
This directive may refere to the implicitly defined config block with
some default values. But to the user it looks like a module name and
nothing more. It's trickly to explain all dark corners of such behavior
in the user documentation.
Even more, there's another problem with the implementation, these
implicitly defined blocks can't access global directives because they
are defined before the configuration is parsed.
-- Solution
This commit removes the third way of module reference handling. There
are no "implicitly defined" config blocks anymore.
Second, all module references by default create a new module instance.
All following directives create a new module instance, no catches here.
```
deliver_to smtp_downstream
deliver_to smtp_downstream tcp://127.0.0.1:2525
deliver_to smtp_downstream { ... }
```
Although, the first one will fail because smtp_downstream needs at least
one endpoint address somewhere.
Ability to define configuration blocks at a top-level and reference them
in other places is retained for use in cases where it's actually
useful, including the initial idea of "state sharing" (see "Dev:
Comments on design" on the project wiki).
However, such referneces are now explicitly prefixed by the '&'
character. Such as the following:
```
deliver_to &smtp_downstream
```
This directive references the existing configuration block named
"smtp_downstream". Following directives are not allowed as they make no
sense:
```
deliver_to &smtp_downstream tcp://127.0.0.1:2525
deliver_to &smtp_downstream { ... }
```
So, there is no confusion about what happens when.
Closes#167. I decided to not make any radical changes now. Changes
made to the initialization logic solve the actual problem that led to
the creation of the referenced issue.
This allows for some complex but useful configurations, such as making
decision on delivery target based on the result of per-destination
address rewriting. One example where that can be useful is aliasing
local address to a remote address in a way that can't make the server
an open relay.
Previous error reporting code was inconsistent in terms of what is
logged, when and by whom. This caused several problems such as: logs
missing important error context, duplicated error messages, too verbose
messages, etc.
Instead of logging all generated errors, module should log
only errors it 'handles' somehow and does not simply pass it to the
caller. This removes duplication, however, also it removes context
information. To fix this, exterrors package was extended to provide
utilities for error wrapping. These utilities provide ability to
'attach' arbitrary key-value ('fields') pairs to any error object while
preserving the original value (using to Go 1.13 error handling
primitives).
In additional to solving problems described above this commit makes logs
machine-readable, creating the possibility for automated analysis.
Three new functions were added to the Logger object, providing
loosely-typed structured logging. However, they do not completely
replace plain logging and are used only where they are useful (to allow
automated analysis of message processing logs).
So, basically, instead of being logged god knows where and when,
all context information is attached to the error object and then it is
passed up until it is handled somewhere, at this point it is logged
together with all context information and then discarded.
