Docker Mailserver
How can I submit mail to port 25 for DMS to send? #3995
-
|
when using port 25 I'm receiving the following error. I'm using port 25 to send messages from apps since I'm struggling to get them to work with port 465 and I need a temporary solution. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
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 assist you effectively, could you please provide the specific error message you are encountering when using port 25? This will help in diagnosing the issue more accurately. This comment was generated by Glime. |
Beta Was this translation helpful? Give feedback.
-
|
Port 25 is not authorized for mail submission, only delivery. You have ports 465 or 587 to authenticate against when you want to provide mail for DMS to send.
If you search our issues or discussions, you will find advice on how to enable port 25 for sending mail without authentication, but it would be better for you to troubleshoot the above guidance so that you can send mail properly. |
Beta Was this translation helpful? Give feedback.
-
|
Hello polarathene, Email is already setup and working I have it in Thunderbird working. All the apps are in container inside the same docker, when trying to send I constantly get this error. DockerMail -> port 465 TLS Passbolt -> port 465 TLS DockerMail -> port 587 TLS Passbolt -> port 587 TLS I forgot to put the compose file to check if I'm doing something wrong. One thing to keep in mind is the way I have the network designed. services:
mailserver:
image: ghcr.io/docker-mailserver/docker-mailserver:latest
container_name: mailserver
# Provide the FQDN of your mail server here (Your DNS MX record should point to this value)
hostname: mail.example.com
# Automatic cleanup (removes older image pulls from wasting disk space):
environment:
- SSL_TYPE=manual
- ENABLE_RSPAMD=1
- ENABLE_CLAMAV=1
- ENABLE_FAIL2BAN=1
- ONE_DIR=1
- POSTFIX_MESSAGE_SIZE_LIMIT=26214400
- ENABLE_OPENDKIM=0
- ENABLE_OPENDMARC=0
- ENABLE_POLICYD_SPF=0
- ENABLE_AMAVIS=0
- ENABLE_SPAMASSASSIN=0
- SSL_CERT_PATH=/tmp/dms/custom-certs/example.com.crt
- SSL_KEY_PATH=/tmp/dms/custom-certs/example.com.key
env_file: mailserver.env
# More information about the mail-server ports:
# https://docker-mailserver.github.io/docker-mailserver/latest/config/security/understanding-the-ports/
# To avoid conflicts with yaml base-60 float, DO NOT remove the quotation marks.
ports:
#- "25:25" # SMTP (explicit TLS => STARTTLS, Authentication is DISABLED => use port 465/587 instead)
#- "143:143" # IMAP4 (explicit TLS => STARTTLS)
- "465:465" # ESMTP (implicit TLS)
- "587:587" # ESMTP (explicit TLS => STARTTLS)
- "993:993" # IMAP4 (implicit TLS)
volumes:
- /docker/certificates/:/tmp/dms/custom-certs/:ro
- ./docker-data/dms/mail-data/:/var/mail/
- ./docker-data/dms/mail-state/:/var/mail-state/
- ./docker-data/dms/mail-logs/:/var/log/mail/
- ./docker-data/dms/config/:/tmp/docker-mailserver/
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped
stop_grace_period: 1m
cap_add:
- NET_ADMIN
healthcheck:
test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
timeout: 3s
retries: 0Thanks in advance for the assist. |
Beta Was this translation helpful? Give feedback.
-
This is likely because the connection is going through the docker network gateway (
These two similar errors are about the same issue. They cannot verify your custom cert as the CA is not known. The client (containers?) would need to have the CA used to sign your certificate in their trust stores to trust the certificate you've configured for DMS. Normally this is a non-issue as your certificate is signed by a CA already in the trust store like LetsEncrypt. If you are new to this, you'll want to gain a better understanding of how to work with your own internal certificates. This isn't likely to be a DMS specific issue. Ensure that you're not using self-signed certificates (no root CA used to establish trust), once you've provisioned the certs correctly and any client has the signing CA in their trust stores they should be able to verify without an issue. Some guidance for troubleshooting along the wayIn the DMS test suite, we use timeout 1 openssl s_client -connect mail.example.com:587 -starttls smtp -CAfile '/path/to/ca-cert.pem'You can run that locally or in the container (with That should then have some output that includes After that, you'll want to learn how to add your CA cert to your trust stores. This varies by OS distro, so might differ per container you have and you may need to run some commands to update the trust store beyond adding your CA cert there. When you've done that successfully, that |
Beta Was this translation helpful? Give feedback.
-
|
Hello @polarathene, Thank you for the information, there are a couple of things that are not clear to me. I'm using several containers inside the same docker, if I insert the
Is there a way in DockerMail to ignore TLS if connections are coming from private IPs or at least a whitelist to add the IP. Another thing that I want to check, is if all the apps and DockerMail are in the same docker network does that bypass the TLS requirements? I understand how certificates work, but this is my first time working with LetsEncrypt certificates not being run by the OS and yes by the proxy. Running by the OS it will insert the CA in the From my understanding the apps, mail servers, API, etc, should have the full chain certificate, usually a .pem, but in the variables for the several docker apps it seems that every app is only making "gets" to the .crt and .key, but in theory the .crt is also the CA which was copied to the trusted store. https://ubuntu.com/server/docs/install-a-root-ca-certificate-in-the-trust-store And yes the CA in theory was uploaded correctly to the trust store. For this reason I need a bit of help understanding how to make this viable without the certificates if private networking is in use or if all containers are in the same docker network. Only outgoing emails, communications, webservices or API are mandatory to have certificate signing, that the proxy handles it. In hopes this helps to have a cleared picture if what I'm facing and what I wish to accomplish. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry about the 2 month delay in a response, I missed this 😓 (I realize this is probably too late and you've probably figured it out or switched to another alternative) I haven't had time to go through the prior discussion again, so I might be repeating myself here or missing some context, sorry about that.
You shouldn't manually adjust $ docker run --rm -it --hostname example.test --add-host mail.example.test:1.2.3.4 alpine cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
1.2.3.4 mail.example.test
172.17.0.5 example.test example
Docker has it's own internal embedded DNS that it'll use to route to containers within the network (via compose service name, hostname, container name, etc). EDIT: I might be mistaken, and those are all added to The daemon can have a default DNS service configured, I can't recall if that is the equivalent to explicitly setting one on a container ( $ docker run --rm -it --dns 1.1.1.1 alpine cat /etc/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 1.1.1.1
# Based on host file: '/etc/resolv.conf' (legacy)
# Overrides: [nameservers]So maybe keep that in mind as a potential gotcha to be aware of
Off the top of my head, I think you can do something like this but it might vary by service (Dovecot, Postfix, Rspamd, etc). We do have a It will allow you to bypass more than just TLS check however.
I think I just covered that. TLS shouldn't be necessary for port 25 to receive or send. It is expected for the authenticated ports to ensure your credentials aren't sent unencrypted over the network. If that isn't a concern for you, you could choose not to use TLS at all. --
We have fairly good coverage on this topic with our docs? Along with guides for automating renewals. Is there something missing? For LetsEncrypt, be sure to handle this correctly. We have docs on this too regarding mounting a volume from the host so that it can resolve symlinks correctly (common config mistake from users).
It's been a while since I refreshed on this topic, but DMS should only need the custom root CA certs added if it has any internal service making a request where that trust needs to be verified, which I think would be to a service external of DMS (eg: another DMS instance acting as a relay host). Otherwise, you just need to provide the public cert provisioned for DMS to use by that CA. Any client connecting to DMS would then need that custom CA root cert in the clients trust store (either the client software supports it's own trust store, or it uses the one from the OS), and when connecting to DMS, the public cert will be provided (this should contain any additional intermediate certs needed for the client to resolve the trust chain). You can find my docs on how we provisioned certs for DMS test suite. The Smallstep CLI tool makes it quite easy to provision the root CA and leaf cert files. You could add additional intermediate certs into the mix there too if you need to test configuring for such. We use those cert files for test coverage in:
While the container startup configures TLS certs for Dovecot and Postfix with this helper script. The public key (cert) assigned to these services to use, can contain the full chain, but for it to be possible to verify the client itself still needs the CA cert in it's trust store, it can't solely trust DMS as the only source of information to verify properly, so this certificate only needs to provide the details for DMS cert that the client wouldn't have (the leaf cert).
Is there a reason you can't provision certificates for these connections to use instead?
How would you define outgoing mails? A mail client submits mail to DMS to send outbound, are you expecting the proxy to handle TLS correctly for this mail client connecting to DMS, with that mail client not being in the private network or as a container on that docker network? Do you already have the proxy handling this for you?
Your proxy should just pass the TLS connection over to DMS to terminate. You can still provision the certificate via the proxy if that works for you, and have DMS use that. Alternative just bypass the proxy and expose the DMS ports directly, if you don't have more than one DMS instance, you probably don't have much use for the proxy. If you insist on the proxy, keep in mind of the client IP caveats this causes, you'll want to use the PROXY protocol.
I was a little confused, but that's likely my fault for not going through the full discussion again. Unfortunately I lack the time for assisting you better, but I do know that we have a working proxy guide with Traefik and PROXY protocol.
Regarding the TLS requirement, if verification is the only concern you want to ignore, I think your mail client should allow you to continue with TLS connections that aren't trusted. That's a bit better than trying to bypass TLS to rely on unencrypted connections for trusted clients? |
Beta Was this translation helpful? Give feedback.
-
|
hello @polarathene, Thank you for the explanation. I've decided to simplify the setup. Instead of using the proxy, I've configured NAT rules and directly implemented Let's Encrypt in the docker-compose. I initially wanted to experiment with new configurations for a more refined setup, but it proved to be too challenging and after extensive research, I couldn't find a solution. To enhance security, I placed the containers that need to send emails on the same Docker network as docker-mail and opened port 25. I created a network specifically for this purpose. While port 25 is generally considered a security risk, using it internally should pose no issues. Your explanation was exactly what I needed. If this were for a professional or enterprise mail server, I would need to reconfigure based on the new information. However, since this is for personal use, everything is working fine without being blocked by providers. Thank you again for your time. This will likely be useful for someone facing the same scenario I did. |
Beta Was this translation helpful? Give feedback.
Sorry about the 2 month delay in a response, I missed this 😓 (I realize this is probably too late and you've probably figured it out or switched to another alternative)
I haven't had time to go through the prior discussion again, so I might be repeating myself here or missing some context, sorry about that.
You shouldn't manually adjust
/etc/hostsin a container AFAIK as Docker itself manages that file, you might run into issues? Docker does provide a CLI option or Compose setting to add additional…