Configuring docker mail server to relay inbound and outbound mails

[furstblumier]

Hi,

In my current setup I rented a VPS from a cloud provider of my choice. I setup DMS and it worked like a charm, I can now receive mails. 🥳

Now I wanna add on to this. Instead of having my mail lying around on a system that I don't own I'd rather have DMS act as a "proxy" for me. The VPS host has a static IP with DKIM, DMARC, SPF and the whole shebang, so it's a valid target to receive email. Instead of saving these, I'd want to have it relay the mail towards my homeserver that is also running DMS, but only has access to dyndns. I assume my VPS DMS instance doesn't care about that though and would be able to deliver the email "home"(?)

So... how can I configure DMS to relay inbound mail? Should I even use DMS in that case or is it overkill? I'd be glad for any input or ideas! :3

[glime-ai[bot]]

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

---

To configure your Docker Mail Server (DMS) instance on your VPS to relay inbound mail to another DMS instance running on your home server, you can indeed use DMS for this purpose. DMS supports relaying emails, which fits your requirement of acting as a "proxy" to relay emails to your home server. Given that your VPS has a static IP and is already configured with DKIM, DMARC, SPF, and other necessary email authentication mechanisms, it's well-prepared to act as a reliable relay.

Here are the general steps you would need to follow:

1. Configure the Home Server DMS Instance: Ensure your home server DMS instance is configured to receive emails from your VPS. This might involve configuring firewall rules, port forwarding if behind a NAT, and ensuring that your dynamic DNS (DDNS) service is updating correctly so that your VPS can resolve your home server's current IP address.

2. Configure the VPS DMS Instance for Relaying: On your VPS DMS instance, you will need to configure it to relay emails to your home server. This involves setting up your VPS as an SMTP relay. You can use the postfix-main.cf configuration to specify your home server as a relay host.

   You might need to adjust the relayhost parameter in your postfix-main.cf file to point to your home server's current hostname (as provided by your DDNS service). Additionally, ensure that any necessary authentication is configured if your home server requires it for accepting relayed emails.

3. Test the Configuration: After configuring both DMS instances, it's crucial to test the setup to ensure emails are correctly relayed from your VPS to your home server. You can do this by sending emails from an external account to an address handled by your VPS DMS instance and checking if it arrives at your home server.

4. Security Considerations: Ensure that your relay configuration does not accidentally create an open relay that could be abused by spammers. You should restrict which hosts can relay mail through your VPS.

Given the complexity of email systems and the potential for misconfiguration, it's essential to refer to the DMS documentation and specific configuration guides. Unfortunately, the provided context does not include direct instructions for setting up DMS as a relay in this manner, but the general approach outlined above follows standard practices for configuring mail servers for relaying.

For detailed configuration options and commands, you would typically refer to the DMS documentation, Postfix documentation (since DMS uses Postfix for mail handling), and possibly your DDNS service documentation for ensuring your home server is reachable.

If you're not comfortable with manual configuration or if this setup becomes too complex, you might consider simpler alternatives or using a dedicated relay service. However, given your setup and requirements, using DMS as a relay is feasible and allows you to leverage your existing infrastructure.

This comment was generated by Glime.

[polarathene]

Now I wanna add on to this. Instead of having my mail lying around on a system that I don't own I'd rather have DMS act as a "proxy" for me.

Can you confirm if this is what you're wanting?

• Public DMS that receives mail for domains you own
• Received mail is relayed to a private instance of DMS
• Outbound mail sent through the public instance, while if submitted from the private instance it would relay through the public instance?

I think you should be ok with a virtual alias setup alias add ... for your accounts, or a wildcard/catchall (add to postfix-virtual.cf directly) that directs mail to your private instance. An alternative may be to have remote storage (like NFS, but the support is a bit problematic I've heard) or using a feature we have for a separate mail storage backend service, which would be where mail is delivered to for storage instead of the internal Dovecot service we have. It might be possible to use a 2nd DMS instance for that 🤔

You then want to setup the private instance with the Relay Host support (you'll probably want to wait on the v14 release however which carries some fixes for this feature) if you won't connect directly to the public instance from your mail client, and that'd route the mail there for being sent outbound.

---

I've seen this type of setup requested a few times. You could possibly implement it a bit differently.

If you're main concern is with the storage on public VPS, I have been meaning to get the on-disk encryption feature sorted out for v15 release of DMS, which with one of the settings no one can read your mail from access to the disk storage as it'd require your credentials to decrypt.

You kind of want a TCP proxy for the inbound mail (Traefik could do this), which could skip the public DMS instance on the VPS, you'd just route the traffic from the public IP / VPS to your internal DMS on another machine. Kind of need similar for routing the traffic to send back out from the public IP though unless you configure a Relay Host instead such as SendGrid or Gmail (this should be simpler, and for low traffic is free).

Instead of saving these, I'd want to have it relay the mail towards my homeserver that is also running DMS, but only has access to dyndns.

You might be able to leverage something like tailscale, which is similar to a VPN setup. That way your personal system and the VPS can be in a private network, but if dyndns works for you that should be fine too 👍

I'd also consider the feature I mentioned earlier for storage, I'm just not sure how that looks config wise for you. That would be handled via this ENV POSTFIX_DAGENT, which could be a separate Dovecot container or similar service, you might be able to mirror the configuration of the public DMS instance though for a private one so that it configures Dovecot for you.

We have a very basic test case for this kind of setup, it uses our user-patches.sh feature with this script to adjust the configuration. You'd use that with the private instance, while the public instance uses POSTFIX_DAGENT to point to the IP/hostname and port. In the user-patches.sh I think it should be ok to stay on the 127.0.0.1 IP, you'd publish the port for the container for it to be reachable via your dyndns or other network interface (eg: if using tailscale).

[furstblumier]

Thank you for the detailed answer, I appreciate you took the time!

Can you confirm if this is what you're wanting?

Public DMS that receives mail for domains you own
Received mail is relayed to a private instance of DMS
Outbound mail sent through the public instance, while if submitted from the private instance it would relay through the public instance?

That is correct yes! I think I got a bit hung-up on the relaying part. You are likely correct that a catch-all alias would do exactly what I need. Would my mail be saved on the public instance in that case? I probably need to run my public instance with SMTP_ONLY=1 since I am not using any dovecot capabilities?

You might be able to leverage something like tailscale, which is similar to a VPN setup. That way your personal system and the VPS can be in a private network, but if dyndns works for you that should be fine too 👍

Good idea, I can just setup wireguard to have everything in my local network and don't have to punch more holes in my firewall.

If you're main concern is with the storage on public VPS, I have been meaning to get the on-disk encryption feature sorted out for v15 release of DMS, which with one of the settings no one can read your mail from access to the disk storage as it'd require your credentials to decrypt.

That is indeed my main concern. The current at-rest encryption implementation kinda does nothing if someone has access to the disk, since they could just read out the private key that is stored on the same system. Defeats the purpose somewhat imo

[polarathene]

Would my mail be saved on the public instance in that case?

No I don't think so. Postfix should resolve the alias and if it does not consider it as locally managed (eg Dovecot running with a DMS account added with setup email add ...), it should send that to the target address. I'm not able to confirm that right now so you'll need to test it.

I probably need to run my public instance with SMTP_ONLY=1 since I am not using any dovecot capabilities?

I think so... I haven't looked into that feature in a while and I think our current documentation is a bit minimal for it. It was community contributed by the same user that wanted to replace Dovecot with their own Kopano instance IIRC, which used that POSTFIX_DAGENT ENV to configure.

Although most issues/support for SMTP_ONLY=1 tends to be around using it as a null-mailer (a service that only sends mail outbound rather than receives). Once again it should be fairly easy to verify in your setup.

It was contributed some time ago and may have been overlooked with DMS development at some point, AFAIK we have a basic test case in place. If you have any problems that need config changes in DMS we can look into resolving that for the next release and expanding the test coverage 👍

---

The current at-rest encryption implementation kinda does nothing if someone has access to the disk, since they could just read out the private key that is stored on the same system. Defeats the purpose somewhat imo

Yeah, I had revised it with another option that supports per-user encryption which relies on credentials at auth to decrypt, avoiding that concern. I want to get back to that for v15.

Since remote filesystem support seems a bit iffy, your probably taking the right approach with running DMS on your personal system.

• You could possibly use Cloudflare email routing (inbound) paired with SendGrid (outbound) or similar service as a way to avoid the public VPS 🤔 The cloudflare service takes a public domain address (managed by it's DNS service) and forwards the mail to a destination domain like [email protected], you could possibly use the dyndns for that?
• Or go with the earlier suggestion with TCP reverse-proxy like Traefik or public DMS with SMTP_ONLY=1 and alias config to achieve roughly the same inbound scenario. For outbound relay through SendGrid like service or that same public DMS (this doesn't need your sender address as an account, it could be anything really, just providing the credentials from setup email add for your private DMS to authenticate with).

[furstblumier]

Alright, I've built the inbound relay with a public Postfix instance. I installed it directly instead of using DMS since the public instance should be kept very simple. I am connecting both instances via wireguard. My main.cf is

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

myorigin = example.com
mydestination =
local_recipient_maps =
local_transport = error:local mail delivery is disabled

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 3.6 on
# fresh installs.
compatibility_level = 3.6



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = external-mail.example.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
transport_maps = hash:/etc/postfix/transport
relay_domains = $mydestination, hash:/etc/postfix/relay
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
maillog_file = /var/log/postfix.log

the only files I created were transport:
example.com relay:[internal-mail.example.com]:25
and relay:
example.com OK
Though I could have just used relay_domains = example.com in main.cf I guess. That's all for the public instance. For my private DMS I did the following:
I added the VPN network of my remote instance to postfix-main.cf:
mynetworks = 192.168.2.0/24
Though the remote host with /32 would also work ofc. Other than, I set it up as normal. I could only test inbound mail so far, but not outbound yet, so I'll update this thread once I do. :3
References I used:

• Docu
• Blog

[polarathene]

Sounds good so far! Here's some feedback if it helps :)

---

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

This should probably be configured for your actual TLS certs otherwise they're probably not going to be trusted by anyone that cares when connecting with STARTTLS on port 25 to deliver you mail on the public Postfix instance.

There was a recent issue that might have some CLI commands you can try to inspect the certs:

• question: Why does my mail client show a certificate for an FQDN I do not know? #3955 (comment)
• question: Why does my mail client show a certificate for an FQDN I do not know? #3955 (comment)

Should be possible to just spin up a alpine container and install the step package like I show at the start of that 2nd link, then use the verify subcommand, should be something like step certificate verify smtps://mail.example.com (you are verifying TLS for the public Postfix server, thus the MX record address for example.com, not the domain in an email address like [email protected]).

Many will connect happily and only care about the the connection being secured over TLS, rather than the authenticity that the connection is from the server it claims to be or that it's still valid IIRC. More relaxed than you'd experience with an HTTPS connection.

Just mentioning this as a potential concern, but so long as that connecting client does not insist on TLS being established for port 25, if the client only allowed TLS connection for trusted verified cert, it would usually fallback to plaintext unencrypted delivery (so you can see why it tends to be more relaxed, if the transfer will go ahead anyway, it might as well use TLS when available).

With MTA-STS or other explicit opt-in mailserver config, compatible clients would always enforce delivery over TLS and refuse to deliver over unencrypted connection, but that should only be a concern if you intentionally configure your mail domain for that.

---

relay_domains = $mydestination, hash:/etc/postfix/relay

the only files I created were transport:
example.com relay:[internal-mail.example.com]:25
and relay:
example.com OK

relay_domains is not quite the same feature I had in mind for relaying. That isn't one DMS supports for relaying.

IIRC it was for mail domains that the Postfix instance does not manage itself locally but was authorized to send outbound without the authentication / network requirement. That is what you need though 🤔

Though I could have just used relay_domains = example.com in main.cf I guess.

Yes, looks like it.

I would have thought of using relayhost = [internal-mail.example.com]:25 which should be similar to transport_maps but would route all outbound mail to that target MTA (your private DMS instance). But the transport_maps is probably better, especially since this seems to be a case where relay_domains is useful 👍

• https://www.postfix.org/postconf.5.html#transport_maps
• https://www.postfix.org/postconf.5.html#relay_domains
• https://www.postfix.org/postconf.5.html#relayhost

---

I added the VPN network of my remote instance to postfix-main.cf:
mynetworks = 192.168.2.0/24

You could presumably setup relay to use credentials. Our v14 / edge docs page for relay hosts shows how to configure this, but your mynetworks approach on the DMS side is probably an easier solution than adding the extra config to your public Postfix instance:

For you this would be:

## Routing to private DMS:
# Send all outbound mail through this relay service (should be equivalent to your `transport_maps`, you might only need to adjust the port):
relayhost = [internal.example.com]:587
# You'll still probably need the additional `relay_domains = example.com`

## Authentication support:
# The DMS account and password credentials to authenticate with
smtp_sasl_password_maps = static:[email protected]:secret
# Required to provide credentials to the relay service:
smtp_sasl_auth_enable = yes
# Enforces requiring credentials when sending mail outbound:
smtp_sasl_security_options = noanonymous
# Enforces a secure connection (TLS required) to the relay service:
smtp_tls_security_level = encrypt

I think that'd work 😅 The only difference you'd really get is not needing to configure the VPN subnet on the DMS side, instead the public Postfix like any other mail server that can reach your private DMS instance could connect to port 587 and authenticate with credentials.

Just a different way to manage the trust for the most part, as either is required to ignore the security checks that your public Postfix server is not authorized to send mail on behalf of the sender address, so would normally reject it.

---

In saying that, your public Postfix probably isn't going to be checking SPF + DKIM either, and I know there was discussion about if mail arriving from authenticated ports like 587 with DMS should also bypass the anti-spam checking which would be one notable difference to mynetworks 🤔

If you do find yourself receiving extra spam or forged mail that could have been avoided by checking SPF/DKIM etc, you'll need to manage a bit more config for the public instance. I think one issue that could happen is you get mail delivered to [email protected] arrive to your public Postfix instance, it accepts it because of the domain and relays to the private DMS, which skips checks and then notices the user is not valid to deliver to (unless you have a wildcard/catch-all), so it should send back a bounce mail to the public Postfix and that may relay that back to the original sender address... which could be forged to use your server to send mail to the sender address as a target, which isn't actually from the mailserver that sent the mail 😬

I believe that is called backscatter and is bad for your mail domain reputation which could get the mail you send out marked as spam/junk (or worse not delivered). Something like that 🤷‍♂️ not sure if services like SendGrid avoid that penalty, possibly.

Just bringing that to your attention as it may become a problem.

[furstblumier]

This should probably be configured for your actual TLS certs otherwise they're probably not going to be trusted by anyone that cares when connecting with STARTTLS on port 25 to deliver you mail on the public Postfix instance.

Funnily enough when I inspect that cert I can see that my server is offering a certificate that is valid until 2034 and was issued 2 days ago. I don't think I've knowingly setup these snakeoil certs, though I might be wrong lol I was using DMS on my public instance, but I assume it's not from it since I didn't see a bindmount to the ssl folder. I guess I could setup traefik to generate a "better" certificate, similar to how I did it with DMS before on the public instance...

relay_domains is not quite the same feature I had in mind for relaying. That isn't one DMS supports for relaying.

If this issue is something that is coming up regularly, maybe I could PR that functionality.

/etc/postfix/transport
your-mail-domain.com    relay:[X.X.X.X]:port
*                       relay:[smtp.gmail.com]:587

/etc/postfix/relay
your-mail-domain.com     OK
*                        OK

Would support inbound and outbound relay as before, like that.

I believe that is called backscatter and is bad for your mail domain reputation which could get the mail you send out marked as spam/junk (or worse not delivered).

I actually have catch-all that drops mail for users that aren't some that I explicitly defined. So that should be less of a concern for me.

EDIT:
I saw this in the documentation in relay.sh

# This helper is only concerned with relaying mail from authenticated submission (ports 587 + 465).
# Thus it does not deal with `relay_domains` (which routes through `relay_transport` transport, default: `master.cf:relay`),
# that is intended for forwarding inbound mail (including from port 25) for any permitted domains.

so probably it would have to be its own function

[polarathene]

I don't think I've knowingly setup these snakeoil certs

They're provisioned by the Postfix package itself when installed as part of the image build.

docker-mailserver/target/postfix/main.cf

Lines 26 to 29 in d502dae

	# TLS parameters
	# These [snakeoil files actually exist](https://askubuntu.com/questions/396120/what-is-the-purpose-of-the-ssl-cert-snakeoil-key), but shouldn't ever be used in production!
	# If no `SSL_TYPE` env is set, "plaintext" is configured, but still accepts SSL with these:
	smtpd_tls_chain_files = /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem

I guess I could setup traefik to generate a "better" certificate, similar to how I did it with DMS before on the public instance...

You could, or you could follow our certbot guide, should roughly work the same for you if you don't want to setup/manage Traefik on the VPS. Just add a cron-job/systemd-timer to routinely run the certbot container and update the cert folder that Postfix will reference and you should be good to go 👍

If you want to double check configuration of Postfix with TLS to be similar to what DMS does we have this logic:

• Postfix / Dovecot primary cert:

  docker-mailserver/target/scripts/helpers/ssl.sh

  Lines 31 to 57 in d502dae

  	# Primary certificate to serve for TLS
  	function _set_certificate() {
  	local POSTFIX_KEY_WITH_FULLCHAIN=${1}
  	local DOVECOT_KEY=${1}
  	local DOVECOT_CERT=${1}
  	# If a 2nd param is provided, a separate key and cert was received instead of a fullkeychain
  	if [[ -n ${2} ]]; then
  	local PRIVATE_KEY=$1
  	local CERT_CHAIN=$2
  	POSTFIX_KEY_WITH_FULLCHAIN="${PRIVATE_KEY} ${CERT_CHAIN}"
  	DOVECOT_KEY="${PRIVATE_KEY}"
  	DOVECOT_CERT="${CERT_CHAIN}"
  	fi
  	# Postfix configuration
  	# NOTE: `smtpd_tls_chain_files` expects private key defined before public cert chain
  	# Value can be a single PEM file, or a sequence of files; so long as the order is key->leaf->chain
  	sedfile -i -r "s|^(smtpd_tls_chain_files =).*|\1 ${POSTFIX_KEY_WITH_FULLCHAIN}|" "${POSTFIX_CONFIG_MAIN}"
  	# Dovecot configuration
  	sedfile -i -r \
  	-e "s|^(ssl_key =).*|\1 <${DOVECOT_KEY}|" \
  	-e "s|^(ssl_cert =).*|\1 <${DOVECOT_CERT}|" \
  	"${DOVECOT_CONFIG_SSL}"
  	}

• Our custom TLS level settings:

  • docker-mailserver/target/scripts/helpers/ssl.sh

    Lines 87 to 104 in d502dae

    	function _apply_tls_level() {
    	local TLS_CIPHERS_ALLOW=$1
    	local TLS_PROTOCOL_IGNORE=$2
    	local TLS_PROTOCOL_MINIMUM=$3
    	# Postfix configuration
    	sed -i -r \
    	-e "s|^(smtpd?_tls_mandatory_protocols =).*|\1 ${TLS_PROTOCOL_IGNORE}|" \
    	-e "s|^(smtpd?_tls_protocols =).*|\1 ${TLS_PROTOCOL_IGNORE}|" \
    	-e "s|^(tls_high_cipherlist =).*|\1 ${TLS_CIPHERS_ALLOW}|" \
    	"${POSTFIX_CONFIG_MAIN}"
    	# Dovecot configuration (secure by default though)
    	sed -i -r \
    	-e "s|^(ssl_min_protocol =).*|\1 ${TLS_PROTOCOL_MINIMUM}|" \
    	-e "s|^(ssl_cipher_list =).*|\1 ${TLS_CIPHERS_ALLOW}|" \
    	"${DOVECOT_CONFIG_SSL}"
    	}

  • docker-mailserver/target/scripts/helpers/ssl.sh

    Lines 133 to 159 in d502dae

    	# TLS strength/level configuration
    	case "${TLS_LEVEL}" in
    	( "modern" )
    	local TLS_MODERN_SUITE='ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'
    	local TLS_MODERN_IGNORE='!SSLv2,!SSLv3,!TLSv1,!TLSv1.1'
    	local TLS_MODERN_MIN='TLSv1.2'
    	_apply_tls_level "${TLS_MODERN_SUITE}" "${TLS_MODERN_IGNORE}" "${TLS_MODERN_MIN}"
    	_log 'debug' "TLS configured with 'modern' ciphers"
    	;;
    	( "intermediate" )
    	local TLS_INTERMEDIATE_SUITE='ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256'
    	local TLS_INTERMEDIATE_IGNORE='!SSLv2,!SSLv3,!TLSv1,!TLSv1.1'
    	local TLS_INTERMEDIATE_MIN='TLSv1.2'
    	_apply_tls_level "${TLS_INTERMEDIATE_SUITE}" "${TLS_INTERMEDIATE_IGNORE}" "${TLS_INTERMEDIATE_MIN}"
    	_log 'debug' "TLS configured with 'intermediate' ciphers"
    	;;
    	( * )
    	_log 'warn' "TLS_LEVEL '${TLS_LEVEL}' not valid"
    	;;
    	esac

• Our base main.cf TLS settings that the logic above overrides:

  docker-mailserver/target/postfix/main.cf

  Lines 32 to 50 in d502dae

  	smtpd_tls_security_level = may
  	smtpd_tls_loglevel = 1
  	smtp_tls_security_level = may
  	smtp_tls_loglevel = 1
  	# Reduces CPU overhead with `NO_COMPRESSION`, SMTP not at risk of CRIME attack (see git blame for details)
  	# Reduce opportunities for a potential CPU exhaustion attack with `NO_RENEGOTIATION`
  	tls_ssl_options = NO_COMPRESSION, NO_RENEGOTIATION
  	tls_high_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
  	tls_preempt_cipherlist = yes
  	smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  	smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  	smtpd_tls_mandatory_ciphers = high
  	smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  	smtpd_tls_exclude_ciphers = aNULL, SEED, CAMELLIA, RSA+AES, SHA1
  	smtpd_tls_dh1024_param_file = /etc/postfix/dhparams.pem
  	smtpd_tls_CApath = /etc/ssl/certs
  	smtp_tls_CApath = /etc/ssl/certs

If you need to support port 587/465 on that public instance, this is our base master.cf config, but may need some adjustment:

docker-mailserver/target/postfix/master.cf

Lines 17 to 43 in d502dae

	submission inet n - n - - smtpd
	-o syslog_name=postfix/submission
	-o smtpd_tls_security_level=encrypt
	-o smtpd_sasl_auth_enable=yes
	-o smtpd_sasl_type=dovecot
	-o smtpd_reject_unlisted_recipient=no
	-o smtpd_sasl_authenticated_header=yes
	-o smtpd_client_restrictions=permit_sasl_authenticated,reject
	-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
	-o smtpd_sender_restrictions=$mua_sender_restrictions
	-o smtpd_discard_ehlo_keywords=
	-o milter_macro_daemon_name=ORIGINATING
	-o cleanup_service_name=sender-cleanup
	submissions inet n - n - - smtpd
	-o syslog_name=postfix/submissions
	-o smtpd_tls_wrappermode=yes
	-o smtpd_sasl_auth_enable=yes
	-o smtpd_sasl_type=dovecot
	-o smtpd_reject_unlisted_recipient=no
	-o smtpd_sasl_authenticated_header=yes
	-o smtpd_client_restrictions=permit_sasl_authenticated,reject
	-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
	-o smtpd_sender_restrictions=$mua_sender_restrictions
	-o smtpd_discard_ehlo_keywords=
	-o milter_macro_daemon_name=ORIGINATING
	-o cleanup_service_name=sender-cleanup

You don't really need the custom TLS logic we have, Postfix should have good enough defaults I think? We set certs through a different single setting, but that's to support a feature of primary and fallback certs (to support offering both ECDSA + RSA types to clients). But I figured I might as well reference what DMS does while on this topic 😅

If you choose to use Traefik, be sure to follow our guide (Note: I completely rewrote this page, so switching to edge / v14 version is encouraged) of this page has been so that the proper client IP is preserved if that's important for you if you have it replace the public postfix instance.

---

If this issue is something that is coming up regularly, maybe I could PR that functionality.

I recall several users in the past issues/discussions inquiring about a similar setup to what is discussed here, but I can't recall their exact requirements.

If there was more demand for it, I'd encourage a PR but you're more likely to get friction with that by a requirement for documentation so that users can better understand the new feature support and discover it in the docs with more context on how to set it up properly. Basically adapting the highlights of this discussion.

Generally due to low demand for it, we'd defer to a docs only contribution. Similar to our docs for the example guide on using Traefik with PROXY Protocol I linked earlier in this response.

---

so probably it would have to be its own function

Yes, I wrote / refactored the logic there into that separate relay.sh helper file we have today. There's an open TODO issue by me that notes future refactor work to do, similar to commentary in the file itself 😅

A contribution to the scripts if approved by maintainers would also require adding some test cases. Presently I haven't had time to move the test suite forward towards migrating to compose.yaml approach, which is when we'd introduce a DNS container which would make it easier to write tests needing multiple DMS instances such as for relaying.

I'd advise just contributing to the docs examples page if that interests you, review is more relaxed/quick and it's just markdown files (with some special syntax from the docs generator). If that interests you, here is a recent contribution from a user adding a new page to our docs, it should be a useful reference.

You can use our existing postfix-main.cf / user-patches.sh for most customization needs when writing such documentation. It's ok to describe how you handle routing public deliveries to your private DMS server, you can be as detailed/brief as you like on that. Most focus on review is on advice with configuring DMS.

You may also open a feature request issue if you'd like to get the relay_domains support approved. It can help with showing user demand, or if other maintainers are happy to approve a PR for it without that, you can also go straight to a PR for that (docs would still be expected, and to whatever degree is reasonable with the current test suite for test coverage). All maintainers are happy to provide guidance in area of the project, just ask and we'll point you to what you need to know or explain how to approach implementation 👍 (you can also just raise a feature request without any obligation to implement, or time pressure to commit).

[furstblumier]

I'll at least expand the docs to cover my setup, I think and also open a feature request! Thank you for helping me out and brainstorming :D

One question, though. If I use DKIM with my relay setup, will the public postfix instance have to use the private key? I've seen that my private instance added the dkim header in a test email, but I'm unsure if I would need to do that again for my relay.

[polarathene]

I'll at least expand the docs to cover my setup, I think and also open a feature request!

Greatly appreciated, thanks so much!

If I use DKIM with my relay setup, will the public postfix instance have to use the private key?

Private key is only used for signing AFAIK, so that should only be relevant when sending the mail out?

I've seen that my private instance added the dkim header in a test email, but I'm unsure if I would need to do that again for my relay.

I'm not entirely sure to advise here. Ironically I've not actually deployed DMS myself beyond local testing 😅

I do recall some issues earlier this year (or late last year) regarding DKIM concerns with relays. I think any related to rspamd has been sorted out for v14, there was one user recently having an issue with OpenDKIM (default) but they didn't provide much details wise to troubleshoot.

I think DMS will sign for the mail it relays outbound, and anything else could relay again could optionally sign but that'd only matter to verify nothing added since (such as extra paper trail of mail server(s) sent through) is accurate. The DKIM signature for your mail should be intact and verify it's message content hasn't been tampered with 👍 A test mail should confirm that :)

This is something I'd like the test suite to have better coverage for once we get a DNS service container added into the test suite setup 😎

If you use a relay service like SendGrid / AWS SES, they can add DKIM signature I think. I'm not sure how configurable our OpenDKIM / Rspamd support is with verification vs signing, I assume the feature support enables both, rspamd might be a bit more flexible but that's a feature I have very little exposure/experience with.