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.
As noted in maddy-filters(5), action 'ignore' is useful for testing of
new checks without actually enforcing them. Though, it is essentially
useless without the ability to see check results.
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.
Relaxed alignment is defined by RFC 7489 as equality of eTLD+1 of
checked identifier and eTLD+1 or the RFC5322.From domain. For example,
sub1.example.org and sub2.example.org are in alignment. Strict alignment
requires the exact equality of identifiers. In both cases, the use of eTLD+1
instead of the domain itself can lead to false failures.
Hence, EvaluateAlignment function now accepts RFC5322.From domain instead of
Organizational Domain (eTLD+1).
For quarantined messsages, the Authentication-Results header provides
all information necessary for troubleshooting. When the message is
rejected altogether, there is no information other than opaque 'DMARC
check failed'. With this commit, log message will contain information
about DKIM and SPF checks status and corresponding identifiers.
applyResults modifies the header while FetchRecord (running in parallel
calls extractDomains that reads it.
Additionally, another race condition was caused by go-mockdns not
copying the slice before returning, that was addressed upstream:
* ed42e5b Copy slice before returning it from Lookup*
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.
This includes: queue dispatch, check runner and some checks (only SPF
atm) doing various stuff in parallel to the main delivery flow.
Queue panic handler drops the message that caused the panic from queue
to avoid further errors. It is assumed that most panics are caused due
to corruption of per-message state, so it is possible to reasonably
recover from it by stopping attempts to handle the problematic message.
NDN is not generated in this case, since it could cause interaction with
the state of a possibly corrupted message. This could change in the
future, as per RFC 5321 the server "MUST NOT lose the message for frivolous
reasons".
Additionally, when panic causes SMTP-time rejection, the server returns
a 4xx code, essentially deferring the message instead of dropping it.
That's the safety net for cases where panic is caused by a transient
problem (e.g. a race condition).
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.
Old code was marking alignment check as 'passing' without actual
authentication of the used identifier since we don't implement SPF (see
#91 for related discussion).
This commit effectively disables SPF alignment completely. Relevant code
is still here, though, if we will change decision on SPF support in the
future.
DMARC (RFC 7489) does not require support of both authentication
mechanisms.
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.
2019-10-13 18:42:51 +03:00
Renamed from dispatcher/check_runner.go (Browse further)
