SMTP SNI problems

Feja111

I had 0Byte free disk space.
Than i had executed: “docker image prune”
It had given me 57Gigs of storage back. 🙂
But now, i can recieve mails and send mails via the SOGo panel but not sending mails via smtp:
warning: TLS library problem: error:1422E0EA:SSL routines:final_server_name:callback failed:../ssl/statem/extensions.c:1011:
warning: tls_server_sni_maps: smtp.feja111.de map lookup problem
warning: hash:/opt/postfix/conf/sni.map lookup error for "smtp.feja111.de"
warning: hash:/opt/postfix/conf/sni.map is unavailable. open database /opt/postfix/conf/sni.map.db: No such file or directory

esackbauer

Could be that those 2 files got corrupted? Restore it from a backup.

Feja111

How can i check/repair?

Feja111

I do not have created backups by my self.
I use a wildcard certificate (*.feja111.de and feja111.de)
The file looks like this:
root@3b70cc0d5e37:/# cat /opt/postfix/conf/sni.map autoconfig.fam.feja111.tk /etc/ssl/mail/autoconfig.fam.feja111.tk/key.pem /etc/ssl/mail/autoconfig.fam.feja111.tk/cert.pem autoconfig.feja111.tk /etc/ssl/mail/autoconfig.fam.feja111.tk/key.pem /etc/ssl/mail/autoconfig.fam.feja111.tk/cert.pem autodiscover.fam.feja111.tk /etc/ssl/mail/autoconfig.fam.feja111.tk/key.pem /etc/ssl/mail/autoconfig.fam.feja111.tk/cert.pem autodiscover.feja111.tk /etc/ssl/mail/autoconfig.fam.feja111.tk/key.pem /etc/ssl/mail/autoconfig.fam.feja111.tk/cert.pem autodiscover.mail.feja111.tk /etc/ssl/mail/autoconfig.fam.feja111.tk/key.pem /etc/ssl/mail/autoconfig.fam.feja111.tk/cert.pem

Feja111

Can i redeploy the mailcow postfix container with new generatated config files?

esackbauer

Why is your sni.map showing “feja111.tk” instead of “feja111.de”?
Probably a redeployment of the certificates should be enough:
https://docs.mailcow.email/post_installation/firststeps-ssl/#how-to-use-your-own-certificate

Feja111

I do not use the acme container.
I have a reverse proxy via nginx and i deploy the certificate that Mailcow needs to server IMAP and SMTP and some other services that are not webservices over this script:

rm /opt/mailcow-dockerized/data/assets/ssl/key.pem
rm /opt/mailcow-dockerized/data/assets/ssl/cert.pem
ln $(readlink -f /etc/letsencrypt/live/feja111.de/fullchain.pem) /opt/mailcow-dockerized/data/assets/ssl/cert.pem
ln $(readlink -f /etc/letsencrypt/live/feja111.de/privkey.pem) /opt/mailcow-dockerized/data/assets/ssl/key.pem
#cd /opt/mailcow-dockerized/ && docker restart mailcowdockerized_acme-mailcow_1 mailcowdockerized_postfix-mailcow_1 mailcowdockerized_nginx-mailcow_1

In my mailcow.conf looks it like this:
SKIP_LETS_ENCRYPT=y ENABLE_SSL_SNI=n

The Domain feja111.tk is a old domain that was in use.
The Cert that has to be deployed via the script has the Domain Names *.feja111.de and feja111.de.
Mailcow only needs to have this cert.

esackbauer

Obviously you haven’t read the Docs properly:
“IMPORTANT: Do not use symbolic links! Make sure you copy the certificates and do not link them to data/assets/ssl.”

Feja111

Okay, i did a copy of the certs and restarted the 3 services.
The same problem occurs if i try to send mail:

esackbauer

You really should have a file level backup where you can restore single files from…
It seems you have at one point used SNI in the past.
Please create an empty sni.map file in data/conf/postfix and rename the sni.map.db file to something else. Then restart postfix.

Feja111

I do not have a sni.map.db

esackbauer

Then just create an empty sni.map file.

Feja111

The same error occurs:

But i have viewed another interresting things in the log just after the restart:

And the sni.map file was automatically refilled with the same content as before.

Feja111

I solved it!!!
The solution is eventually not the best but it works:
under data/assets/ssl/autoconfig.fam.feja111.tk/domains
i added the smtp.feja111.de server1.feja111.de imap.feja111.de feja111.de domains
i changed the certs in this folder through my wildcard certs.

esackbauer

Seems like a file level permission problem.
This is how my data/conf/postfix folder looks like
root@mail:/opt/mailcow-dockerized/data/conf/postfix# ls -la total 116 drwxr-xr-x 3 root root 4096 Aug 6 05:08 . drwxr-xr-x 11 root root 4096 Feb 28 10:50 .. -rw-r--r-- 1 root root 31 Feb 28 10:50 allow_mailcow_local.regexp -rw-r--r-- 1 root root 1056 Feb 28 10:50 anonymize_headers.pcre -rw-r--r-- 1 root root 223 Feb 28 15:39 custom_postscreen_whitelist.cidr -rw-r----- 1 root systemd-network 0 Feb 28 10:57 custom_transport.pcre -rw-r--r-- 1 root root 940 Aug 4 16:58 dns_blocklists.cf -rw-r--r-- 1 root root 153 Aug 6 05:08 extra.cf -rw-r--r-- 1 root root 63 Feb 28 10:50 local_transport -rw-r--r-- 1 root root 8523 Aug 6 05:08 main.cf -rw-r--r-- 1 root root 7079 Feb 28 10:50 master.cf -rw-r--r-- 1 root root 46640 Jul 31 19:44 postscreen_access.cidr -rw-r--r-- 1 root root 190 Feb 28 10:50 smtp_dsn_filter -rw-r--r-- 1 root root 0 Aug 6 05:08 sni.map -rw-r--r-- 1 root root 12288 Aug 6 05:08 sni.map.db drwxr-xr-x 2 root systemd-network 4096 Feb 28 10:57 sql

Feja111

You are right! The user was www-data!
root@srv001j:/opt/mailcow-dockerized/data/conf/postfix# ll
total 1MB
drwxr-xr-x 3 www-data root 1MB Aug 6 16:49 ./
drwxr-xr-x 12 www-data root 1MB Feb 16 2021 ../
-rw-r–r– 1 www-data root 1MB Jan 9 2021 allow_mailcow_local.regexp
-rw-r–r– 1 www-data root 1MB Jan 9 2021 anonymize_headers.pcre
-rw-r–r– 1 www-data root 1MB Jan 9 2021 custom_postscreen_whitelist.cidr
-rw-r—– 1 root systemd-network 0MB Jan 9 2021 custom_transport.pcre
-rw-r–r– 1 www-data root 1MB Aug 6 16:49 extra.cf
-rw-r–r– 1 www-data root 1MB Jan 9 2021 local_transport
-rw-r–r– 1 www-data root 1MB Aug 6 16:49 main.cf
-rw-r–r– 1 www-data root 1MB Jun 12 2021 master.cf
-rw-r–r– 1 www-data root 1MB Jan 25 2023 postscreen_access.cidr
-rw-r–r– 1 www-data root 1MB Jan 9 2021 smtp_dsn_filter
-rw-r–r– 1 root root 1MB Aug 6 16:49 sni.map
-rw-r–r– 1 root root 1MB Aug 6 16:49 sni.map.db
drwxr-xr-x 2 root systemd-network 1MB Jun 12 2021 sql/