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.
For user convenience, we permit both A-labels and U-labels in
configuration and convert them to U-labels for internal use.
Domains in configuration that can't be converted to U-labels form for
whatever reason are rejected as a configuration error.
This effectively means that it is not possible to specify different
handling for A-labels domain and U-labels domain, but it should not be a
problem in practice.
Some parts were implemented in msgpipeline package poorly hooked to some
bits in check/dmarc. Now it is fully in check/dmarc and pipeline code
simply calls two functions.
Also I took that chance to add proper documentation to check/dmarc with
the intention to contribute some parts to the go-msgauth library later.
There was a poor assumption that textproto.Header is just a fancy
wrapper around map[string][]string so passing it around by value and
modifying it could work fine, but it broke terribly due to a change in
Header structure.
since the endpoint/smtp initialization is rather complex, tests use
New+Init instead of creating the Endpoint object directly like it is
done for target/queue and target/remote. This requires a couple of
tricks to create a valid configuration tree for it. This is the reason
dummy module was moved into 'module' package, this wasy it can be
registered and then referenced by the Init code when reading the
configuration.
A small problem was found and fixed in go-mockdns along the way.
Rules to be generally followed are outlined in HACKING.md (section
Error handling) and in exterrors package documentation.
exterrors.SMTPError is extended with type-safe fields commonly added
using 'arbitrary context' WithFields function.
Most of "reason" field uses are err.Error(), so do that by default
using the Err field.
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.
Mostly used for checks that indicate 'obviously malicious' clients so it
is preferable to immediately reject all commands without session
initialization and running other checks.
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.
It fits poorly with limited amount of checks that are (and will be)
implemented in maddy.
Advanced filtering that requires "spam score" logic should be performed
by external software such as rspamd. At this point duplicating that
logic in maddy makes no sense, since it is highly problematic to
integrate it with external software.
New name more precisely describes what it is doing now. It was initally
meant to be more generic and usable for other purposes, but I don't
think we will need that flexibility.
