kein kontakt zu synology mail server mehr möglich

Hallöchen

habe kleines Problem:

setup: 128.4.3esr (64-bit), macos 15.1.1, synology mail server 1.7.5-20671

bis vor einiger zeit konnte ich das problemlos nutzen, d.h. ich habe auf dem NAS meine mails rübergeschoben als archiv.

seit irgendeiner version von TB ist es unmöglich, eine verbindung herzustellen: zertifiakt passt vermutlich nicht (das wurde seitens NAS sicher verändert), aber ich kann jetzt weder zertifikat laden noch sonstwas.

kennt das jemand? bin für jeden tipp dankbar!!!

Es gibt keine Popups (wie "früher") mit "Ausnahme akzeptieren" usw.; die Zertifikate vom Synology lassen sich nicht installieren über den Einstellungen-Dialog, ich bin jetzt am Ende mit meinem Latein...

Hallo,

sorry, versuche mal, die fehlenden Infos beizugeben:

Auf dem NAS (Synology) läuft "Synology Mail", das basiert wohl auf Dovecot. Bietet einen IMAP und einen IMAP SSL/TLS Zugang an; ich kann beide Ports per Telnet erreichen aus dem gleichen Netz, nur um eine Blockade auszuschliessen.

Mein TB ist so konfiguriert (oder: war), daß er sich einfach per IMAP mit dem Ding verbindet und synchronisiert; genutzt habe ich TLS od STARTTLS. Wie bei einem ganz normalen IMAP-Server eben.

Einzige Aktion, die initial und beim Zertifikatswechsel notwendig war: Im Popup des TB das neue Zertifikat laden und als Ausnahme einrichten. Das hat immer einwandfrei funktioniert, jetzt mindestens 3 Jahre lang, somit 6x Zertifikat erneuert usw.

Dieses Popup kommt aber nicht mehr, sondern es steht in Statusleiste lediglich "Connecting to NAS...". Keine Meldung, kein Fehler, nichts.

Namensauflösung findet statt, das ist schonmal abgehakt. cert9.db habe ich schon gelöscht, keine Abhilfe.

Wenn ich das Zertifikat manuell laden will (siehe Screenshot), geht das nicht; es kommt immer die Meldung "unable to obtain identification status for this site".

Habe hier auch alles ausprobiert, mit nas:143, mit IP usw., nur für denn Fall der Fälle. Früher war das einfach nas:143 und fertig. Gebe ich eine bekannte Adresse ein, bspw. 8.8.8.8, dann checkt er jedoch problemlos und sagt "alles klar"...

Zwischen Client und Server keine Firewall, lokal auf dem Client auch alles abgestellt, keine Virenscanner aktiv, nichts. Tritt auf beiden Clients auf, die mir zur Verfügung stehen.

Also zusammengefasst aus meiner Sicht alles Standard bis auf das Zertifikat.

Habe das gerade auch mal mit Apple Mail getestet, funktionert: Per IMAP auf NAS Mail zugreifen und alle Operationen gehen.

Gruß

M

Zitat von hamma

Hier wird der Fehler und die vermeintliche Behebung beschrieben:

https://support.plesk.com/hc/en-us/artic…me-is-not-valid

Hallo, vielen Dank, aber ich schnalle es noch nicht - vielleicht bin ich zu alt

Wie löst das meine Problem? Ich will ja erstmal ein selbst erstelltes Zertifikat laden (was garnicht mehr funktioniert) und der Server ist nur im lokalen Netzwerk ohne Aussenkontakt, kein FQDN etc.

Das Problem geht eher in die Richtung, daß TB weder Zertifikate lädt noch akzeptiert, sich aber auch nicht "beschwert", sondern einfach nicht funktioniert.

Zitat von Sehvornix

Einen Namen wird der Server im Netzwerk aber sicherlich haben. Der sollte intern über einen DNS-Dienst auflösbar sein. I.d.R. (Windows-Welt) hat man auch eine s.g. Workgroup, ob man will oder nicht. Vermutlich ist auch in der MAC-Welt eine Standardvorgabe für das SMB-Protokoll gegeben. Angeblich hat Apple ja .local für sich okkupiert. Am Ende steht auch in einem selbstsignierten Zertifikat ein Name, für den das Zertifikat gilt. Mit einer IP-Adresse geht es nicht. So oder so, die Rädchen müssen ineinandergreifen. Das ist u.a. mit dem Hinweis aus dem Link gemeint. Servername, Name im Zertifikat und IMAP-Server in Thunderbird müssen zusammenpassen.

Da Dein synology mail server nur intern arbeitet, könntest Du Dir überlegen, auf Port 143 zurückzugehen und ohne SSL / STARTTLS verbinden.

Gruß
Sehvornix

Ah, jetzt verstehe ich, danke!

Also, der Server heisst seit Jahren so wie er jetzt heisst, hat sich nicht geändert. Das Zertifikat wird auch immer gleich von ihm selbst zur Verfügung gestellt, bei der Namensauflösung hat sich nichts geändert, und wie ich schrieb, habe ich alle Varianten ausprobiert - neben der, die tatsächlich mal ging.

Kurzum, ich würde ein Problem mit der Benamung ausschliessen.

Was hat SMB mit dem Thema zu tun? SMB nutze ich natürlich auch, völlig problemlos, mit allen Rechnern (Macs, Linuxe, NASe usw.) die hier im Netz sind. Windows habe ich nur virtualisiert, auch da keine Probleme.

Das mit "ohne TLS" kann ich mal probieren, habe ich noch garnicht dran gedacht.

TLS aus hat leider auch nix gebracht, was für ein Mist.

Jetzt ziehe ich erstmal um auf Apple Mail und arbeite da weiter, sonst komme ich zu nix mehr

Viele Dank für Eure Unterstützung, werde demnächst nochmal eine ältere ESR-Version versuchen, vllt klappt's ja damit.

Danke & Schönen Abend!

Nachtrag, hat mit keine Ruhe gelassen, Problem gelöst.

Die Zertifikatabfrage im TB leitet fehl: Wenn man das (selbstsignierte) Zertifikat installieren möchte, dann geht das nicht ohne weiteres; hier die Lösung, die für mich funktioniert hat:

• TB suggeriert, man müsse das Zertifikat vom Server mittels "https://..." laden; das ist natürlich Quatsch, denn das ist HTTPS auf Port 443. Ein damit geladenes Zertifikat passt nicht zu IMAP mit TLS.
• Für IMAP mit TLS braucht man Port 993; also wäre logisch "servername:993" zu nutzen. Das kann man machen, aber da passiert einfach nichts.
• Ursache: Das geht nicht mehr "out of the box", sondern den Port muss man erst freischalten mit dem manuellen Setzen von "network.security.ports.banned.override" mit Wert "993".
• Nun kann man im Zertifikat-Manager eine Ausnahme laden mittels "servername:993" (ohne https:// o.ä. Protokoll-Angabe!).

Ein recht unintuitives Verhalten vom TB, aber zumindest kann ich ihn jetzt wieder nutzen und kann mir andere Mail-Programme ersparen

Schönes WE!