Martin M

Danke für die Info, dann lasse ich das. Immer gut, alte defaults mal hinter sich zu lassen.

Ich ziehe froxlor auf einen neuen Server um. froxlor 2.28 auf bullseye zu froxlor 2.2.8 auf bookworm. Dabei soll vor allem der IMAP-Zugriff nach der DNS-Umstellung ohne Umkonfiguration der Client laufen. Ich habe froxlor auf dem neuen Server per apt installiert und konfiguriert. Beim Vergleich der Dovecot-config ist mir aufgefallen, dass die configs such deutlich unterscheiden: alter Server: mail_home = /var/customers/mail/mailboxes/%d/%n mail_location = maildir:~/mail:LAYOUT=fs neuen Server: mail_location = mbox:~/mail:INBOX=/var/mail/%u und kein mail_home, obwohl in den "Einstellungen" Mail-Homedir auf /var/customers/mail/ steht (so wie immer). Hat sich die Dovecot-config grundlegend geändert, oder mache ich was falsch? Output von doveconf -n hängt an. dove.conf

yup, der Patch hat geholfen! Vielen Dank (Übrigens Debian 11, PHP 7.4.33)

Bei mir sind die A und AAAA Records direkt in der DNS-Zone, kein CNAME, und ich bekomme trotzdem den Fehler.

Vielen Dank für die Einstellung, sie umschifft das Problem, hilft aber nicht zu verstehen, wie es dazu kommt. Ich habe eine Domain mit Alias "www". Froxlor ist der authoritive DNS server. Die DNS-Einträge entsprechen den SSL-Einstellungen. HTTP-IPs entsprechen den HTTPS-IPs. Die IP-Einträge existieren schon seit Monaten. dig und host liefern exakt die erwarteten IPs (IPv4 und IPv6). Letsencrypt hat mit froxlor 0.10 funktioniert. Seit Upgrade auf froxlor 2.0 werden keine Letsencrypt-Zertifikate erneuert. OK, in der acme-Config steht noch /var/www/froxlor als Le_Webroot. Daher hatte ich die Idee: ssl ausschalten (task laufen lassen) ssl wieder einschalten. Jetzt kommt aber die genannte Fehlermeldung (inkl. Tippfehler "enhalten" statt "enthalten"). (Einstellung siehe Screenshots unten) Antwort von dig: In der neuen Einstellung "DNS Resolver für die DNS Überprüfung" habe ich diverse Resolver getestet (1.1.1.1, lokal, 9.9.9.9), alles ohne Erfolg. Umgebung: Debian bullseye Ich würde die DNS-Prüfung gerne eingeschaltet lassen. Kann ich noch weitere Infos zur Ursachenfindung beitragen? (btw: vielen Dank für die großartige Arbeit!)

Interessanter Weise hat PHP kein Thema mit dem Dual Stack. Dort funktioniert die Konfiguration "localhost". Entweder wird hier IPv4 priorisert oder beide Protokolle ausprobiert. Es würde ja sonst auch sofort auffallen. Postfix handhabt das halt anders. Nun gut, hoffen wir, der Thread hilft, dass der Workaround schnell gefunden wird.

Für mich war auch der Patch in allen /etc/postfix/mysql*.cf notwendig: hosts = 127.0.0,1 Hintergrund: Das von mir aufgesetzte Debain 11 ist Dual-Stack (IPv4 und IPv6). localhost wird von sowohl zu IPv4 als auch zu IPv6 aufgelöst, obwohl in /etc/hosts nur 127.0.0.1 steht: # host localhost localhost has address 127.0.0.1 localhost has IPv6 address ::1 MariaDB hat immer noch ein Thema mit Dual Stack. Nun ist es IMHO gute Praxis, MariaDB normalerweise nur lokalen Zugriff zu gewähren. Das wird (best practice) erreicht durch bind-address = 127.0.0.1 Egal ob ich in /etc/mysql/mariadb.conf.d/50-server.cnf als bind-address 'localhost' oder '127.0.0.1' eingebe, MariaDB lauscht immer nur auf IPv4. Falls in den mysql_*.cf jetzt 'hosts = localhost' steht, priorisiert der Mysql-Client anscheinend die IPv6 Adresse, kann darunter jedoch den MariaDB-Server nicht erreichen und bricht ab, ohne IPv4 versucht zu haben. Statt dessen versucht er nun, MariaDB über den Standard-Socket zu erreichen. Der Socket ist aber im chroot-Jail nicht erreichbar. Das führt zur verwirrenden Fehlermeldung (can't connect through socket obwohl doch localhost angegeben ist). Daher sollten wir in Erwägung ziehen, in den Debian 11 Templates "hosts = 127.0.0.1" statt des aktuellen "localhost" zu verwenden.