Docker Mailserver
Replies: 4 comments 9 replies
|
Needed - ENABLE_SASL_AUTH=1 on the relay server. |
|
No that doesn't seem right. I have provided a detailed response, but the short answer is that you should start with this EDIT: For clarity, the reason this probably worked for you is you were tweaking settings without proper container restart like we advise with |
|
I'm not sure where I got the setting from, possibly chatgpt or some other internet resource, but it definitely changed the situation from authentication failure to working. ¯_(ツ)_/¯ |
|
I wrote the revised version of these docs, so it would be helpful to get some feedback from you on where it could be improved. I wanted to ensure that I provided as much information on the topic as it can get a bit bewildering to grok for the various configuration different users required. I tried to organize all those details into this structure:
Technical details in particular is useful for me to refresh on a feature we have without hunting all that information down again each time as-needed. Before I rewrote the docs for the page it was less consistent and more vague on details 😅
Just to double check, did you see the end of that document in the "Technical Details" section there is a link to an example I can understand if you didn't see that link, or if it was a bit much to be helpful to you. Perhaps we could add at the top of the docs page a link this The rest of that section also shows what we configure in Postfix for you under the hood. You could technically do this without any of the DMS related config/features for relay host support, by just using our standard You'll also notice a link to our ENV docs page for anything related to Relay Host config there, and EDIT: Oh that minimal They are similar but the official example committed is an improved revision (based on another original GH comment of mine on the topic, which is linked to at the start of the official
This config file is covered in the "Advanced Configuration" section, the docs perhaps could be a bit clearer on this concern but in the earlier "Configuration" section, you are shown the relay credentials with ENV So you can absolutely use that, but just the ENV works too. What you do need to be mindful of is when playing around with the configuration, as annoying as it can be you might not get those changes applied properly unless you do a full container restart ( |
|
Don't get me wrong here, I definitely appreciate the detailed reply, but
My next step now would be to find and setup such a simple smtp relay. There are plenty available but I have yet to find one that allows encrypted authentication - or maybe I am just still fumbling around in the dark. But I realize that is another project, so I don't want to waste your time with this. Thanks again for the detailed reply, appreciated! |
|
Again, thanks for a very extensive (not sure if this is the correct word, not a native english speaker) reply with many options. Let me first try to clarify my situation and objective if I didn't explain it well before: I have a VPS on the public internet, where I currently run my mailserver with DMS. Everything works perfectly, except the hosting is cheap and unreliable and is sometimes down, which is not acceptable for incoming mail. For this reason I want to move DMS to my homelab. The only problem with this is that many (if not most) mail servers reject mails coming from consumer networks, hence the need for a relay server that is not on a consumer network. I don't spam or mass mail, it's just my private mail that I want to host myself for privacy reasons, so I don't need any mass mail relay service, I just need a gateway on a proper public internet IP address that isn't going to be automatically blacklisted. I also don't want incoming mail to reach a server that is down, so I want it to go directly to my homelab. I don't suppose that should be a problem. It is a gigabit fiber link, and though it is nominally a dynamic IP, it hasn't changed in the time I've had the ISP, and even then I use cloudflare dns and have a very effective cloudflare-ddns script that checks the IP address every 5 minutes and if changed, updates the MX records. Not perfect, but a lot better than what I have now. I'm not hysterical about the memory footprint, I just thought it was an overkill to use DMS as a relay, but if, as you suggest, there is an SMTP_ONLY environment variable that would limit it to that part I suppose I might as well use an old trusted friend rather than trying to find something else. Your suggestion with the dms-relay example probably would work. There's a couple of things I don't really understand though:
As for what I was looking for was basically a simple example of what I needed to do on the mailserver to tell it to use a relay, and what do to to setup a relay. The latter part you just did with your dms-relay example |
|
Short answers:
Below is more verbose / detailed response to each question but I will follow-up with another answer that is easier to digest 👍 (UPDATE: Please view this answer instead) Collapsed due to verbosity (click to view)
As mentioned in an earlier reply, In DMS we enforce TLS on port 587 and 465 since you are sending credentials in plaintext over the network otherwise, you could technically remove the requirement but your ISP and anyone else listening could inspect all traffic then (some airport in Thailand was caught doing this when using their Wi-Fi AP I think). SMTP over port 25 isn't generally assumed to be sent through a secure connection though, but you might care about your credentials (since if leaked would allow anyone to send mail out from your instance). It doesn't have to be LetsEncrypt, you could supply your own certs that are only valid to your systems as the official example demonstrates: docker-mailserver/demo-setups/relay-compose.yaml Lines 46 to 50 in 060bf9a docker-mailserver/demo-setups/relay-compose.yaml Lines 54 to 57 in 060bf9a docker-mailserver/demo-setups/relay-compose.yaml Lines 106 to 147 in 060bf9a Generating your own certificate files like that can be done as instructed at the bottom of this comment I referenced in an earlier response. Just to clarify, while TLS is optional for inbound connections to DMS where not configuring the docker-mailserver/target/scripts/helpers/relay.sh Lines 94 to 102 in 5f4e868 We could override that with our docker-mailserver/target/scripts/check-for-changes.sh Lines 126 to 136 in 5f4e868
This is a Docker Compose feature I often use this in my examples so you can copy a single You can stick with what is familiar and switch to using separate files if you prefer, whatever is most convenient there is no notable difference except that
Same as the first question, it's a regular DMS instance so you can create the Alternative is to use There is a way to configure accounts within Postfix too, but nobody has taken time to contribute docs or integration into DMS yet. You will find a tracking issue that you can subscribe to here along with links to issues/discussions where users have shared solutions that worked for them. Ultimately, if the DMS image is familiar and works well for you with minimal resource overhead as-is, just don't expose port 25 publicly. You only need to publish your preferred port 587 (works best presently for when you have You could alternatively probably leverage a VPN to keep the VPS DMS private. Without port 25 published, no mail will be delivered from the public, and provided you're not sending mail to a recipient address that relay DMS is configured for, then the default Dovecot won't try store it either, it'll just be used for the account auth for Postfix. I know DMS is not that ideal for a simple dumb authenticated relay service, but it may be quicker to setup and get going in the meantime 🤷♂️
I actually showed you both parts, To run the relay example, as the referenced link in the top of that # Start all 3 containers:
docker compose up -d --force-recreate
# Run the `swaks` command to send a test email from dms-sender, to dms-destination via the dms-relay container (relay host):
# This represents your mail client (eg: Thunderbird), unrelated to relay feature, you can authenticate over port 587 or 465
# `--port 587 -tls` / `--port 465 -tlsc` (the additional `c` is not a typo, you'll need that if changing to port 465)
# If you want to verify TLS (optional), you can tell `swaks` about the CA cert location with: `--tls-ca-path /tmp/tls/ca-cert.pem`
docker compose exec dms-sender swaks --ehlo mail.example.test --server mail.example.test \
--port 587 -tls \
--auth PLAIN --auth-user john.doe@example.test --auth-password secret \
--from john.doe@example.test --to jane.doe@destination.test
# View the logs, you'll see that the mail was sent, relayed and delivered successfully:
docker compose logsThat runs 3 DMS instances locally all in the same docker network, using private TLS certificates and Docker's embedded DNS (without mail specific DNS records setup), and uses All you have to do is adapt the referenced config to your real DMS containers at the homelab and VPS and you're good to go. I've tried to make that easier for you with the two Your homelab DMS only needs to add these ENV to relay to environment:
- DEFAULT_RELAY_HOST=[smtp.relay-service.test]:587
- RELAY_USER=relay-user@relay-service.test
- RELAY_PASSWORD=secretIt should be that simple 😎 As for your VPS
NOTES:
|
Just so you're aware, services like SendGrid tend to offer a free tier that is viable when you don't have much mail flowing through it, so you could leverage that for sending personal mail instead of the VPS setup of your own relay host service. They should work much in the same way as I described configuring DMS as a relay host. Except they tend to have already established a solid sender reputation and have the partnerships/trust with big mail service providers that it may be more reliable for delivery. Something to consider :) |
|
I was quite exited with this answer, but it turns out that the free plans only allow one user, so I'll proceed with your (excellent) examples below. I'll update shortly, when there's news. :) |
|
Apologies for the delay, I suffered an injury 😓 Nearly recovered though :) I have an email notification that detailed a separate reply from you that discussed SendGrid and you later cite As for the related config and failure logs you shared (which I am only able to view via the email notification I received):
Within the DMS container I am able to connect to their relay service over StartTLS port 587 successfully, getting a valid certificate and negotiating TLS 1.3 cipher (but they support TLS 1.2 too): $ openssl s_client -connect smtp.mailersend.net:587 -starttls smtp
# ...
-----END CERTIFICATE-----
subject=CN = *.mailersend.net
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5342 bytes and written 438 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 STARTTLS
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
# ...So I don't think the failure you encountered would be an issue on DMS or For The only condition for this is that you send mail with a sender address that matches your verified domain, so it's not locked down to a single user per se, just that you are understandably required to be authorized for sending the mail (which you are not when it's third-party senders and you want to forward that). From what you had explained to me, you were wanting to relay outbound mail you send, which is presumably all from the same mail domain for the sender addresses used. If you have multiple mail domains, then you're right that the plan won't work for you. If you instead need to relay third-party mail arriving at port 25 to DMS, then you will probably want to use PostSRSd (this is a workaround that rewrites the sender address to use your own domain, so when you forward that mail your mail domain DNS will pass the record checks like SPF) or ARC (Rspamd supports this AFAIK and is relevant to forwarding mail that was delivered to DMS). Both of these approaches should enable the ability to forward mail from foreign senders without firing alarms for spam detection 😅
I've not used any personally, nor compared competing services so I don't have much feedback with the relay services out there. SendGrid apparently no longer offers the free tier, recently switching to a 60 day trial. So I guess that's the drawback with trying to delegate to free SaaS plans when they later rug pull 😓 The link has users suggesting alternatives if you're interested in that. |
|
I have put this together for you, two NOTE:
Step A - Configure DMS to use a relay hostThis is your homelab instance, adapt the below
services:
dms-homelab:
image: mailserver/docker-mailserver:latest # :15.1
hostname: mail.example.test
environment:
- DEFAULT_RELAY_HOST=[smtp.relay-service.test]:587
- RELAY_USER=relay-user@relay-service.test
- RELAY_PASSWORD=secret
# `configs` is a Docker Compose feature to embed files. I have used this feature to make the example simple.
# You can instead use separate files with `volumes` in your real `compose.yaml` config.
configs:
- source: dms-postfix-overrides
target: /tmp/docker-mailserver/postfix-main.cf
- source: dms-accounts
target: /tmp/docker-mailserver/postfix-accounts.cf
# Using the Docker Compose `configs.content` feature instead of volume mounting separate files.
# NOTE: This feature requires Docker Compose v2.23.1 (Nov 2023) or newer:
# https://github.com/compose-spec/compose-spec/pull/446
configs:
dms-postfix-overrides:
content: |
smtp_tls_security_level=may
# DMS expects an account to be configured to run, this example provides accounts already created.
# Login credentials:
# user: "john.doe@example.test" password: "secret"
dms-accounts:
# NOTE: Any `$` in `compose.yaml` implies a system environment variable to substitute,
# As such any content with `$` needs to be changed to `$$` to opt-out of this Docker Compose feature.
content: |
john.doe@example.test|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.Extra Info - ENV for relay-hostThis is all you need to know about the required relay DMS ENV settings:
Extra Info - DNSNothing special here to change for relay host support, standard DNS for a typical mailserver. Your mail domain (
Step B - Configure another DMS instance to act as a relay hostYour VPS instance:
services:
dms-relay:
image: mailserver/docker-mailserver:latest # :15.1
hostname: smtp.relay-service.test
# This is optional but skips the default anti-spam service since you don't have a need for it?
environment:
- ENABLE_AMAVIS: 0
# This is the only port that needs to be published so `dms-homelab` can connect
ports:
- 587:587
# Keep everything in `compose.yaml` for convenience
configs:
- source: dms-accounts
target: /tmp/docker-mailserver/postfix-accounts.cf
# NOTE: Change this the `relay-user` content line to your own generated `postfix-accounts.cf` with a more secure password
configs:
# Login credentials:
# user: "relay-user@relay-service.test" password: "secret"
dms-accounts:
content: |
relay-user@relay-service.test|{SHA512-CRYPT}$$6$$o65y1ZXC4ooOPLwZ$$7TF1nYowEtNJpH6BwJBgdj2pPAxaCvhIKQA6ww5zdHm/AA7aemY9eoHC91DOgYNaKj1HLxSeWNDdvrp6mbtUY.Extra info
|
|
Some times it is easier to try a working example yourself for reference. So if the above advice is still unclear, this might help to try. At the bottom I also show the resource usage of the example. The Try it out locallyCreate a file with the This runs everything locally as 3 DMS containers. It will send a test email that will be relayed through services:
dms-homelab:
image: mailserver/docker-mailserver:latest # :15.1
hostname: mail.example.test
environment:
- DEFAULT_RELAY_HOST=[smtp.relay-service.test]:587
- RELAY_USER=relay-user@relay-service.test
- RELAY_PASSWORD=secret
configs:
- source: dms-postfix-overrides
target: /tmp/docker-mailserver/postfix-main.cf
- source: dms-accounts
target: /tmp/docker-mailserver/postfix-accounts.cf
# Optionally publish this port and send an email from your own mail client instead of using `swaks`:
# This will need to have the mail client configured to connect to DMS at `localhost:587`,
# the sender and recipient addresses shouldn't need any extra DNS setup on the Docker host system.
#ports:
# - 127.0.0.1:587:587
dms-relay:
image: mailserver/docker-mailserver:latest # :15.1
hostname: smtp.relay-service.test
environment:
- ENABLE_AMAVIS=0
#ports:
# - 587:587
configs:
- source: dms-accounts-relay
target: /tmp/docker-mailserver/postfix-accounts.cf
# NOTE: Pretend this is another mail server that your target recipient belongs to (like Gmail):
dms-destination:
image: mailserver/docker-mailserver:latest # :15.0
hostname: mail.destination.test
configs:
- source: dms-accounts-destination
target: /tmp/docker-mailserver/postfix-accounts.cf
# WORKAROUND:
# Normally an MX record for `@destination.test` would direct mail to an MTA (eg: `mail.destination.test`).
# This change makes it so that `dms-relay` can resolve the correct container IP via the internal Docker Compose DNS.
networks:
default:
aliases:
- destination.test
# WORKAROUND:
# Skip Postfix security check `reject_unknown_sender_domain` by trusting connections made from the same network.
# When mail arrives from `dms-relay`, `dms-destination` performs a lookup for the sender address domain @example.test`
# But without `dms-homelab` having a similar `networks.default.aliases` configured, the query would fail, rejecting the mail.
environment:
- PERMIT_DOCKER=connected-networks
# Likewise, if you want to you can publish the IMAP ports to access via your preferred mail client
# where you can view the mailbox more easily with a UI. Since `SSL_TYPE` is unset, 993 won't require TLS.
#ports:
# - 127.0.0.1:143:143
# - 127.0.0.1:993:993
configs:
dms-postfix-overrides:
content: |
smtp_tls_security_level=may
# DMS credentials. The password is `secret`
dms-accounts:
content: |
john.doe@example.test|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.
# Copies of `dms-accounts` with username (email address) changed for the other two DMS containers:
dms-accounts-relay:
content: |
relay-user@relay-service.test|{SHA512-CRYPT}$$6$$o65y1ZXC4ooOPLwZ$$7TF1nYowEtNJpH6BwJBgdj2pPAxaCvhIKQA6ww5zdHm/AA7aemY9eoHC91DOgYNaKj1HLxSeWNDdvrp6mbtUY.
dms-accounts-destination:
content: |
jane.doe@destination.test|{SHA512-CRYPT}$$6$$o65y1ZXC4ooOPLwZ$$7TF1nYowEtNJpH6BwJBgdj2pPAxaCvhIKQA6ww5zdHm/AA7aemY9eoHC91DOgYNaKj1HLxSeWNDdvrp6mbtUY.Run the example
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I have read the documentation, specifically https://docker-mailserver.github.io/docker-mailserver/latest/config/advanced/mail-forwarding/relay-hosts/ but I am afraid I am probably too dense to understand it. There are so many if's and but's and particular conditions and exceptions that it leaves me completely confused. I have spent hours with the help of chatgpt to try to make heads and tail of it all, but I just can't get it to work. In order to avoid a TL;DR situation I won't go through everything I tried, just, could someone guide me through what I need to do on the two servers.
Both servers generally works. The public server is currently my working server and works fine, when my ISP works, but it is a cheap setup and as a result not very reliable, happens to be down every now and than. My homelab otoh is rock solid, and I'm on FTTH gigabit internet with excellent reliability too, which is why I prefer using my homelab for my mailserver. Only problem is, it's by definition a consumer line, and hence many (most?) mail hosts rejects it for that alone.
Without going into details, I have on my mailserver (in my homelab) I have
on the relay I have tried various things ,but I think perhaps the most essential is a config/postfix-sasl-password.cf with the same details as on the mailserver above:
At this time I'm stuck with this error:
emails and passwords are of course checked and double checked. I'm sure I'm missing something simple but essential, but I just don't know what, and chatgpt just goes in circles...
help ...
All reactions