IMAP - TLS-Handshakefehler bei mail.teknik.io

  • Hi,


    ich habe mit der Version 8.7 und einem Konto bei teknik.io seit einiger Zeit das Problem:


    Zitat

    24.02.2019, 20:24:22: IMAP - Verbinde zum IMAP-Server mail.teknik.io auf Port 993
    24.02.2019, 20:24:22: IMAP - Einleitung TLS-Handshake
    !24.02.2019, 20:24:24: IMAP - TLS-Handshakefehler. Eine vorhandene Verbindung wurde vom Remotehost geschlossen

    Ich kann also bspw. beim betreffenden Konto keine Mails im Posteingang sehen. Der Abruf und das Senden mit Thunderbird beim selben Konto klappt einwandfrei.


    Was bedeute diese Meldung und was kann ich tun, um das zu beheben?


    //modedit Im Titel Teknikio hinzugefügt

  • mse: Ich habe im Protokoll keine Zertifikatsfehler, sondern ausschliesslich diesen TLS-Handshakefehler, und dass die Verbindung vom "Remotehost" geschlossen wird (s.o.). - Insofern ist das offenbar nicht vergleichbar, auch wenn es sich ebenfalls um ein "teknik.io-Konto" handelt.

  • hmmm, im von Dir erwähnten Thread half ja wohl:

    Zitat

    *Antispamsniper aktiv, aber SSL geschützte Verbindungen filtern ist nicht angehakt!*
    das war bei mir angehakt und das habe ich geändert, jetzt scheint es zu gehen!

    Antispamsniper nutze ich auch. Nur finde ich die Einstellung "SSL geschützte Verbindungen filtern" nicht. Habe es jetzt gefunden und deaktiviert.


    Ansonsten nutze ich ESET NOD32-AV und dort ist mein Email-Client-Schutz permanent deaktiviert!

  • Habe nun nach dem Deaktivieren einen neuen Fehler im Protokoll (der TLS-Handshake Fehler ist verschwunden):


    Es geht nach wie vor nichts.

  • Ansonsten nutze ich ESET NOD32-AV und dort ist mein Email-Client-Schutz permanent deaktiviert!


    Die entsprechende Option befindet sich oft nicht unter E-Mail-Schutz o.ä. In KIS ist sie z.B. unter den erweiterten Netzwerkeinstellungen zu finden und heißt "Untersuchungen von sicheren Verbindungen". Zu ESET/NOD32 und SSL steht etwas in der Online-Hilfe unter https://help.eset.com/eav/11/de-DE/idh_config_epfw_ssl.html. Wenn also der Fehler bleibt, dann musst du entweder die entsprechende Option in ESET/NOD32 ausschalten oder dort eine Ausnahme erstellen.

  • Bei meinem NOD32 ist die SSL-Filterung ebenfalls komplett deaktiviert:



    Das kann´s also leider auch nicht sein ... :(



  • Ich bekomme keinerlei Zertifikatswarnungen von TheBat! Keine "ungültigen" Zertifikate werden mir angezeigt.

    Wie ich bereits in dem anderen Thread beschrieben habe, musst du im TB!-Adressbuch "Trusted Root CA" anzeigen lassen und dort nach dem in deinem Fall relevanten Zertifikat "DST Root CA X3" suchen. Jetzt klickst du darauf zweimal, dann auf den Reiter "Zertifikate" und dort auf den Eintrag "DST Root CA X3" doppelklicken. Im nächsten Fenster muss "Dieses Zertifikat ist gültig" stehen und nicht so, wie auf dem Screenshot von Liquid Soul im anderen Thread - "Dieses Zertifikat ist ungültig". Findest du dieses Zertifikat unter Trusted Root CA überhaupt? Wenn ja, ist es gültig?

  • und jetzt ?

    Dann ist es ein serverseitiges Problem, das du leider nicht lösen kannst. Ich glaube, dass teknik.io bereits darauf hingewiesen wurde. Vielleicht postet Liquid Soul das Ergebnis im anderen Thread. Du könntest teknik.io auch kontaktieren.


    Außerdem wurde auch schon im Ritlabs BugTracker ein Eintrag gemacht - #0001701: Connection to mail server at teknik.io fails because of algorithm ECC. Wenn du dort bereits registriert bist, dann kannst du ihn bestätigen. Wenn nicht, dann kannst du dich registrieren, wenn du willst. Einzelheiten unter https://www.batboard.net/index…40-BugTracker-Verwendung/. Ich empfehle, die Sprache von TB! auf Englisch umzuschalten, eine Verbindung zum Server aufzubauen und dann das Protokoll auf Englisch im BugTracker zu posten, damit Ritlabs die genaue Fehlermeldung sieht.


    Du könntest es testweise auch mit anderen Einstellungen versuchen. Ich habe etwas dazu im anderen Thread geschrieben, also STARTTLS oder ganz ungeschützt.

  • Ich habe testweise einmal auf "Standard" umgestellt, und dann erneut auf TLS (993)


    Ergebnis:


    Zitat

    24.02.2019, 22:54:57: IMAP - Verbinde zum IMAP-Server mail.teknik.io auf Port 143
    24.02.2019, 22:54:58: IMAP - Verbunden mit IMAP-Server (mail.teknik.io)
    >24.02.2019, 22:54:58: IMAP - IMAPrev1
    24.02.2019, 22:54:58: IMAP - Authentifiziere (Benutzer: "xxxx@teknik.io", Methode: "LOGIN")...
    24.02.2019, 22:54:58: IMAP - IMAP-Server Authentifikation OK - IMAP-Server meldet: "LOGIN completed"


    habe soeben auch eine Testmail geschickt und sie empfangen können. Papierkorb vom Server wird auch wieder aktualisiert angezeigt.
    Das war es jetzt "schon" ... ? Was bedeutet IMAPrev1 ?



    Dann versucht zu senden. Ergebnis - Senden geht nicht. Empfangen geht (bisher)!


  • teknik.io funktioniert nicht mit STARTTLS oder TLS egal wie. Wegen des neuen Zertifikats. Ärgerlich.
    Der Bug ist schon an Ritlabs gemeldet.

    The Bat! Pro 9.x BETA (32bit) | Win 10 Pro x64 | GnuPG 2.2.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Ich habe testweise einmal auf "Standard" umgestellt, und dann erneut auf TLS (993)

    Laut Protokoll wurde aber auf Port 113 zugegriffen. Also hast du wohl STARTTLS eingestellt. Oder TLS mit dem falschen Port. Alle Zugangsdaten, vorausgesetzt dass sie immer noch stimmen, sind auf der offiziellen Seite unter https://help.teknik.io/Mail zu finden.


    Hat's übrigens mit Standard und Port 25 geklappt?



    Was bedeutet IMAPrev1 ?

    Das müsste wohl richtigerweise IMAP4rev1 heißen (also IMAP Version 4 Revision 1) und wäre eine andere Bezeichnung für IMAP4. Steht zumindest bei mir bei einem IMAP-Server IMAP - IMAP4rev1 Hello.



    Dann versucht zu senden. Ergebnis - Senden geht nicht. Empfangen geht (bisher)!

    Bei Liquid Soul ist es umgekehrt - Empfangen geht nicht, aber Senden schon. Und es soll beides mit Voyager v7 gehen.