TLS is required, but was not offered by host gmail-smtp-in.l.google.com

1n5

Good afternoon.

I have had a mailcow install for quite a while, and was probably a couple updates behind, when I installed the update “Mootember Update 2025 - Revision B” yesterday.

Since then I have been unable to send any emails to gmail.com addresses.

This seems very similar tot he second half of this thread: https://community.mailcow.email/d/3358-tls-is-required-but-was-not-offered-by-host-alt2gmail-smtp-inlgoogle/32 However, I do not believe I have any SMTP proxy, especially as I have not had any problems until I upgraded yesterday.

The relevant part of logs in docker container logs -f mailcowdockerized-postfix-mailcow-1:

Sep 13 11:43:23 c085f767dc8e postfix/smtp[537]: connect to gmail-smtp-in.l.google.com[2607:f8b0:4023:2009::1a]:25: Network is unreachable
Sep 13 11:43:23 c085f767dc8e postfix/smtp[537]: 5B8F315D44F: TLS is required, but was not offered by host gmail-smtp-in.l.google.com[192.178.164.26]
Sep 13 11:43:24 c085f767dc8e postfix/smtp[537]: 5B8F315D44F: TLS is required, but was not offered by host alt1.gmail-smtp-in.l.google.com[142.251.190.26]
Sep 13 11:43:24 c085f767dc8e postfix/smtp[537]: connect to alt1.gmail-smtp-in.l.google.com[2607:f8b0:4003:c0a::1b]:25: Network is unreachable
Sep 13 11:43:24 c085f767dc8e postfix/smtp[537]: connect to alt2.gmail-smtp-in.l.google.com[2607:f8b0:4001:c74::1b]:25: Network is unreachable
Sep 13 11:43:24 c085f767dc8e postfix/smtp[537]: 5B8F315D44F: to=<xxxxxxxxx@gmail.com>, relay=none, delay=2246, delays=2245/0.1/0.86/0, dsn=4.4.1, status=deferred (connect to alt2.gmail-smtp-in.l.google.com[2607:f8b0:4001:c74::1b]:25: Network is unreachable)

I can confirm that ipv6 is disabled in /etc/docker/daemon.json (unfortunately required)

Any thoughts?

DocFraggle

1n5 I can confirm that ipv6 is disabled

Why is your postfix container resolving the IPv6 address then?

Do you have any kind of firewall in-between your mailcow and the Internet which is interfering with STARTTLS due IPv4?

pkernstock

Is ENABLE_IPV6 disabled? Try this: https://docs.mailcow.email/post_installation/firststeps-disable_ipv6/

1n5

pkernstock

Thank you for the suggestion, but yes, my mailcow.conf contains: ENABLE_IPV6=false (at the very bottom)

Also, my /etc/docker/daemon.json contains: {"ipv6":false,"fixed-cidr-v6":"fd00:dead:beef:c0::/80","experimental":true,"ip6tables":false}

It is confusing to me that it’s trying the ipv6 ips. But my understanding is it is also trying the ipv4 IPs, which is when it gets the “TLS is required, but was not offered by host” errors.

My read of the documentation implies that the ‘fixed-cidr-v6’ should not be in /etc/docker/daemon.json

So I removed it, did docker compose down and docker compose up -d and symptoms appear to be the same:

Sep 14 19:16:44 17691ebf71d7 postfix/qmgr[365]: 7ED0315D2E1: from=<xxxxxx@mailmag.net>, size=532, nrcpt=1 (queue active) Sep 14 19:16:44 17691ebf71d7 postfix/sogo/smtpd[369]: disconnect from mailcowdockerized-sogo-mailcow-1.mailcowdockerized_mailcow-network[172.22.1.248] ehlo=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=6 Sep 14 19:16:44 17691ebf71d7 postfix/smtp[374]: 7ED0315D2E1: TLS is required, but was not offered by host gmail-smtp-in.l.google.com[192.178.164.26] Sep 14 19:16:44 17691ebf71d7 postfix/smtp[374]: connect to gmail-smtp-in.l.google.com[2607:f8b0:4023:2009::1a]:25: Network is unreachable Sep 14 19:16:44 17691ebf71d7 postfix/smtp[374]: 7ED0315D2E1: TLS is required, but was not offered by host alt1.gmail-smtp-in.l.google.com[142.251.190.26] Sep 14 19:16:44 17691ebf71d7 postfix/smtp[374]: connect to alt1.gmail-smtp-in.l.google.com[2607:f8b0:4003:c0a::1a]:25: Network is unreachable Sep 14 19:16:44 17691ebf71d7 postfix/smtp[374]: 7ED0315D2E1: to=<xxxxxxxxxxx@gmail.com>, relay=alt2.gmail-smtp-in.l.google.com[192.178.212.27]:25, delay=1.9, delays=0.99/0.08/0.86/0, dsn=4.7.4, status=deferred (TLS is required, but was not offered by host alt2.gmail-smtp-in.l.google.com[192.178.212.27])

1n5

Update: I can confirm I am able to send email to Microsoft-owned mail servers still. I am assuming via TLS, but unsure how to be completely sure.

DocFraggle

1n5 but unsure how to be completely sure

Look at the headers of a mail you sent there

1n5

Emails to Microsoft mailserver domains do appear to being passed encrypted, but emails to Gmail domains are still not being delivered with the same error as before. I’m quite confused now as to what is wrong.

Could this be something related to MTA-STS? Especially since that support was added in the update that seems to have broke my delivery to gmail? (However, the last time I can 100% confirm delivery to gmail was working was August 25th. I’m trying to find any confirmations of email successfully delivered after that)

Follows is headers of an email sent to a domain using O365 for email: (I removed the sections about MS mailservers relaying the email to each other for simplicity)

Authentication-Results: spf=pass (sender IP is 199.192.20.237) smtp.mailfrom=mailmag.net; dkim=pass (signature was verified) header.d=mailmag.net;dmarc=pass action=none header.from=mailmag.net;compauth=pass reason=100 Received-SPF: Pass (protection.outlook.com: domain of mailmag.net designates 199.192.20.237 as permitted sender) receiver=protection.outlook.com; client-ip=199.192.20.237; helo=mail.mailmag.net; pr=C Received: from mail.mailmag.net (199.192.20.237) by zzzzzzzzzzz.mail.protection.outlook.com (10.167.242.199) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.13 via Frontend Transport; Mon, 15 Sep 2025 02:33:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPA id EEB8F161D2F for <xxxxxxxxx@xx_msdomain_xx>; Sun, 14 Sep 2025 19:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailmag.net; s=dkim; t=1757903610; h=from:subject:date:message-id:to:mime-version:content-type; bh=AmO7N4BA4LqUe6D52SGPSoK9pUUk0vuyQ6nPGOs1nFU=; b=lrTHy1QB1M5ifcO4IDLw5lEKv9e1x4BIeG8F7koAoYSLHUQ2yDJQz+Sl4d97xzUKPuz1I1 Q5R+H9ufx6fVNu6EQ4EoCvL2ug/NKIcGdpDl3UsL4Ma5SSU7clGqpkp9n0/8cOb3gORHls JsCr1HRVXNkYXPkCi3edRrPisTqR51WyOdtm4eJ9HyiFBs9uQWxGjdYQyVq/Revhz81Q9I pdxnJdympzK3R1z2x+aDcfdd/Kk1TWFk3v1CUmnWuoRCoYgO03kbsfngbwSPY3g5/IGHkJ Yj+rnZ/vyThG2yhyRuSFVWk/TCpDGp9v9mvKotgnbyeLJKmdYjs9vi7L5A/YZQ== From: "xxxxxxx" <xxxxxxx@mailmag.net> To: xxxxxxxxxxxx@xx_msdomain_xx User-Agent: SOGoMail 5.12.3 MIME-Version: 1.0 Date: Sun, 14 Sep 2025 19:33:29 -0700 Subject: test email #16 Content-Type: text/plain; charset="utf-8" X-Last-TLS-Session-Version: None Return-Path: xxxxxx@mailmag.net

DocFraggle

It’s better if you check the complete headers here yourself, the above is of no use unfortunately:

https://mxtoolbox.com/EmailHeaders.aspx

1n5

Thanks. I pasted the full headers into their tool, and it shows the same as manually looking at the headers above does: The transport from my mailcow server to the O365-managed email domain is done using HTTPS/SSL/TLS (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) It didn’t show anything else of note.

I obviously cannot get the headers from the email sent to gmail, as they fail to send and is stuck int he queue, retried every so often.

I also tried MxToolbox’s “email deliverability” test where you send an email to them, and they give you a report, and that reported nothing wrong, with everything good except for the fact that my DMARC policy is currently not enabled. (exists, but not currently set to quarantine or reject)

Additionally, I have found that the new tlspol container for outbound MTA-STS appears to be causing this.

The logs for that container show postfix-tlspol-mailcow-1 | Sep 15 09:46:27.304 INFO Evaluated policy for "gmail.com": secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostname (from cache, 4h45m58s remaining)

And from my reading, secure means that domain specifies you should not fall back to unencrypted email no matter what.

So now the question is why am I unable to initiate an encrypted connection to gmail, while I am to microsoft?

1n5

DocFraggle Why is your postfix container resolving the IPv6 address then?

I’m investigating the ipv6 bit at the moment. If I connect into the postfix container, I get IPv6 results via DNS, but have no IPv6 address. Will investigate further.

Do you have any kind of firewall in-between your mailcow and the Internet which is interfering with STARTTLS due IPv4?

I don’t believe so, but am beginning to worry there is one I have not been told about, and this is the real root cause of the problems. I am working on opening a ticket with my provider.

1n5

Upon further investigation, I fear there is likely outbound SMTP transparent proxying going on:

If I run a test inside the postfix container:

root@b5870cc05739:/# openssl s_client -connect alt1.gmail-smtp-in.l.google.com:25 -starttls smtp
CONNECTED(00000003)
Didn't find STARTTLS in server response, trying anyway...
40A7F10EC37F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:../ssl/record/rec_layer_s3.c:322:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 228 bytes and written 377 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Google IS NOT offering a STARTTLS in response which seems very unlikely.

I opened a ticket with my provider and am awaiting a response. Though I’m not sure I understand why they would be proxying outbound to gmail but not some other providers….

1n5

Unfortunately, confirmed.

My hosting provider is indeed doing some sort of transparent SMTP filtering / proxying. 🙁

Is there any way I can temporarily turn MTA-STS back off while I search for a new hosting provider?

I tried adding smtp_tls_security_level = may to data/conf/postfix/extra.cf and restarted the whole stack after taking it down with docker compose down. However, that does not appear to have made a difference, as postfix still gets the TLS is required, but was not offered by host message.

DocFraggle

If Google is enforcing it you can’t do anything about it unfortunately…

1n5

I do not believe that is the case.

The problem started when MTA-STS was added to mailcow.

Before then, Google was advertising via MTA-STS to only use encrypted connections, but they were actually accepting non-encrypted ones.

After the mailcow change, mailcow is checking Google’s MTA-STS settings, which say to never use unencrypted. That is causing my email server to refuse to send email to google unencrypted. (and therefore not at all)

I know it wouldn’t be advised, and I would not plan to use it long-term, but it seems like there should be a way to turn MTA-STS back off, the way it used to be before the recent update.

Comprehensive answer:

Turns out my provider was actually doing SMTP filtering/proxying. See the rest of the thread for how to use openssl to check if you are also affected.

Temporary solution:
Add BOTH of these lines to data/conf/postfix/extra.cf:

smtp_tls_security_level = may
smtp_tls_policy_maps =

This will turn back off MTA-STS (AND DANE) for outbound email.

Long-term, I am looking for a replacement for my provider, as this is very undesirable behavior. (and if you have this same problem, you should too)

disgustipated

Do you happen to be using Hetzner? I started getting the same after the update.

mr-manuel

I have the same issue and my server is hosted at Hetzner. Recipient domains are web.de, gmx.net, freenet.de. Google worked somehow.

Adding the config worked for now. Curious, if we can solve this without turninf off encryption.

1n5

I am not using Hetzner, (it’s hosting offered by Namecheap) but unfortunate to hear they are doing this also….

I’m going to guess it is impossible to pass encrypted SMTP traffic from these networks at least on port 25. It may be possible to deliver mail using a different port, but that’s going to vary per email server.

It really sucks that they are doing this, (presumably to scan for outbound spam) because it makes delivery of secure email basically completely impossible. They block opening a secure connection, and they strip the STARTLS command from a non-secure tunnel to prevent it from being upgraded.

My question becomes what providers AREN’T doing this so I can setup a simple email server with modern security…..

mr-manuel

I contacted the Hetzner support and they told me that there is only a limitation for cloud servers (see https://docs.hetzner.com/cloud/servers/faq/#why-can-i-not-send-any-mails-from-my-server) which can be disabled after a while. Anyway, I’m using a dedicated server and there is no SMTP filtering.

Trying manually to connect to a MX server, where the Mailcow Postfix is not able to connect, shows no issues:

root@mail01:~# openssl s_client -starttls smtp -connect mx-ha03.web.de:25 -crlf -ign_eof
CONNECTED(00000003)
depth=2 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
verify return:1
depth=1 C = DE, O = Deutsche Telekom Security GmbH, CN = Telekom Security ServerID OV Class 2 CA
verify return:1
depth=0 C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mx.web.de
verify return:1
---
Certificate chain
 0 s:C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mx.web.de
   i:C = DE, O = Deutsche Telekom Security GmbH, CN = Telekom Security ServerID OV Class 2 CA
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 19 07:05:18 2025 GMT; NotAfter: Feb 23 23:59:59 2026 GMT
 1 s:C = DE, O = Deutsche Telekom Security GmbH, CN = Telekom Security ServerID OV Class 2 CA
   i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  2 09:16:44 2022 GMT; NotAfter: Aug  2 23:59:59 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIJBTCCB22gAwIBAgIQOZrsxtVRqfTT7SgrKcgxOTANBgkqhkiG9w0BAQsFADBo
MQswCQYDVQQGEwJERTEnMCUGA1UECgweRGV1dHNjaGUgVGVsZWtvbSBTZWN1cml0
eSBHbWJIMTAwLgYDVQQDDCdUZWxla29tIFNlY3VyaXR5IFNlcnZlcklEIE9WIENs
YXNzIDIgQ0EwHhcNMjUwMjE5MDcwNTE4WhcNMjYwMjIzMjM1OTU5WjBvMQswCQYD
VQQGEwJERTEYMBYGA1UECBMPUmhlaW5sYW5kLVBmYWx6MRIwEAYDVQQHEwlNb250
YWJhdXIxHjAcBgNVBAoMFTEmMSBNYWlsICYgTWVkaWEgR21iSDESMBAGA1UEAxMJ
bXgud2ViLmRlMIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA1Rk5R3tz
9VvUrtiSqwHqz1lcfY+nv99+QjzLy/PRta8jQGapToY7WREcN0EO8L8uTbqFARqt
t4YXW+dSYpzQxz/zkAfrzPecpkPLc08xPfyY3p3CdWDT6Bb8KvyfD/uhW/mRVjd2
9rsHgcdtnkfHwYJCcBSCG/VK9+pPQmh9Pg9T8I+OwJ9i3WD8s6Wnzw6u38l9Ld1L
qvgVh8TeKVdB4elzf5BfCOIU5TbOq0+Tphk22B4vvgSrwtb1R0cDvgsxRHclG57q
PgMhig4RUtz0a1BXNLIaHTTEMue4KxmTRJwuYsYvbDIxNBGPjRpQeG/wwLbVmMzX
mm1RnmuSStHX+vQsgF9Yh/GZECKr3qF7z49JgqMzLqdugO6NPu8V4Ub8+KE9MUOs
4q/TfteNZwYcC9W7chatY0RIm+Vg0+1kD6wIP/BFYzPWiC75tVoOb9EiCnZuqrp2
FhojFEu0jZ63SBNmArq6fTfUEegfr4i8QYrU3Q6SN+Pd9msYcOuLEvs/AgMBAAGj
ggSiMIIEnjAfBgNVHSMEGDAWgBQcBZOxf6g0MIxS4JZAoHKjEF3g/zAOBgNVHQ8B
Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMB0GA1UdDgQW
BBTNC9rCOuJsRiwy4JSbl9JvicnXcTBTBgNVHSAETDBKMEgGBmeBDAECAjA+MDwG
CCsGAQUFBwIBFjBodHRwOi8vZG9jcy5zZXJ2ZXJpZC50ZWxlc2VjLmRlL2Nwcy9z
ZXJ2ZXJpZC5odG0wXgYDVR0fBFcwVTBToFGgT4ZNaHR0cDovL2NybC5zZXJ2ZXJp
ZC50ZWxlc2VjLmRlL3JsL1RlbGVrb21fU2VjdXJpdHlfU2VydmVySURfT1ZfQ2xh
c3NfMl9DQS5jcmwwgZ8GCCsGAQUFBwEBBIGSMIGPMDEGCCsGAQUFBzABhiVodHRw
Oi8vb2NzcC5zZXJ2ZXJpZC50ZWxlc2VjLmRlL29jc3ByMFoGCCsGAQUFBzAChk5o
dHRwOi8vY3J0LnNlcnZlcmlkLnRlbGVzZWMuZGUvY3J0L1RlbGVrb21fU2VjdXJp
dHlfU2VydmVySURfT1ZfQ2xhc3NfMl9DQS5jcnQwDAYDVR0TAQH/BAIwADBSBgNV
HREESzBJgglteC53ZWIuZGWCDm14LWhhMDIud2ViLmRlgg5teC1oYTAzLndlYi5k
ZYINZGhteDAxLndlYi5kZYINZGhteDAyLndlYi5kZTCCAnIGCisGAQQB1nkCBAIE
ggJiBIICXgJcAHYADleUvPOuqT4zGyyZB7P3kN+bwj1xMiXdIaklrGHFTiEAAAGV
HQaBvAAABAMARzBFAiEAz3VK7RGd3IKfHanmc/bKtQ2QjmEy0WPgxSEEDJniM/cC
IF8GsCm+cqOypLozUQeZDfsI9tHq6CeKv215cOXl8dSoAHcAlpdkv1VYl633Q4do
NwhCd+nwOtX2pPM2bkakPw/KqcYAAAGVHQaEhgAABAMASDBGAiEAts5WxxOZu8WK
fu7IxMqBfTj/sv/Vw/NQAWaX+fPTS0ACIQD/Gf740GA9ald0ikhfzSlkzIkOAWM9
OGzWzLQ5iGrnNwB3ABmG1Mcoqm/+ugNveCpNAZGqzi1yMQ+uzl1wQS0lTMfUAAAB
lR0GgNIAAAQDAEgwRgIhAJUqplDG2Rtum04Ij/9lA+KI7RcQMTnLauP/0Z+F9yFg
AiEA+gtSPraNeWaEfa+HLMkaR6pYRpZRoUFQWHX4bpVvJncAdwBJnJtp3h187Pw2
3s2HZKa4W68Kh4AZ0VVS++nrKd34wwAAAZUdBoDhAAAEAwBIMEYCIQDtDZaKzsel
5DJ4viCX5w6rMlWp7PlmHOcAvTTtUOBxxgIhAIdLeWNvydLQlhmYrAo5P+bzim42
IxGEYt12XUpwGynSAHcAZBHEbKQS7KeJHKICLgC8q08oB9QeNSer6v7VA8l9zfAA
AAGVHQaBhQAABAMASDBGAiEA+DAX2eoGZV0NGZ8x2vSvqjd8zAA4gWupOAIwH9jj
hwICIQDvw3ZDzaDNEcm5337zg3UCuzeaP0b98uGeTNsmnu8HPTANBgkqhkiG9w0B
AQsFAAOCAYEAvfDcT2aZLqTkuFX+8xXo8CxGPFrGxK5N4nKME7jQqrNcHuyoK38D
uVezri4kAL3xXXygJzVumqy9Lmaw0PRx6kewNqfWQJpfHbnQpr5f757te3vEek1c
9/MqEuN931XtkrqN6+K646WHzc4UZW5fvtDi/8m+svv2R+Gu9HfpI4yt2TMX7p8I
cB8M5nG4Qu8jpi1i5RCUXV9mfKDHC+ki/M+gf8DnVKJQNWNuV+AEfi7SksJbUrvd
+6DTe1gB0D5F7ArbOJ6TP6aywlEm86iRURz/DMh8QO5ZUWSoMcyf3SGOET7YD8ha
8uAgyq5vIzCsy8a5rs4hsCQI/Ug1jTERZJLUGf1T2pIPjrZRpO6Bw3yJLL8CByM+
2mQXy4Gy4wex13IAGXoqyFY4cpkqet301k0jeo7kKVf98+dRXO/8d7gR6i5Y/cWT
pzMxy8OKRQUek9UlufA9WWIAG2f1S1cmeKakg3ciUcJj3I1I+4LD9W9lnlRcZ8UN
AtGtV889D5M5
-----END CERTIFICATE-----
subject=C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mx.web.de
issuer=C = DE, O = Deutsche Telekom Security GmbH, CN = Telekom Security ServerID OV Class 2 CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4686 bytes and written 786 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 3072 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

Here the log entries of the Mailcow Postfix log when trying to connect to the exact same server:

postfix-mailcow-1  | Sep 25 10:57:27 9f3f2b5235f7 postfix/smtp[430]: SSL_connect error to mx-ha03.web.de[212.227.15.17]:25: Connection timed out
postfix-mailcow-1  | Sep 25 10:57:27 9f3f2b5235f7 postfix/smtp[430]: DDAE51403F4: to=<redacted-for-pricavy@web.de>, relay=mx-ha03.web.de[212.227.15.17]:25, delay=601, delays=0.6/0/600/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure)

I checked the TLS version and ciphers and found no issue.

The TLS policies are empty and TLS is not enforced in the settings of any user:

When searching for smtp_tls_policy_maps, there is no place where something is set, except for the lookup in the database, which returns no results:

root@mail01:~# grep -R "smtp_tls_policy_maps" /opt/mailcow-dockerized/
/opt/mailcow-dockerized/update_diffs/diff_before_update_2025-09-25-10-43-27:+smtp_tls_policy_maps =
/opt/mailcow-dockerized/data/conf/postfix/extra.cf:# smtp_tls_policy_maps =
/opt/mailcow-dockerized/data/conf/postfix/main.cf:  $smtp_tls_policy_maps,
/opt/mailcow-dockerized/data/conf/postfix/main.cf:smtp_tls_policy_maps = proxy:mysql:/opt/postfix/conf/sql/mysql_tls_policy_override_maps.cf socketmap:inet:postfix-tlspol:8642:QUERY
/opt/mailcow-dockerized/data/conf/postfix/main.cf:# smtp_tls_policy_maps =

Why does it work when adding smtp_tls_policy_maps = to data/conf/postfix/extra.cf? That makes absolutely no sense to me. I’m overseeing something?

DocFraggle

mr-manuel When searching for smtp_tls_policy_maps, there is no place where something is set, except for the lookup in the database, which returns no results:

That’s not quite correct:

/opt/mailcow-dockerized# cd /opt/mailcow-dockerized; docker compose exec postfix-mailcow /bin/bash
 
root@8b067870f8de:/# postmap -q web.de proxy:mysql:/opt/postfix/conf/sql/mysql_tls_policy_override_maps.cf
root@8b067870f8de:/# postmap -q web.de socketmap:inet:postfix-tlspol:8642:QUERY
dane-only

So for web.de it’s “dane-only”, which means:

Postfix requires DANE (DNSSEC + TLSA) to validate the server’s certificate.
If no TLSA records are found or DNSSEC validation fails → the message is not delivered.
It will not fall back to opportunistic TLS or plaintext.

And “dane-only” comes right out of the new postfix-tlspol container:

In other words, without “dane-only” it’s working for you as soon as you “unset” smtp_tls_policy_maps

EDIT: here the query for gmail.com:

root@8b067870f8de:/# postmap -q gmail.com proxy:mysql:/opt/postfix/conf/sql/mysql_tls_policy_override_maps.cf
root@8b067870f8de:/# postmap -q gmail.com socketmap:inet:postfix-tlspol:8642:QUERY
secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostname

According to ChatGPT:

secure → This is the TLS policy.
secure means Postfix will require a successful TLS session when sending to this destination. If TLS can’t be negotiated, delivery fails (no plaintext fallback).
match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com → This specifies which remote MX hosts the policy applies to.
In this case, it matches Gmail’s inbound SMTP servers (gmail-smtp-in.l.google.com).
servername=hostname → This sets the SNI (Server Name Indication) value Postfix will present during the TLS handshake. Normally Postfix uses the MX hostname automatically, but here it is being overridden to hostname.

mr-manuel

root@8b067870f8de:/# postmap -q web.de socketmap:inet:postfix-tlspol:8642:QUERY
dane-only

Thanks! This at least explains where it comes from.

If I understood correctly, then web.de has a faulty DANE setup or anything else in this chain that prevents correct functioning?

Checking https://mta-sts.web.de/.well-known/mta-sts.txt is says testing:

version: STSv1
mode: testing
mx: mx-ha02.web.de
mx: mx-ha03.web.de
max_age: 604800