Hi I'm having trouble recently with my Mailcow server and seemingly SSL certs. I unable to connect to the server via Thunderbird but sending and receiving still seemed to work fine through the webmail. Though applications I have trying to send/receive emails through this server are not working either. In the Postfix logs I am regularly getting `warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:` I'm using SSL certs from my NGINX Proxy Manager instance, and using the same process as I have been for a long time to move the certificates across. I think it's dovecot not picking up the certificate for some reason? but I've not been able to find anything that has helped me with this so far. Dovecot logs show no errors or warnings at all. My SSL cert and privkey are in /opt/mailcow-dockerized/data/assets/ssl and /opt/mailcow-dockerized/data/assets/ssl/HOSTNAME.TLD as cert.pem and key.pem I have put the outputs of a few commands that seem to show something below. ``` bash helper-scripts/expiry-dates.sh Could not read certificate from Unable to load certificate TLS expiry dates: Postfix: Feb 12 07:48:19 2026 GMT Dovecot: Nginx: Feb 7 04:36:36 2026 GMT ``` ``` openssl s_client -starttls imap -connect HOSTNAME.TLD:993 | openssl x509 -noout -text 40278DDDB07E0000:error:8000006F:system library:BIO_connect:Connection refused:../crypto/bio/bio_sock2.c:114:calling connect() 40278DDDB07E0000:error:10000067:BIO routines:BIO_connect:connect error:../crypto/bio/bio_sock2.c:116: connect:errno=111 Could not read certificate from Unable to load certificate ``` ``` openssl s_client -starttls smtp -connect HOSTNAME.TLD:587 | openssl x509 -noout -text depth=0 CN = HOSTNAME.TLD verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = HOSTNAME.TLD verify error:num=21:unable to verify the first certificate verify return:1 depth=0 CN = HOSTNAME.TLD verify return:1 250 DSN Certificate: Data: Version: 3 (0x2) Serial Number: 05:a0:ad:77:47:0e:b0:88:ff:f2:cc:c0:bc:93:df:cd:d3:16 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = Let's Encrypt, CN = E8 Validity Not Before: Nov 14 07:48:20 2025 GMT Not After : Feb 12 07:48:19 2026 GMT Subject: CN = HOSTNAME.TLD Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:6a:36:1e:31:8f:3c:4a:e3:60:2f:fb:83:c8:a1: 34:89:db:ec:93:c2:49:8e:10:cd:10:a0:31:d7:7f: 54:d8:8c:61:75:37:3b:c1:fc:b8:62:2a:c8:a1:a1: fb:a2:1d:ca:94:4f:19:cd:d3:f1:74:36:db:8f:ee: e6:1b:14:bc:d4:d2:18:39:03:56:76:a0:08:95:20: 63:34:75:8a:c2:01:fa:4f:af:f6:f6:6c:b8:96:f8: 94:3f:15:60:6a:91:59 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: CD:62:C6:70:F9:8F:11:AB:75:83:0C:B5:7C:66:2B:69:A3:29:49:6D X509v3 Authority Key Identifier: 8F:0D:13:A2:F6:2E:7E:D1:50:6C:33:18:38:5D:59:8E:23:72:91:CA Authority Information Access: CA Issuers - URI:http://e8.i.lencr.org/ X509v3 Subject Alternative Name: DNS:HOSTNAME.TLD X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 X509v3 CRL Distribution Points: Full Name: URI:http://e8.c.lencr.org/23.crl CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : CB:38:F7:15:89:7C:84:A1:44:5F:5B:C1:DD:FB:C9:6E: F2:9A:59:CD:47:0A:69:05:85:B0:CB:14:C3:14:58:E7 Timestamp : Nov 14 08:46:50.960 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 30:44:02:20:77:07:13:A2:E3:E7:3D:54:B6:BB:5F:E0: 62:CF:66:6B:27:4A:DB:E1:B9:A9:33:55:F7:60:F9:F0: 86:FE:1B:58:02:20:7D:63:25:3E:2C:0D:9A:24:DC:1E: 5C:77:4B:B1:15:B7:CC:36:9E:5F:37:9B:52:44:D2:F7: 31:72:7A:5E:E9:DD Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 49:9C:9B:69:DE:1D:7C:EC:FC:36:DE:CD:87:64:A6:B8: 5B:AF:0A:87:80:19:D1:55:52:FB:E9:EB:29:DD:F8:C3 Timestamp : Nov 14 08:46:50.949 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:70:8F:F0:33:5E:A4:16:C6:F8:3A:D8:11: A6:4A:76:80:8B:65:B5:09:26:66:93:66:D8:50:50:E4: AA:FC:49:A5:02:21:00:D0:A6:E3:C1:6D:45:72:27:32: 35:0D:04:22:59:29:E8:B5:BC:19:63:79:AF:6C:2B:BD: 88:BA:AC:92:60:FF:C9 Signature Algorithm: ecdsa-with-SHA384 Signature Value: 30:65:02:30:55:a9:a5:f0:2b:b0:31:59:45:ca:26:5b:79:3b: 35:2e:1e:c5:54:f1:bf:f8:3b:f0:b8:fe:97:e8:2e:f6:6f:98: f0:5b:b4:56:16:ca:15:5e:38:2d:17:42:fc:22:e7:80:02:31: 00:8f:a6:91:00:2f:c0:44:f6:87:79:69:c0:a5:22:b0:a1:91: ce:fb:99:40:8b:a9:46:6a:de:7e:58:5e:67:92:b3:e7:81:85: 30:a5:01:4b:89:18:df:f3:19:4c:1f:19:94 ```

Keys seems to be newly rotated,.. ``` Not Before: Nov 14 07:48:20 2025 GMT Not After : Feb 12 07:48:19 2026 GMT ``` did you made restart? or down and up whole stack?

Without sharing your mailcow server host address its difficult to say whats the problem. Also the log files of Thunderbird and exact error messages would help. Maybe you have not all required DNS names (SAN) in your Nginx Proxy Manager certificates? https://docs.mailcow.email/getstarted/prerequisite-dns/#the-minimal-dns-configuration

@"ETNyx"#p28913 I've tried both restarting the whole VM and just taking the stack up and down, with a few different certificates over a few days, freshly renewed each time to try and rule something out from that. @"esackbauer"#p28914 all I get when trying to add an account in Thunderbird is "Thunderbird failed to find the settings for your email account" which isn't at all helpful. Previously added accounts just don't load anything and do not show any errors either. Account details are definitely correct as the work in the webmail. Plus they used to work in thunderbird before what ever happened. As for the DNS, it's all still there too. This has been working for over a year without issues prior to this. server is on mail2.website-inator.com if that helps

> @"fmaddict"#p28916 “Thunderbird failed to find the settings for your email account” which isn’t at all helpful. It is helpful as it indicates you are missing the autodiscover.website-inator.com and autoconfig.website-inator.com from your certificate. And checking your certificate on mail2.website-inator.com confirms this.

@"esackbauer"#p28918 I am still getting the same error on manual configuration, which shoudn't rely on the autos. The DNS records are there for them anyway. I've been swapping between trying wildcard cert and for the specific URL for testing, and had left it on the specific. It's back to wildcard and the issues remain.

> @"fmaddict"#p28920 the same error on manual configuration, Could be that Thunderbird tries to overrule it. Maybe you have in Thunderbird settings the experimenal new account configuration activated? Try to deactivate it. > @"fmaddict"#p28920 The DNS records are there for them anyway. That is another problem, if Thunderbird finds the DNS names, it expects a proper certificate. > @"fmaddict"#p28920 I’ve been swapping between trying wildcard cert Wildcard certs are not supported by mailcows dovecot and postfix as far as i know.

> @"esackbauer"#p28921 Could be that Thunderbird tries to overrule it. Maybe you have in Thunderbird settings the experimenal new account configuration activated? Try to deactivate it. The experimental setting is not enabled. Also as previously mentioned other software trying to send emails through this server are having issues with their previously working set ups. > @"esackbauer"#p28921 Wildcard certs are not supported by mailcows dovecot and postfix as far as i know. All the information I'm finding is saying otherwise. Either way, I think the bigger issue here is why is this error coming up in postfix logs. This isn't just about Thunderbird setup, I only mentioned that as a symptom that I have noticed. Also when running the expiry-dates.sh helper script, why does Dovecot not show a certificate at all?

Maybe the certificate file is incomplete. As per [documentation](https://docs.mailcow.email/post_installation/firststeps-ssl/#how-to-use-your-own-certificate): > save the **combined certificate** (containing the certificate **and intermediate CA/root CA if any**) to data/assets/ssl/cert.pem and the corresponding key to data/assets/ssl/key.pem.

> @"esackbauer"#p28923 Maybe the certificate file is incomplete. As per [![](https://community.mailcow.email/api/kilowhat-rich-embeds/proxy?url=https%3A%2F%2Fdocs.mailcow.email%2Fassets%2Fimages%2Ffavicon.png) documentation![](https://community.mailcow.email/api/kilowhat-rich-embeds/proxy?url=https%3A%2F%2Fdocs.mailcow.email%2Fassets%2Fimages%2Ffavicon.png) docs.mailcow.emailAdvanced SSL - mailcow: dockerized documentationNone ![](https://community.mailcow.email/api/kilowhat-rich-embeds/proxy?url=https%3A%2F%2Fdocs.mailcow.email%2Fassets%2Fimages%2Fsocial%2Fpost_installation%2Ffirststeps-ssl.en.png)](https://docs.mailcow.email/post_installation/firststeps-ssl/#how-to-use-your-own-certificate): The same issues exist wether using the fullchain.pem, or cert.pem from what's downloaded from NGINX proxy manager. Historically using the cert.pem has been fine. When using chain.pem from this download the containers do not start properly. If the certificate file was incomplete I would have expected the inbuilt nginx and postfix to have an issue reading it, which they don't.

> @"fmaddict"#p28910 TLS expiry dates: > Postfix: Feb 12 07:48:19 2026 GMT > Dovecot: > Nginx: Feb 7 04:36:36 2026 GMT Could you explain why the certificates have different expiry dates?

SSL Bad Certificate warning

ETNyx

Yes, this is line from your ls-la

-rw-rw-r-- 1 vetinari vetinari 2908 Nov 16 09:04 cert.pem

there are wrong permissions first part -rw-rw-r-- should be -rw-r--r-- than vetinari vetinari should be root root to fix this you need to always maintaining your stack as root, so on your MC host use sudo su - than check your umask should output 0022. Than you can copy your certs for example using scp from your remote server where is you acme client. Than if you make ls-la again you should see simillar to this:

ls -la
total 24
drwxr-xr-x 3 root     root     4096 Nov 16 09:04 .
drwxr-xr-x 7 root     root     4096 Nov 16 09:03 ..
-rw-r--r-- 1 root     root        2908 Nov 16 09:04 cert.pem
-rw-r--r-- 1 root     root      424 Nov  9 05:46 dhparams.pem
-rw-r--r-- 1 root     root      306 Nov 16 09:04 key.pem

Hope this is little bit straight forward, if not please feed my response to AI hope it can fix my bad english for you :-)

fmaddict

ETNyx Okay, thank you. I did get most of it.

total 24
drwxr-xr-x 3 root root 4096 Nov 16 09:47 .
drwxr-xr-x 7 root root 4096 Nov 16 09:03 ..
-rw-r--r-- 1 root root 2908 Nov  4 06:42 cert.pem
-rw-r--r-- 1 root root  424 Nov  9 05:46 dhparams.pem
-rw-r--r-- 1 root root  306 Nov  4 06:42 key.pem
drwxr-xr-x 2 root root 4096 Nov 14 08:51 mail2.website-inator.com

is the output now

I’ve taken the stack down and back up, but it’s no longer loading.

bash helper-scripts/expiry-dates.sh
Could not read certificate from <stdin>
Unable to load certificate
Could not read certificate from <stdin>
Unable to load certificate
TLS expiry dates:
Postfix: 
Dovecot: 
Nginx:   Feb 12 07:48:19 2026 GMT

And this is the output of that helper script

[unknown] but it’s no longer loading.

Clarification on this, mean the web interface isn’t loading.

[unknown] but it’s no longer loading.

Clarification on this, mean the web interface isn’t loading.

ETNyx

Ok now ls-la looks fine, after down and up did you check docker compose exec postfix-mailcow ls -la /etc/ssl/mail/ it’s the same right?

Next step is to inspect logs so docker compose logs postfix-mailcow check for your last restart(up) should have some error or post reasonable amount of lines here

fmaddict

ETNyx

docker compose exec postfix-mailcow ls -la /etc/ssl/mail/
total 24
drwxr-xr-x 3 root root 4096 Nov 16 20:17 .
drwxr-xr-x 1 root root 4096 Nov 16 20:58 ..
-rw-r--r-- 1 root root 2908 Nov  4 17:12 cert.pem
-rw-r--r-- 1 root root  424 Nov  9 16:16 dhparams.pem
-rw-r--r-- 1 root root  306 Nov  4 17:12 key.pem
drwxr-xr-x 2 root root 4096 Nov 14 19:21 mail2.website-inator.com

Yes so this is the same now.

but in the postfix-mailcow logs we still have the same error

warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:

And this is coming up every time something trys to connect via SMTP

ETNyx

Hmm i did some basic checks from outside should be ok, even expity-dates.sh shoud be fine now (for postfix) echo | openssl s_client -connect mail2.website-inator.com:587 -starttls smtp 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d "=" -f 2 > Feb 2 05:44:11 2026 GMT can you post let’s say 25 lines before this error to get some context?

fmaddict

a few more than 25 here, but you can see how it just repeats it every time a client is connecting

docker compose logs postfix-mailcow
postfix-mailcow-1  | 2025-11-16 20:58:30,169 INFO Set uid to user 0 succeeded
postfix-mailcow-1  | 2025-11-16 20:58:30,170 INFO supervisord started with pid 1
postfix-mailcow-1  | 2025-11-16 20:58:31,172 INFO spawned: 'processes' with pid 8
postfix-mailcow-1  | 2025-11-16 20:58:31,175 INFO spawned: 'postfix' with pid 9
postfix-mailcow-1  | 2025-11-16 20:58:31,177 INFO spawned: 'syslog-ng' with pid 10
postfix-mailcow-1  | Uptime: 32  Threads: 5  Questions: 346  Slow queries: 0  Opens: 50  Open tables: 43  Queries per second avg: 10.812
postfix-mailcow-1  | Nov 16 20:58:31 fbe8f0bb937d syslog-ng[10]: syslog-ng starting up; version='3.38.1'
postfix-mailcow-1  | Checking if ASN for your IP is listed for Spamhaus Bad ASN List...
postfix-mailcow-1  | 2025-11-16 20:58:32,233 INFO success: processes entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
postfix-mailcow-1  | 2025-11-16 20:58:32,233 INFO success: syslog-ng entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
postfix-mailcow-1  | The AS of your IP is NOT listed as a banned AS from Spamhaus!
postfix-mailcow-1  | Using the open Spamhaus blocklists.
postfix-mailcow-1  | chown: cannot access '/usr/share/man/man1/mailq.1.gz': No such file or directory
postfix-mailcow-1  | Nov 16 20:58:34 fbe8f0bb937d postfix/postfix-script[367]: starting the Postfix mail system
postfix-mailcow-1  | Nov 16 20:58:34 fbe8f0bb937d postfix/master[369]: daemon started -- version 3.7.11, configuration /opt/postfix/conf
postfix-mailcow-1  | 2025-11-16 20:58:41,572 INFO success: postfix entered RUNNING state, process has stayed up for > than 10 seconds (startsecs)
postfix-mailcow-1  | Nov 16 20:59:14 fbe8f0bb937d postfix/postscreen[383]: cache proxy:btree:/var/lib/postfix/postscreen_cache full cleanup: retained=0 dropped=0 entries
postfix-mailcow-1  | Nov 16 20:59:14 fbe8f0bb937d postfix/postscreen[383]: CONNECT from [185.196.11.84]:61234 to [172.22.1.253]:25
postfix-mailcow-1  | Nov 16 20:59:14 fbe8f0bb937d whitelist_forwardinghosts: Look up 185.196.11.84 on whitelist, result 200 DUNNO
postfix-mailcow-1  | Nov 16 20:59:15 fbe8f0bb937d postfix/postscreen[383]: PREGREET 11 after 0.28 from [185.196.11.84]:61234: EHLO User\r\n
postfix-mailcow-1  | Nov 16 20:59:15 fbe8f0bb937d postfix/dnsblog[401]: warning: dnsblog_query: lookup error for DNS query 84.11.196.185.b.barracudacentral.org: Host or domain name not found. Name service error for name=84.11.196.185.b.barracudacentral.org type=A: Host not found, try again
postfix-mailcow-1  | Nov 16 20:59:15 fbe8f0bb937d postfix/dnsblog[399]: addr 185.196.11.84 listed by domain zen.spamhaus.org as 127.0.0.9
postfix-mailcow-1  | Nov 16 20:59:15 fbe8f0bb937d postfix/dnsblog[399]: addr 185.196.11.84 listed by domain zen.spamhaus.org as 127.0.0.3
postfix-mailcow-1  | Nov 16 20:59:15 fbe8f0bb937d postfix/dnsblog[399]: addr 185.196.11.84 listed by domain zen.spamhaus.org as 127.0.0.4
postfix-mailcow-1  | Nov 16 20:59:15 fbe8f0bb937d postfix/dnsblog[399]: addr 185.196.11.84 listed by domain zen.spamhaus.org as 127.0.0.2
postfix-mailcow-1  | Nov 16 20:59:15 fbe8f0bb937d postfix/dnsblog[397]: addr 185.196.11.84 listed by domain bl.mailspike.net as 127.0.0.2
postfix-mailcow-1  | Nov 16 20:59:16 fbe8f0bb937d postfix/postscreen[383]: DNSBL rank 18 for [185.196.11.84]:61234
postfix-mailcow-1  | Nov 16 20:59:16 fbe8f0bb937d postfix/postscreen[383]: DISCONNECT [185.196.11.84]:61234
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d postfix/postscreen[383]: CONNECT from [213.209.157.165]:64023 to [172.22.1.253]:25
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d whitelist_forwardinghosts: Look up 213.209.157.165 on whitelist, result 200 DUNNO
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d postfix/dnsblog[394]: addr 213.209.157.165 listed by domain zen.spamhaus.org as 127.0.0.3
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d postfix/dnsblog[394]: addr 213.209.157.165 listed by domain zen.spamhaus.org as 127.0.0.4
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d postfix/dnsblog[394]: addr 213.209.157.165 listed by domain zen.spamhaus.org as 127.0.0.2
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d postfix/dnsblog[394]: addr 213.209.157.165 listed by domain zen.spamhaus.org as 127.0.0.9
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d postfix/postscreen[383]: PREGREET 11 after 0.35 from [213.209.157.165]:64023: EHLO User\r\n
postfix-mailcow-1  | Nov 16 20:59:28 fbe8f0bb937d postfix/dnsblog[400]: addr 213.209.157.165 listed by domain bl.mailspike.net as 127.0.0.2
postfix-mailcow-1  | Nov 16 20:59:29 fbe8f0bb937d postfix/dnsblog[397]: addr 213.209.157.165 listed by domain hostkarma.junkemailfilter.com as 127.0.0.2
postfix-mailcow-1  | Nov 16 20:59:29 fbe8f0bb937d postfix/dnsblog[397]: addr 213.209.157.165 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
postfix-mailcow-1  | Nov 16 20:59:29 fbe8f0bb937d postfix/postscreen[383]: DNSBL rank 21 for [213.209.157.165]:64023
postfix-mailcow-1  | Nov 16 20:59:29 fbe8f0bb937d postfix/postscreen[383]: DISCONNECT [213.209.157.165]:64023
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: connect from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: SSL_accept error from unknown[10.32.8.221]: -1
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: lost connection after CONNECT from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: disconnect from unknown[10.32.8.221] commands=0/0
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: connect from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: SSL_accept error from unknown[10.32.8.221]: -1
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: lost connection after CONNECT from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: disconnect from unknown[10.32.8.221] commands=0/0
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: connect from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: SSL_accept error from unknown[10.32.8.221]: -1
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: lost connection after CONNECT from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 20:59:30 fbe8f0bb937d postfix/smtps/smtpd[408]: disconnect from unknown[10.32.8.221] commands=0/0
postfix-mailcow-1  | Nov 16 21:00:17 fbe8f0bb937d postfix/postscreen[383]: CONNECT from [10.32.8.204]:49244 to [172.22.1.253]:25
postfix-mailcow-1  | Nov 16 21:00:17 fbe8f0bb937d postfix/postscreen[383]: ALLOWLISTED [10.32.8.204]:49244
postfix-mailcow-1  | Nov 16 21:00:17 fbe8f0bb937d postfix/smtpd[410]: connect from unknown[10.32.8.204]
postfix-mailcow-1  | Nov 16 21:00:17 fbe8f0bb937d postfix/smtpd[410]: TLS SNI mail2.website-inator.com from unknown[10.32.8.204] not matched, using default chain
postfix-mailcow-1  | Nov 16 21:00:17 fbe8f0bb937d postfix/smtpd[410]: Anonymous TLS connection established from unknown[10.32.8.204]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384
postfix-mailcow-1  | Nov 16 21:00:17 fbe8f0bb937d postfix/smtpd[410]: lost connection after STARTTLS from unknown[10.32.8.204]
postfix-mailcow-1  | Nov 16 21:00:17 fbe8f0bb937d postfix/smtpd[410]: disconnect from unknown[10.32.8.204] ehlo=1 starttls=1 commands=2
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: connect from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: SSL_accept error from unknown[10.32.8.221]: -1
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: lost connection after CONNECT from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: disconnect from unknown[10.32.8.221] commands=0/0
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: connect from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: SSL_accept error from unknown[10.32.8.221]: -1
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: lost connection after CONNECT from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: disconnect from unknown[10.32.8.221] commands=0/0
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: connect from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: SSL_accept error from unknown[10.32.8.221]: -1
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: lost connection after CONNECT from unknown[10.32.8.221]
postfix-mailcow-1  | Nov 16 21:00:30 fbe8f0bb937d postfix/smtps/smtpd[408]: disconnect from unknown[10.32.8.221] commands=0/0

ETNyx

So those are incoming connection, I assume yours Thunderbird client since IP is private LAN type. So clients usually connecting over 465 port. I can not reach you over this port WRONG->openssl s_client -connect mail2.website-inator.com:465 -starttls smtp -showcerts any firewall blocking my connection?

Edit: sorry mistake in command, but still no response if you want to test than openssl s_client -connect mail2.website-inator.com:465 -showcerts

fmaddict

ETNyx That one receives the following

openssl s_client -connect mail2.website-inator.com:465 -showcerts
0023E1238F7F0000:error:8000006F:system library:BIO_connect:Connection refused:crypto/bio/bio_sock2.c:178:calling connect()
0023E1238F7F0000:error:10000067:BIO routines:BIO_connect:connect error:crypto/bio/bio_sock2.c:180:
connect:errno=111

ETNyx

Ok, from my point of view 25 and 587 are open and communicating, but 465 is not. This is intentional from your side? To diagnose further I would like to be able test this service from my side. Those 2 are ok, If i get an error on 465 server is most-likely to blame, if not your client is…

fmaddict

Ok so, yesterday night when fiddling with this (_24hours ago) a bunch of the emails from the software I noticed that wasn’t coming through, finally came through. Really not sure what changed that one.

As for the port 465 part I did find one of my docker containers misconfigured trying to talk to it on that port. So I’ve updated that and now that log entry seems to have been sorted too.
In the end that one seems to be unrelated to the main issue I noticed of another software’s emails not coming through.

The issues with Thunderbird accessing the accounts still remain, but as the service ones are now working I’m happy that that’s on the Thunderbird side and I can look into that more thoroughly when I have some time.

Thank you very much for your help, I’m really confused as to what made things start working again but hey, they are working again. So I’m very happy with that

« Previous Page