Use case is being able to reuse the common methods when extending the image so that the behavior is consistent (e.g: same formatting for log messages) without needing to repeat the code while extending.
This PR allows setting an empty `ALLOWED_SENDER_DOMAINS` variable. The default behaviour remains the same (empty `ALLOWED_SENDER_DOMAINS` will throw an error), but it is posible to override this behaviour via a new variable `ALLOW_EMPTY_SENDER_DOMAINS`.
Having very specific `TrustedHosts` has turned out to be more of a
hassle than a benefit in the end.
Since the service is runing on `localhost` either way, there's no
theoretical way for anybody alse to access the service. Hence we
just set all hosts (`0.0.0.0/0`) to trusted, reduce the LOC and
call it a day.
Important note: DKIM segment is hardcoded to "mail" in the
configuration.
You shouldn't be using any other segment name.
If you don't know what that means: DKIM checks your DNS server
for this segment name by querying `<segment>._domainkey.<domain>`.
So, when saying you need to use the `mail` segment this means that
the record *must* reside under `mail._domainkey.<domain>`.
This fix makes it more explicit that "mail" segment must be used
with this DKIM and adds a few more code to the DKIM part to make
it more resillient and useful.
This commit brings two important features:
- **DKIM support** It's now possible to configure this postfix
image to sign messages using DKIM by simply generating the keys
and providing them in the approprate folder. This should bring
us one step closer to directly sending out emails without relying
on a 3rd-party proxy.
- **test support** A nice and handy script, conviniently called
`test.sh` has been provided, builds the image, spins it up and
tries to send out an email. You'll need `docker-compose` to run
it, though.
This update includes a few features that make it easier to work
with relay hosts. The configuration now uses built-in (Alpine) TLS
certificates and allows the user to specify how the Postfix should
establish a TLS connection. Configure it using `RELAYHOST_TLS_LEVEL`,
if needed.
Another configuration option was added, `MESSAGE_SIZE_LIMIT`, which
enables you to reject messages exceeding certain limits. Especially
useful with relay servers, to prevent messages getting stuck in
Postfix queue.
Use the `INBOUND_DEBUGGING` parameter to enable additional postfix
logs for incoming messages when things go south.
Use `TZ` parameter to set the timezone of the container (especially
useful for logs and dates in the messages).
*Notice that `ALLOWED_SENDER_DOMAINS` is now a neccessary parameter.*
Turns out that due to Postfix anti-spam configuration there's no way
to start it properly without specifying the domains it will relay
email for.
This commit also includes a few samples of running the container:
- standalone
- in [docker-compose](https://docs.docker.com/compose/)
Further work: add a working Kubernetes / Helm chart example.
There are some use cases when using `reject_unverified_recipient`
(http://www.postfix.org/postconf.5.html#reject_unverified_recipient)
doesn't seem to be as good idea. This patch fixes this.
While in theory it seems good, in practice (for our use case) it's not:
- the service cannot send out emails as fast, as each "RCPT TO" will
result in a DNS lookup (and connection to the target server), which can
slow things down considerably.
- the target server might just be busy or temporarily offline. This will
prevent the service from sending out the email, which defeats the
purpose of mail bagging.
- we might be behind a firewall and not even be able to connect to the
target server for email validation
Furthermore, this patch include the following line:
`smtpd_relay_restrictions = permit`
This basically opens up relay functionality to any address. Previously
there was an issue if you wanted to send an email to the address which
was listed in the `$ALLOWED_SENDER_DOMAINS`.
hosts's username and password, if your remote host requires
authentication.
NEW FEATURE: The possibility to execute third party scripts. This should
make extending this image easier.
REFACTORING: Dockerfile now starts with run.sh instead of suprevisor.
This makes it much easier to see any errors that might creep into the
code. Also note that the script now relies on POSIX-compliant commands
only so the executor has been changed from /bin/bash to /bin/sh.
