Docker Mailserver
How do I debug "SSL routines::wrong version number " #4503
Replies: 2 comments 9 replies
-
Start with a minimal reproduction example. I would suggest just a plain Docker container or with Docker Compose first to get that working well, then you can troubleshoot to the equivalent config in the helm chart. Generally you start with the bare minimum and slowly introduce any additional config until the problem appears, then you can better identify the cause. It can sometimes be a slow process, and while additional effort if you share your solution (especially if you contribute to docs), it can help others avoid that mistake (or resolve it faster). Basic DMS config
name: basic-dms
services:
dms:
image: ghcr.io/docker-mailserver/docker-mailserver:latest # :15.0
hostname: mail.example.test
environment:
# Minimize container startup time and reduce complexity:
ENABLE_AMAVIS: 0
ENABLE_OPENDKIM: 0
ENABLE_OPENDMARC: 0
ENABLE_POLICYD_SPF: 0
configs:
- source: dms-accounts
target: /tmp/docker-mailserver/postfix-accounts.cf
# NOTE:
# - `$$` is required to escape `$` from ENV interpolation (Docker Compose feature)
# - Both accounts have the same password: `secret`
configs:
dms-accounts:
content: |
jane.doe@example.test|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.
john.doe@example.test|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.
services:
dms:
environment:
SSL_TYPE: manual
SSL_KEY_PATH: /srv/tls/key.pem
SSL_CERT_PATH: /srv/tls/cert.pem
configs:
- source: tls-cert
target: /srv/tls/cert.pem
- source: tls-key
target: /srv/tls/key.pem
# Optional - Allows clients in the container to verify cert trust with the CA that signed it:
#- source: tls-ca-cert
# target: /usr/local/share/ca-certificates/ca-smallstep.crt
#- source: script-trust-private-ca
# target: /tmp/docker-mailserver/user-patches.sh
configs:
script-trust-private-ca:
content: |
#!/bin/bash
update-ca-certificates
# Example ECDSA cert files for testing locally:
tls-ca-cert:
content: |
-----BEGIN CERTIFICATE-----
MIIBfTCCASKgAwIBAgIRAMAZttlRlkcuSun0yV0z4RwwCgYIKoZIzj0EAwIwHDEa
MBgGA1UEAxMRU21hbGxzdGVwIFJvb3QgQ0EwHhcNMjEwMTAxMDAwMDAwWhcNMzEw
MTAxMDAwMDAwWjAcMRowGAYDVQQDExFTbWFsbHN0ZXAgUm9vdCBDQTBZMBMGByqG
SM49AgEGCCqGSM49AwEHA0IABJX2hCtoK3+bM5I3rmyApXLJ1gOcVhtoSSwM8XXR
SEl25Kkc0n6mINuMK8UrBkiBUgexf6CYayx3xVr9TmMkg4KjRTBDMA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEBMB0GA1UdDgQWBBQD8sBrApbyYyqU
y+/TlwGynx2V5jAKBggqhkjOPQQDAgNJADBGAiEAi8N2eOETI+6hY3+G+kzNMd3K
Sd3Ke8b++/nlwr5Fb/sCIQDYAjpKp/MpTDWICeHC2tcB5ptxoTdWkTBuG4rKcktA
0w==
-----END CERTIFICATE-----
tls-key:
content: |
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIOc6wqZmSDmT336K4O26dMk1RCVc0+cmnsO2eK4P5K5yoAoGCCqGSM49
AwEHoUQDQgAEFOWNgekKKvUZE89vJ7henUYxODYIvCiHitRc2ylwttjqt1KUY1cp
q3jof2fhURHfBUH3dHPXLHig5V9Jw5gqeg==
-----END EC PRIVATE KEY-----
tls-cert:
content: |
-----BEGIN CERTIFICATE-----
MIIB9DCCAZqgAwIBAgIQE53a/y2c//YXRsz2kLm6gDAKBggqhkjOPQQDAjAcMRow
GAYDVQQDExFTbWFsbHN0ZXAgUm9vdCBDQTAeFw0yMTAxMDEwMDAwMDBaFw0zMTAx
MDEwMDAwMDBaMBkxFzAVBgNVBAMTDlNtYWxsc3RlcCBMZWFmMFkwEwYHKoZIzj0C
AQYIKoZIzj0DAQcDQgAEFOWNgekKKvUZE89vJ7henUYxODYIvCiHitRc2ylwttjq
t1KUY1cpq3jof2fhURHfBUH3dHPXLHig5V9Jw5gqeqOBwDCBvTAOBgNVHQ8BAf8E
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSz
w74g+O6dcBbwienD70D8A9ESmDAfBgNVHSMEGDAWgBQD8sBrApbyYyqUy+/TlwGy
nx2V5jBMBgNVHREERTBDghFtYWlsLmV4YW1wbGUudGVzdIIVbWFpbC5kZXN0aW5h
dGlvbi50ZXN0ghdzbXRwLnJlbGF5LXNlcnZpY2UudGVzdDAKBggqhkjOPQQDAgNI
ADBFAiEAoety5oClZtuBMkvlUIWRmWlyg1VIOZ544LSEbplsIhcCIHb6awMwNdXP
m/xHjFkuwH1+UjDDRW53Ih7KZoLrQ6Cp
-----END CERTIFICATE-----Test commandsExample swaks commands. You can remove the # Start DMS:
docker compose up -d --force-recreate
# Shell into the container to use swaks CLI:
docker compose exec -it dms bash
# Send test mail to port 25 via plain text (unencrypted):
swaks --server mail.example.test --port 25 --from jane.doe@example.test --to john.doe@example.test --silentThis time with TLS, we'll specify both YAML configs this time to merge the TLS config into the main # Start DMS again, now with TLS enabled:
docker compose --file compose.yaml --file with-tls.yaml up -d --force-recreate
docker compose exec -it dms bash
# Sending test mail to port 25 via STARTTLS (encrypted):
swaks --server mail.example.test --port 25 -tls --from jane.doe@example.test --to john.doe@example.test --silentThis example was a little simplified because we skipped DNS records and we also did it all within the same container and system. However that seems to be sufficient for the failure you were running into, so it might not need to be complicated beyond that. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! I've uninstalled docker-mailserver and re-installed it, and now some emails are accepted. I've checked that there is a PEM certificate and PEM RSA private key at the locations specified by Using the directions at the DMS TLS docs I have verified the certificate is ok. Now emails sent to port 25 on the pod are accepted: swaks -tls --server docker-mailserver-6f79f49b8-9p9rt --port 25 --from second@hominidsoftware.com --to first@hominidsoftware.com --helo dms.hominidsoftware.com --auth-optional --auth-user secondbut TLS appears to fail because the pod DNS name doesn't match my certificate: Sending the same command to port 587 on the pod gets a similar message re: TLS, but authentication fails: Sending the same command to port 465 on the pod outright fails with timeout: The Helm chart creates this user-patches script to create proxy ports, so ports 25, 587 and 465 shouldn't have the PROXY Protocol enabled, as the docs say. user-patches.sh: |
#!/bin/bash
# Make sure to keep this file in sync with https://github.com/docker-mailserver/docker-mailserver/blob/master/target/postfix/master.cf!
cat <<EOS >> /etc/postfix/master.cf
# Submission with proxy
10587 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
-o smtpd_upstream_proxy_protocol=haproxy
# Submissions with proxy
10465 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
-o smtpd_upstream_proxy_protocol=haproxy
# Smtp with proxy
12525 inet n - n - 1 postscreen
-o syslog_name=postfix/smtp-proxy
-o postscreen_upstream_proxy_protocol=haproxy
-o postscreen_cache_map=btree:$data_directory/postscreen_10025_cache
EOSI have documentation for how to configure HAProxy ingress controller to use or not use the PROXY Protocol to upstream servers, and I think I've followed it, but I'm still trying to track down what's happening there. |
Beta Was this translation helpful? Give feedback.
-
Ok, but this is because the hostname you are connecting to with swaks is set via I guess that is a tricky one in k8s if you cannot adjust the DNS name that your internal containers would connect to DMS container through to match the certificate. If you're able to add an entry to If you're able to provision a certificate with the hostname that would work too, but a single DNS label isn't an FQDN I believe, so no public CA should support that. Technically you could provide a 2nd certificate, but I'm not sure how well that works when Postfix / Dovecot are configured for the public FQDN. Generally it should be fine to skip verification internally, even publicly MTAs won't enforce it between each other on port 25. Only really matters there for ports behind authentication. If the MTA is using MTA-STS then TLS can be enforced, but I'm not sure if that also enforces verification on port 25 🤔
That should probably be This doesn't matter much beyond that, just making a mention of it.
Are you also using If you were provisioning with a public CA and connecting from public into ingress that should be working correctly? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, again! Sorry, should have earlier included my certificate: dms-hominidsoftware-com
deployment:
env:
OVERRIDE_HOSTNAME: dms.hominidsoftware.com
TZ: America/Toronto
resources:
requests:
cpu: "750m"
service:
annotations:
haproxy.org/send-proxy-protocol: proxy-v2The certificate is created as here: https://github.com/docker-mailserver/docker-mailserver-helm/blob/master/charts/docker-mailserver/README.md#getting-started The resource request is just to prevent cluster autoscaling, which would be a distraction. The annotation is the same as used in my Ingresses for my non-mail services, and the HAProxy ingress controller docs say it works the same on a Service upstream from the controller: https://www.haproxy.com/documentation/kubernetes-ingress/enterprise/configuration-reference/service/#send-proxy-protocol With the above configuration of the proxy ports, PROXY Protocol 2 [binary] is required, yes? The certificate CN is In Unfortunately, authentication still fails with: The value for setup email add <EMAIL ADDRESS> [<PASSWORD>] For the different auth-types, I get |
Beta Was this translation helpful? Give feedback.
-
Just to share one observation I've noticed, while the The check in our default config for Postfix only raises a warning in logs, but a report from some time ago said it also resulted in mail from such a client as being considered spam. I am curious how you went about modifying
It should be no different apart from the change in port and using |
Beta Was this translation helpful? Give feedback.
-
For testing, I just exec-ed into the container and edited /etc/hosts directly. For production, normally you'd create ConfigMap and volumeMount, but that's a whole directory, and there's a lot in /etc you wouldn't want to change, so I'm not sure what contortions you'd have to go to. |
Beta Was this translation helpful? Give feedback.
-
|
You setup looks similar to mine. I would say make it work first without the proxy protocol. Once that works, then you know the host name and certificate line up. It has been quite a while since I looked at this, but port 465 needed special handling:
See: https://www.postfix.org/postconf.5.html And: Maybe HaProxy is doing something different than nginx (https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/) which is what I am using to forward ports to the k8 cluster? |
Beta Was this translation helpful? Give feedback.
-
This is set for port 10465, the port for submissions w/ mandatory TLS and the PROXY Protocol
If I understand correctly, this is for outbound connections to other SMTP servers.
The data in the ConfigMap for TCP connections is identical: apiVersion: v1
kind: ConfigMap
metadata:
name: haproxy-controller-tcp
namespace: haproxy-controller
labels:
app.kubernetes.io/name: kubernetes-ingress
app.kubernetes.io/instance: haproxy-controller
data:
12525: "mail/docker-mailserver:12525"
10465: "mail/docker-mailserver:10465"
10587: "mail/docker-mailserver:10587"
10993: "mail/docker-mailserver:10993" |
Beta Was this translation helpful? Give feedback.
-
|
The Helm chart currently appends this to /etc/postfix/master.cf Do I understand correctly that https://docker-mailserver.github.io/docker-mailserver/latest/examples/tutorials/mailserver-behind-proxy/ says the last line should be or should it be |
Beta Was this translation helpful? Give feedback.
-
|
I don't think the name difference there should matter much. I recall our docs guide shares the postscreen cache with both variants (ports 25 and 12525), but the helm chart only set it for the added port because of the way they approached configuration differently. I explain this at the end of this comment on the helm repo back in April, but I don't think that feedback was applied. I just looked at our docs advice, and we are using UPDATE: Created an issue for this at the helm repo: docker-mailserver/docker-mailserver-helm#173 |
Beta Was this translation helpful? Give feedback.
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 just set up the current version of docker-mailserver, using the Helm chart
docker-mailserver-4.2.1.Kubernetes versions are:
My cluster is managed by DigitalOcean and has one node at present.
The logs appeared normal until I used
setup email addto create the first account. Then I get an endless cycle of these log messages:setup email listgives me a list of accounts without any errors.When I use
swaksto a just-created user from a shell in the docker-mailserver pod:I get the error
Recipient address rejected: User unknown in virtual mailbox tableand the log containsdovecot: auth: passwd-file(skapi@new.hominidsoftware.com): unknown useramid all the stuff above.A second email using swaks is rejected with
554 5.7.1 Spam message rejectedand that also appears in the log amid all the stuff above.I didn't see anything that appears relevant in https://docker-mailserver.github.io/docker-mailserver/latest/faq/
How do i go about debugging this?
Beta Was this translation helpful? Give feedback.
All reactions