This is a simple documentation update to notify users that UIDs/GIDs may
(and in fact are) different across distros.
The documentation now reflects the last known state od UIDs/GIDs.
Startup now announces specific UIDs/GIDs used to make sure people are
aware of any future changes.
This is a really dirt fix for issue #180. It will replace "well-known"
enumerated plugin names with SASL mechanism names. While this is more of
a "bandage" than the actual proper fix, I have currently found no better
ways to do it.
Most likely this issue will rise up again with another SASL plugin and
we will deal with it then. At this stage, it should cover most of the
use cases transparently.
So, according to the documentation, usernames must always include a
domain for SASL.
In other words. User cannot be `johhny` but `johhny@example.org`.
Further info can be found on this ticket: https://github.com/bokysan/docker-postfix/issues/192
This commit will automatically append domain if one is not provided in
`SMTPD_SASL_USERS`.
We encountered an issue where the script common-run.sh would fail if the SMTPD_SASL_USERS environment variable was defined. The failure occurred immediately after displaying the "Enable smtpd sasl auth" message, preventing the container from starting correctly.
The root cause was traced to a conditional check for the existence of the /etc/sasl2/sasldb2 file. When the file did not exist, the subsequent `chown` operation was skipped as intended, but the script would still fail due to an undefined behavior in the shell context.
The addition of a debug message "Sasldb configured" before the closing `fi` statement has resolved the issue. This change appears to stabilize the script execution, allowing the container to start as expected.
While the underlying cause is not fully understood and warrants further investigation, this commit serves as a temporary workaround to ensure functionality in environments where SMTPD_SASL_USERS is set.
This image will now automatically reconfigure `daemon_directory` in case
of distrubution switching.
Alpine and Debian/Ubuntu will use different directly layout and if the
user persists `/etc/postfix`, this image will not start if the
distribution changes.
This will change the `deamon_directory` if it detects a distribution
change. Some distributions will by default set the `deamon_directory` in
`main.cf` and they differentiate between distributions. Hence, updating
to another distribution causes Postfix to fail starting.
A small error where sed was called wrongly ('s/.../d') instead of
'/.../d' was causing an error `sed: unmatched '/' on configuration
change`.
This commit should fix the issue.
This new feature will anonymize emails in the Postfix logs. This allows
you to keep them indefinetely while being compliant with GDPR.
Based on excellent work on [this pull request](https://github.com/bokysan/docker-postfix/pull/91).
Check `README.md` for more details.
With upgrade to Alpine 3.13, support for `hash:` and `btree:` has
beenremoved from Alpine.
As such `hash:<file>` references do not work any more.
[Alpine](https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0)
explains it like this:
> Oracle has changed the license of BDB to AGPL-3.0, making it unsuitable
> to link to packages with GPL-incompatible licenses. Since the old version
> is no longer maintained, the db package is now deprecated. Alpine Linux
> packages are being transitioned to alternatives or, where no alternatives
> exist, removed entirely.
This, unfortunately, will mean that the new version of `docker-postfix`
might not be backwards-compatible, if you're using your own postfix
configuration. Sorry. :-(
The postfix configuration was a bit too permissive with `mynetworks`.
This commit:
- adds `reject` at the end of `*restrictions` list
- adds tests for this feature
Private keys generated with `DKIM_AUTOGENERATE` were created with
the root account and as such were not readable by OpenDKIM.
This fix will reown the created files to the `opendkim` user.
While quite annoying behavour, this is the how `postconf` works.
If you tell it to comment out a command, it will add it to the config
even when the same command exists commented out in the config file.
This commit does a bit of sed and grep magic to find if the comment
already exists and if yes, then it does nothing.
- It's now possible to choose the logging type - either 'plain' or
'json'
- The code is ready to support multiple integration tests (with
different configurations)
- `OPENDKIM_` and `POSTFIX_` variables are handled properly and recorded
in the corresponding files. (This had a downfall that `bash` now needs
to be installed, so we can probably simplify some of the shell
scripts.)
Summary
^^^^^^^
This commit refactors the code base to be more manageble and
prepares the groundwork for tests.
Refactoring
^^^^^^^^^^^
Files are now moved to subdirectories, all for the sole purpose of
easier management. Tests live in their own folders, as well as configs
and other files.
Test framework
^^^^^^^^^^^^^^
Two new important scripts/directories are available:
- `unit-tests.sh` / `/unit-test` which executes unit tests across shell
scripts, and
- `integration-test.sh` / `integration-tests`, which spins up the
container and tries to send the email.
Both tests use the [BATS](https://github.com/sstephenson/bats) framework
for testing. To create a new test, simply drop a `.bats` file into a
corresponding directory.
Functions have been extracted into `common-run.sh`, to be able to test
them independently.
DKIM_SELECTOR
^^^^^^^^^^^^^
It is now possible to specify a DKIM selector to use (instead of
the default "mail"). See `README.md` for more details.
JSON logging
^^^^^^^^^^^^
WIP: rsyslog will now output JSON logs. This is especially important
if you plan on deploying the image into Kubernetes, as [Prometheus](https://prometheus.io/)
can handle logs in JSON much easier.
TODO: Make this an optional feature, to not confuse existing users.