Several comments were removed since they are not worth the trouble.
A few minor issues were addressed.
Most of remaining comments got corresponding GitHub issues assigned.
With new authorization/authentication identities split, it is possible
to have non-email authentication identity while using email authorization
identity.
The authentication provider can now provide multiple authorization
identities associated with credentials. Protocols that support that
(e.g. JMAP, SASL) can let the client select the wanted identity.
This makes server more aggressive in retrying delivery. The total
attempts time is approximately the same (around 5 days).
Notably, the increased amount of attempts is needed to handle large
recipient lists where the remote server sometimes rejects subset of them
with "Too Many Recipients" code.
See #149.
While was not strictly needed before, it is necessary in the presence of
limits and other internal target errors that should cause the delivery
to get rescheduled without increasing retries counter.
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.
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.
