[X] ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
[X] ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
[X] ... I have understood that answers are voluntary and community-driven, and not commercial support.
[X] ... I have verified that my issue has not been already answered in the past. I also checked previous issues.
Description
I have trouble sending a mail to the @rwth-aachen.de domain. Apparently, postfix thinks this domain should have DANE and checks for a TLSA record, while this domain doesn't actually support it. It looks like that in the postfix logs: https://paste.xinu.at/5ik/
This appears to only affect the @rwth-aachen.de receiving domain for my mailcow instance. It looks like I can send to all other non-DANE domains without problems. And also sending to DANE-supporting domains is not an issue. It seems likely that for some reason I have some exceptional dane-only configuration for only this domain. But the thing is... I don't.
I already was in contact with guys in the #mailcow Libera irc channel and we digged through some different causes for this (especially thanks to FingerlessGloves), but couldn't really find the cause why postfix is trying to enforce DANE for that domain. I will list the things we checked now:
I already restarted the postfix container, the whole mailcow stack, and even the host machine.
If I manually add a "may" TLS policy map override in the Mailcow UI, then the mails that were stuck in the queue will be send out! If I remove this override again, it will fall back to failing to send them out (as it's again requiring DANE).
Output of docker compose exec postfix-mailcow postconf smtp_tls_security_level = smtp_tls_security_level = dane (not dane-only).
smtp_tls_security_level is on the default mailcow values (as you also see further down for the git diff with origin/master): https://paste.xinu.at/eOKfI/
I still think this might be an issue on my end, but as we ran out of ideas in IRC, we thought I should create a bugreport here. Any help would really be appreciated. Thank you very much in advance!
Logs:
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/qmgr[377]: 7053A70F0F00: from=<rene@pasing.net>, size=856, nrcpt=1 (queue active)
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[408]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mx1.rz.rwth-aachen.de type=TLSA: Host not found, try again
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[409]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mx1.rz.rwth-aachen.de type=TLSA: Host not found, try again
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[408]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mx1.rz.rwth-aachen.de type=TLSA: Host not found, try again
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[408]: warning: TLS policy lookup for rwth-aachen.de/mx1.rz.rwth-aachen.de: TLSA lookup error for mx1.rz.rwth-aachen.de:25
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[409]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mx1.rz.rwth-aachen.de type=TLSA: Host not found, try again
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[409]: warning: TLS policy lookup for rwth-aachen.de/mx1.rz.rwth-aachen.de: TLSA lookup error for mx1.rz.rwth-aachen.de:25
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[408]: 4188F70F3950: to=<rene.pasing@rwth-aachen.de>, relay=none, delay=517, delays=517/0.08/0.07/0, dsn=4.7.5, status=deferred (TLSA lookup error for mx1.rz.rwth-aachen.de:25)
mailcow-postfix-mailcow-1 | May 24 03:34:36 f00f27c85c77 postfix/smtp[409]: 7053A70F0F00: to=<rene.pasing@rwth-aachen.de>, relay=none, delay=1506, delays=1506/0.11/0.04/0, dsn=4.7.5, status=deferred (TLSA lookup error for mx1.rz.rwth-aachen.de:25)
Steps to reproduce:
Observe postfix logs
Send a test email to @rwth-aachen.de
See a DANE TLSA lookup problem in the mailcow logs
Mail has not been sent out
Which branch are you using?
master
Operating System:
Arch Linux
Server/VM specifications:
16 GiB memory, 4 core Intel Xeon
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
Docker :)
Docker version:
24.0.0
docker-compose version or docker compose version:
2.18.1
mailcow version:
2023-04b
Reverse proxy:
Nginx
Logs of git diff:
diff --git a/data/conf/nginx/templates/listen_plain.template b/data/conf/nginx/templates/listen_plain.template
index a044b22f..35b556b2 100644
--- a/data/conf/nginx/templates/listen_plain.template
+++ b/data/conf/nginx/templates/listen_plain.template
@@ -1,2 +1,3 @@
listen ${HTTP_PORT};
listen [::]:${HTTP_PORT};
+listen unix:/run/nginx/nginx.sock;
diff --git a/data/conf/postfix/main.cf b/data/conf/postfix/main.cf
index a445b60c..31bf02c5 100644
--- a/data/conf/postfix/main.cf
+++ b/data/conf/postfix/main.cf
@@ -198,3 +198,6 @@ parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks
# DO NOT EDIT ANYTHING BELOW #
# User overrides #
+
+myhostname = mail.renepasing.de
+
diff --git a/data/conf/sogo/sogo.conf b/data/conf/sogo/sogo.conf
index 2c042c30..e3017019 100644
--- a/data/conf/sogo/sogo.conf
+++ b/data/conf/sogo/sogo.conf
@@ -26,10 +26,10 @@
// Domains are isolated, you can define visibility options here.
// Example:
- // SOGoDomainsVisibility = (
- // (domain1.tld, domain5.tld),
- // (domain3.tld, domain2.tld)
- // );
+ SOGoDomainsVisibility = (
+ (XXX1, YYY1, ZZZ1), // replaced with XXX due to privacy
+ (XXX2, YYY2, ZZZ2) // replaced with XXX due to privacy
+ );
// self-signed is not trusted anymore
WOPort = "0.0.0.0:20000";
@@ -45,7 +45,7 @@
SOGoMaximumPingInterval = 3540;
- SOGoInternalSyncInterval = 45;
+ SOGoInternalSyncInterval = 60;
SOGoMaximumSyncInterval = 3540;
// 100 seems to break some Android clients
diff --git a/data/web/inc/vars.inc.php b/data/web/inc/vars.inc.php
index 5e6d72e7..798a63a3 100644
--- a/data/web/inc/vars.inc.php
+++ b/data/web/inc/vars.inc.php
@@ -39,7 +39,7 @@ $autodiscover_config = array(
'autodiscoverType' => 'activesync',
// If autodiscoverType => activesync, also use ActiveSync (EAS) for Outlook desktop clients (>= Outlook 2013 on Windows)
// Outlook for Mac does not support ActiveSync
- 'useEASforOutlook' => 'no',
+ 'useEASforOutlook' => 'yes',
// Please don't use STARTTLS-enabled service ports in the "port" variable.
// The autodiscover service will always point to SMTPS and IMAPS (TLS-wrapped services).
// The autoconfig service will additionally announce the STARTTLS-enabled ports, specified in the "tlsport" variable.
diff --git a/docker-compose.yml b/docker-compose.yml
index 23bd308f..d42778d4 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -582,36 +582,6 @@ services:
aliases:
- ofelia
- ipv6nat-mailcow:
- depends_on:
- - unbound-mailcow
- - mysql-mailcow
- - redis-mailcow
- - clamd-mailcow
- - rspamd-mailcow
- - php-fpm-mailcow
- - sogo-mailcow
- - dovecot-mailcow
- - postfix-mailcow
- - memcached-mailcow
- - nginx-mailcow
- - acme-mailcow
- - netfilter-mailcow
- - watchdog-mailcow
- - dockerapi-mailcow
- - solr-mailcow
- environment:
- - TZ=${TZ}
- image: robbertkl/ipv6nat
- security_opt:
- - label=disable
- restart: always
- privileged: true
- network_mode: "host"
- volumes:
- - /var/run/docker.sock:/var/run/docker.sock:ro
- - /lib/modules:/lib/modules:ro
-
networks:
mailcow-network:
driver: bridge
Contribution guidelines
I've found a bug and checked that ...
Description
I have trouble sending a mail to the @rwth-aachen.de domain. Apparently, postfix thinks this domain should have DANE and checks for a TLSA record, while this domain doesn't actually support it. It looks like that in the postfix logs: https://paste.xinu.at/5ik/
This appears to only affect the @rwth-aachen.de receiving domain for my mailcow instance. It looks like I can send to all other non-DANE domains without problems. And also sending to DANE-supporting domains is not an issue. It seems likely that for some reason I have some exceptional dane-only configuration for only this domain. But the thing is... I don't.
I already was in contact with guys in the #mailcow Libera irc channel and we digged through some different causes for this (especially thanks to FingerlessGloves), but couldn't really find the cause why postfix is trying to enforce DANE for that domain. I will list the things we checked now:
I have no outgoing TLS policy map overrides: https://paste.xinu.at/mCWQzB/
I have no encryption policy on my sending mailbox: https://paste.xinu.at/aFCYH/
The postfix config doesn't contain anything 'policy'-related, and the db table is also empty (like shown in the UI): https://paste.xinu.at/nsGN/
I have nowhere a "dane-only" configuration: https://paste.xinu.at/TOfR6/
Resolving mx1.rz.rwth-aachen.de works for unbound: https://paste.xinu.at/yoQ/
The TLSA record query answer from unbound also looks fine (empty): https://paste.xinu.at/CfSHoU/
I already restarted the postfix container, the whole mailcow stack, and even the host machine.
If I manually add a "may" TLS policy map override in the Mailcow UI, then the mails that were stuck in the queue will be send out! If I remove this override again, it will fall back to failing to send them out (as it's again requiring DANE).
Output of
docker compose exec postfix-mailcow postconf smtp_tls_security_level
=smtp_tls_security_level = dane
(notdane-only
).smtp_tls_security_level is on the default mailcow values (as you also see further down for the git diff with origin/master): https://paste.xinu.at/eOKfI/
I still think this might be an issue on my end, but as we ran out of ideas in IRC, we thought I should create a bugreport here. Any help would really be appreciated. Thank you very much in advance!
Logs:
Steps to reproduce:
Which branch are you using?
master
Operating System:
Arch Linux
Server/VM specifications:
16 GiB memory, 4 core Intel Xeon
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
Docker :)
Docker version:
24.0.0
docker-compose version or docker compose version:
2.18.1
mailcow version:
2023-04b
Reverse proxy:
Nginx
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check: