a0ee472501
"Brief" summary/overview of changes. See the PR discussion or individual commits from the PR for more details.
---
Only applies to the `docs/content/**` content (_and `setup` command_). `target/` and `test/` can be normalized at a later date.
* Normalize to `example.com`
- Domains normalized to `example.com`: `mywebserver.com`, `myserver.tld`, `domain.com`, `domain.tld`, `mydomain.net`, `my-domain.tld`, `my-domain.com`, `example.org`, `whoami.com`.
- Alternative domains normalized to `not-example.com`: `otherdomain.com`, `otherdomain.tld`, `domain2.tld`, `mybackupmx.com`, `whoareyou.org`.
- Email addresses normalized to `admin@example.com` (in `ssl.md`): `foo@bar.com`, `yourcurrentemail@gmail.com`, `email@email.com`, `admin@domain.tld`.
- Email addresses normalized to `external-account@gmail.com`: `bill@gates321boom.com`, `external@gmail.com`, `myemail@gmail.com`, `real-email-address@external-domain.com`.
- **`faq.md`:** A FAQ entry title with `sample.domain.com` changed to `subdomain.example.com`.
- **`mail-fetchmail.md`:** Config examples with FQDNs for `imap`/`pop3` used `example.com` domain for a third-party, changed to `gmail.com` as more familiar third-party/external MTA.
* Normalize config volume path
- Normalizing local config path references to `./docker-data/dms/config/`: `./config/`, `config/`, \``config`\`, `/etc/` (_volume mount src path prefix_).
- Normalize DMS volume paths to `docker-data/dms/mail-{data,state,log}`: `./mail`, `./mail-state` `./data/mail`, `./data/state`, `./data/logs`, `./data/maildata`, `./data/mailstate`, `./data/maillogs`, (_dropped/converted data volumes: `maildata`, `mailstate`_).
- Other docker images also adopt the `docker-data/{service name}/` prefix.
* `ssl.md` - Use `dms/custom-certs` where appropriate.
* Apply normalizations to README and example `docker-compose.yml`
---
Common terms, sometimes interchangeably used or now invalid depending on context: `mail`, `mail container`, `mail server`, `mail-server`, `mailserver`,`docker-mailserver`, `Docker Mailserver`.
Rough transformations applied to most matches (_conditionally, depending on context_):
- 'Docker Mailserver' => '`docker-mailserver`'
- 'mail container' => '`docker-mailserver`' (_optionally retaining ' container'_)
- 'mail server' => 'mail-server' / '`docker-mailserver`'
- 'mail-server' => '`docker-mailserver`'
- 'mailserver' => 'mail-server' / '`docker-mailserver`'
Additionally I checked `docker run` (_plus `exec`, `logs`, etc, sub-commands_) and `docker-compose` commands. Often finding usage of `mail` instead of the expected `mailserver`
Additionally changes `mailserver` hostname in k8s to `mail` to align with other non-k8s examples.
---
* drive-by revisions
Mostly minor revisions or improvements to docs that aren't related to normalization effort.
3.5 KiB
| title |
|---|
| Mail Forwarding | Relay Hosts |
Introduction
Rather than having Postfix deliver mail directly, you can configure Postfix to send mail via another mail relay (smarthost). Examples include Mailgun, Sendgrid and AWS SES.
Depending on the domain of the sender, you may want to send via a different relay, or authenticate in a different way.
Basic Configuration
Basic configuration is done via environment variables:
RELAY_HOST: default host to relay mail through,empty(aka '', or no ENV set) will disable this featureRELAY_PORT: port on default relay, defaults to port 25RELAY_USER: username for the default relayRELAY_PASSWORD: password for the default user
Setting these environment variables will cause mail for all sender domains to be routed via the specified host, authenticating with the user/password combination.
!!! warning
For users of the previous AWS_SES_* variables: please update your configuration to use these new variables, no other configuration is required.
Advanced Configuration
Sender-dependent Authentication
Sender dependent authentication is done in docker-data/dms/config/postfix-sasl-password.cf. You can create this file manually, or use:
setup.sh relay add-auth <domain> <username> [<password>]
An example configuration file looks like this:
@domain1.com relay_user_1:password_1
@domain2.com relay_user_2:password_2
If there is no other configuration, this will cause Postfix to deliver email through the relay specified in RELAY_HOST env variable, authenticating as relay_user_1 when sent from domain1.com and authenticating as relay_user_2 when sending from domain2.com.
!!! note To activate the configuration you must either restart the container, or you can also trigger an update by modifying a mail account.
Sender-dependent Relay Host
Sender dependent relay hosts are configured in docker-data/dms/config/postfix-relaymap.cf. You can create this file manually, or use:
setup.sh relay add-domain <domain> <host> [<port>]
An example configuration file looks like this:
@domain1.com [relay1.org]:587
@domain2.com [relay2.org]:2525
Combined with the previous configuration in docker-data/dms/config/postfix-sasl-password.cf, this will cause Postfix to deliver mail sent from domain1.com via relay1.org:587, authenticating as relay_user_1, and mail sent from domain2.com via relay2.org:2525 authenticating as relay_user_2.
!!! note
You still have to define RELAY_HOST to activate the feature
Excluding Sender Domains
If you want mail sent from some domains to be delivered directly, you can exclude them from being delivered via the default relay by adding them to docker-data/dms/config/postfix-relaymap.cf with no destination. You can also do this via:
setup.sh relay exclude-domain <domain>
Extending the configuration file from above:
@domain1.com [relay1.org]:587
@domain2.com [relay2.org]:2525
@domain3.com
This will cause email sent from domain3.com to be delivered directly.
References
Thanks to the author of this article for the inspiration. This is also worth reading to understand a bit more about how to set up Mailgun to work with this.