Beiträge von samsing

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!

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!

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.

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.

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

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...

Salut!

Ich doktore immer noch an dem Problem mit den veschwindenden Tags herum (Filter verschiebt, aber "tagged" nicht).

Um das tieferzulegen wollte ich in die IMAP-Logs anschauen; KEIN PROBLEM dachte ich, machste

- "mailnews.imap.loglevel" auf "All" (Quelle: https://wiki.mozilla.org/MailNews:Logging)

- Error Console auf... kommt nix!

Kapiere ich nicht, denn bei "mailnews.smtp.loglevel" = "All" klappt das ganz hervorragend!

Umgebung:

- 128.2.3esr (64-bit)

- macOS Sequioa oder wie man das schreibt...

Wenn jemand eine Idee hat... DANKE im Voraus!!!!!

Zitat von Sehvornix

Kleiner Test dazu: wenn Du eine Mail mit Schlagwort von dem betreffenden IMAP-Konto in einen Ordner unterhalb von 'Lokale Ordner' verschiebst, bleibt das Schlagwort dabei erhalten?

Habe eine geflaggte Mail in einen anderen Mailserver verschoben (lokal, NAS) und wieder zurück: Flags blieben jeweils erhalten.

Ich denke, daß es beim Provider verloren geht, denn nur die Moves auf deren Server versenken die Flags, bei allen anderen bleibt's erhalten.

Das ist doof, werde am Dienstag mal versuchen, was herauszukriegen.

Mit Apple Mail konnte ich das Verhalten jedoch nicht nachvollziehen, aber da ist mir auch nicht transparent, wie das Flag-Handling erfolgt.

Soweit, so WE.

Hallo,

vielen Dank für die Anregungen, habe ich jetzt nochmal ausprobiert:

Vorweg: KEIN Einsatz von Filtern, alles manuell:

1. alle Tags in TB gelöscht, nur eines angelegt

2. tagge ich eine Mail in der Inbox, bleibt das Tag erhalten beim Switch zu anderen MBen, Foldern, o.ä.

3. verschiebe ich die getaggte Mail in einen leeren Unterordner desselben IMAP-Accounts, wird das Tag für ein paar Sekunden angezeigt und verschwindet dann. Gleiches vice-versa, also von Subfolder zurück in Inbox.

Ich habe das jetzt nochmal eingegrenzt auf meine Mail-Provider; bei meinem "Haupthoster" kann ich das Problem bei unterschiedlichen Mailaccounts reproduzieren (IMAP).

Bei einem anderen Provider (auch IMAP) kann ich markieren und hin- und herschieben, das Tag bleibt erhalten.

Es ist also ein Problem meines Hosters (eigentlich kein kleiner Laden), ggf. (!) im Zusammenspiel mit Thunderbird.

Also gehe ich davon aus, daß das Problem nach aktuellem Stand nicht am TB liegt.

Fallen Euch noch Diagnose-Möglichkeiten ein, die ich zur Diskussion mit meinem Hoster verwenden kann? Laut seiner Aussage "läuft alles".

Danke!

Zitat von Sehvornix

Das Problem ist, dass die Aktionen grundsätzlich in einer anderen Reihenfolge ausgeführt werden können, als sie angelegt wurden. Darauf weist Thunderbird aber auch hin.

Über die Kriterien für die Ausführungsreihenfolge gibt es wenig bekannte Informationen. Es wird wohl versucht, unlogische Abfolgen abzufangen, in dem die Reihenfolge modifiziert wird. Beispiel: verschieben vor taggen wäre ein Problem, weil die bereits verschobene Mail 'weg' ist und somit nicht mehr getaggt werden kann. Jetzt kann man spekulieren, ob die Erkennung von Logikproblemen wirklich unter allen möglichen Varianten alles abfängt.

Du hattest taggen vor verschieben angelegt, was der Logik nach funktionieren müsste. Unbekannt ist, ob und warum Thunderbird ggf. intern die Abarbeitungsreihenfolge geändert hat.

Gruß
Sehvornix

ah, das war mir garnicht bewusst.

und siehe da:

1. taggen

2. verschieben

der eigentliche Fehler ist nun ein anderer, hat m.E. nichts mit den Filtern zu tun:

Beim Verschieben einer Nachricht von einem Ordner in den anderen gehen die Tags verloren; nicht alle, aber die eigenen. Rücksprache mit dem IMAP-Server-Betreiber war negativ, d.h. dort gibt es keine Probleme oder Inkompatibilitäten bzgl. des Taggings von Mails, nach eigener Aussage natürlich....

Also bleibts irgendwie ein Client-Problem, da jetzt nur ich habe. Ich probiere mal weiter....

Zitat von Thunder

Erstelle dazu gerne einen Bug auf BugZilla

werde ich machen, wenn:

Funktioniert das denn bei allen anderen oder haben alle dieses Problem? Das würde mich noch interessieren.

Ergebnis: Filter ohne "verschieben", also einstufig, nur "taggen", funktioniert einwandfrei.

Also komisch ist das: Wenn ich eine Nachricht vom Posteingang in den Unterordner manuell verschiebe (Filter ist aus), dann verschwindet das Tag, und vice-versa.

Das Tag wird erst nach ein paar Sekunden gelöscht, d.h.: Manuelles Verschieben, Nachricht zeigt Tag, andere Nachricht anklicken, wieder zurück zur initialen, Tag ist verschwunden...

Ich habe noch 3 andere Filter, die machen aber nichts, was interferieren könnte.

Protokoll ist IMAP.

Mailbox (in Thunderbird) habe ich "repariert", also einmal neu abgerufen vom Server - same same.

probiere ich gerade, wäre aber nicht meine bevorzugte Lösung, weil ich den Sender-Kreis dauernd anpasse. Müsste dann immer zwei Filter pflegen / kopieren, keine Lust dazu

Aus meiner Sicht wäre das aber auch ein Bug, das muss ja schonmal jemand vor mir erlebt haben...

....Screenshot ist beschnitten wg Privacy, aber man sollte alles Wichtige sehen; die Kriterien stehen auf "any of the following...".

und, wie gesagt, Verschieben geht, unabhängig von der Reihenfolge.

so schaut der aus:

Servus,

ich habe einen simplen Filter:

- Kriterien wie bspw. Sender beinhaltet "@mal.com"

- Aktionen

1. taggen als "To Do"

2. bewegen in unterordner

Nun funktioniert das Taggen nicht, d.h. der 1. Schritt wird nicht (oder falsch) ausgeführt. Die Reihenfolge habe ich schon verändert, kein Unterschied: Verschieben in Unterordner funktioniert, markieren nicht.

Aus meiner Sicht alles richtig, ist ja eigentlich ein Low-Brainer, aber irgendwie geht's net. Vllt übersehe ich was?

Ich danke schonmal für jedweden hilfreichen Kommentar