SSL/Zertifikat /// ERR authentication failed (GMX/Web.de) Probleme

  • Ich benutze zum Verbinden, seit Ewigkeiten schon, ausnahmslos immer nur die jeweilige GMX-Kundennummer, nicht die Email Adresse

    Hast du es denn auch mit der eMail-Adresse versucht? Laut GMX-Anleitung soll man jedenfalls als Benutzernamen die eMail-Adresse verwenden. Das muss man z.B. auch, wenn man sich auf der GMX-Webseite einloggen möchte.

  • Hast du es denn auch mit der eMail-Adresse versucht? Laut GMX-Anleitung soll man jedenfalls als Benutzernamen die eMail-Adresse verwenden. Das muss man z.B. auch, wenn man sich auf der GMX-Webseite einloggen möchte.

    Nein, dass habe ich noch nicht ausprobiert.

    Auf die Idee kam ich nicht, denn ich bekam ja, via der Kundennummer, über The Bat 3.86, seit unzähligen Jahren schon, problemlos Zugriff auf alle meine GMX Konten.

    Der GMX Kundendienst riet mir früher dazu, mich statt via Mail-Adresse via Kundennummer einzuloggen (auch via Mail-Programmen). Auch heute findet man diese Info noch als Problemlösungs-Tipp auf diversen Seiten, z.B. hier: Login-Probleme bei GMX: die 3 besten Lösungen

    Aber ich probiere es jetzt in TB 7.3.6 mal via den Mailadressen. Melde mich wieder ob es damit vlt. klappt.

  • Ja, aber wohl mit einem falschen Port, denn in deinem Protokoll steht: "Verbinde mit SMTP-Server mail.gmx.net auf Port 587", müsste aber "465" sein. Steht auch auf der offiziellen GMX-Infoseite.

    Upps, da habe ich wohl etwas übersehen.

    Ich habe das GMX Konto nun neu eingerichtet. So wie es aussieht, sind die Voreinstellungen für ein neues Konto in TB! für GMX falsch.
    Beim Empfangen ist (TLS) 995 voreingestellt, und beim Senden (TLS) 587.


    Nachdem ich nun nachträglich den korrekten Port 465 eingestellt habe, gibt es auch unter W7 64bit keinerlei Probleme mit der aktuellen v7.

  • Habe für TB 7.3.6 unter Win 7 die Lösung gefunden! Diese Version funktioniert jetzt bei mir mit allen Konten einwandfrei. :thumbup:

    Es lag an den Passwörtern.

    Fast alle meine Passwörter enthalten u.a. auch Umlaute und Sonderzeichen.

    Nur einige wenige Passwörter sind ohne Umlaute und Sonderzeichen, dass waren die wenigen Konten, die bisweilen problemlos abgerufen wurden und wovon ich berichtete.

    Ich hatte alle Kontoeinstellungen für die 7.3.6 aus der alten 3.86 Version bezogen, durch Datensicherung/Wiederherstellung.

    Es entstand das Problem, dass alle Umlaute in Passwörtern, die unter "Empfang - POP3" in Version 7.3.6 automatisch eingetragen wurden, fehlerhaft eingetragen wurden! In der Sicherung selbst stimmten die Umlaute jedoch alle (getestet durch zurückspielen der Sicherung in Version 3.86).

    Ich behaupte also mal, dass das dann ein Bug ist in 7.3.6 und nicht an der Unterschiedlichkeit der Versionen 3.86 / 7.3.6 liegt. Denn die selben Passwörter werden auch noch an einer weitern Stelle aus der Sicherung von 3.86 unter 7.6.3 automatisch eingetragen. Nämlich unter "Erweiterte SMPT-Optionen" (Authentifikation), wo ich bei allen meinen Konten eingestellt habe: SMTP-Authentifikation nach RFC 2554 - "Besondere Einstellungen verwenden". Dort wird ebenfalls selbiger Benutzername und selbiges Passwort wie unter "Empfang - POP3" eingetragen und dort stimmt der automatische Eintrag aber, sprich alle Umlaute sind dort richtig, bei allen Konten!

    Ich wäre mit Sicherheit schon früher drauf gekommen was los ist, wäre mein uraltes Sternchen Passwort Tool in der Lage gewesen, in der Version 7.3.6 die PW sichtbar zu machen. Aber bei der neuen TB Version versagte es leider, hatte es mehrfach vergeblich versucht.

    Ich hatte zwar in 2 Konten, die Passwörter von Hand eingetragen, zum testen, dummerweise aber genau zwei der Konten erwischt, wo die Passwörter keine Umlaute enthielten.

    Weil aber ja 2-4 Konten immer wieder problemlos abgerufen wurden, bei meinen Versuchen, kam ich ins Grübeln, ob es vlt. doch an den Passwörtern liegen kann bei den anderen Konten. Und auch weil sanyok in seinem vorletzten Post, außer den Transporteinstellungen, die Zugangsdaten erwähnte, als eventuelle Problemursache.

    Ich suchte nach einem anderen, neueren Tool, welches Sternchen-PW sichtbar machen kann. Dann sah ich die Bescherung.

    Nachdem ich dann in 97% meiner Konten die ganzen fehlerhaften Umlaute in den Passwörtern berichtigt hatte, wurden endlich alle Konten abgerufen.

    In allen Konten habe ich übrigens auch weiterhin, nicht die jeweiligen Email Adressen als Benutzernamen eingetragen, sondern die GMX-Kundennummern. Funzt bestens damit.

    Ein großes Problem ist gelöst.

    Danke für Eure freundliche Unterstützung :)

    Gelegentlich werde ich auch noch versuchen, ob Version 7.3.6 auch auf meinem alten XP PC funktioniert. Ich berichte das Ergebnis dann.

  • Alle Nicht-ASCII-Zeichen können auf vielen Mailservern Probleme breiten.
    Denn beim Login weiß der Mailserver nicht, in welcher Zeichenkodierung die Nicht-ASCII-Zeichen gesendet wird.
    Es sei denn er kann UTF8-Zeiochen bei der Authentifizierung verarbeiten. Aber das sagt er dem Mailcient dann auch, was er kann.
    Die Server von GMXWebde machen das aber nicht, sie annoncieren kein UTF8 bei SMTP-Auth, dasselbe bei POP3


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

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

    2 Mal editiert, zuletzt von GwenDragon (26. Oktober 2016 um 09:38)

  • Ich behaupte also mal, dass das dann ein Bug ist in 7.3.6 und nicht an der Unterschiedlichkeit der Versionen 3.86 / 7.3.6 liegt.

    Es könnte daran liegen, dass u.a. das Format der Datensicherung in v4.1 verändert wurde. Sicherungen von älteren TB!-Versionen waren jedoch auf neueren TB!-Versionen weiter wiederherstellbar, nur nicht umgekehrt.


    Alle Nicht-ASCII-Zeichen können auf vielen Mailservern Probleme breiten.

    GMX kann damit umgehen. Das Problem hier lag darin, dass beim Aufspielen der TBK-Sicherung in v7 diese Zeichen verlorengegangen waren bzw. ersetzt wurden. Da sich das Passwort hinter Sternchen versteckt, fiel das nicht sofort auf.

  • GMX kann damit umgehen. Das Problem hier lag darin, dass beim Aufspielen der TBK-Sicherung in v7 diese Zeichen verlorengegangen waren bzw. ersetzt wurden.

    Ah, ok, dann hab ich das falsch aufgefasst.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

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

  • Wurde das überarbeitet?

    Nicht seit 2009. Seitdem hat sich die Struktur der ACCOUNT.CFN ja auch nicht geändert.


    Bisher ging mit Version größer als v4 nichts mehr

    Vielleicht nicht mit OTFE, aber ansonsten klappte es bei mir bisher mit jeder TB!-Version. Gerade z.B. mit v7.3.12.1 getestet.

    Damit es keine Missverständnisse gibt. Das Tool heißt "The Bat! Password Recovery" und für mich hatte es daher bisher ausschließlich die Funktion eines Benutzername- und Passwortwiederherstellungsprogramms. Ob das Tool auch andere Einstellungen anzeigen kann, habe ich nie ausführlich getestet. Die kann ich mir notfalls von der Webseite des Mailproviders holen.

  • Vielleicht nicht mit OTFE, aber ansonsten klappte es bei mir bisher mit jeder TB!-Version. Gerade z.B. mit v7.3.12.1 getestet.

    Du hast recht sanyok, ich bin immer davon ausgegangen das nach der v4 nichts mehr geht - steht auch in der Password Recovery Readme, dass das Programm als letztes mit der v4 getest wurde.
    Ich konnte hier auch alles mit der v7 auslesen. :thumbup: Gut das wir drüber gesprochen haben. :)


    PS. Unter Windos 10 (64bit) bekomme ich eine Fehlermeldung das die COMCTL32.OCX nicht korrekt installiert sein. Ich habe sie auch mal in den Sytemordner kopiert, half aber nichts.

  • Unter Windos 10 (64bit) bekomme ich eine Fehlermeldung das die COMCTL32.OCX nicht korrekt installiert sein. Ich habe sie auch mal in den Sytemordner kopiert, half aber nichts.

    Die Datei ist ja bereits im Archiv mit dabei. Wenn sie also ins gleiche Verzeichnis wie EXE entpackt wird, müsste es keine Fehlermeldungen geben. Wenn sie aber gelöscht wird, gibt's in der Tat den Run-time error 339.

  • Wenn sie also ins gleiche Verzeichnis wie EXE entpackt wird, müsste es keine Fehlermeldungen geben. Wenn sie aber gelöscht wird, gibt's in der Tat den Run-time error 339.

    Die Datei war dabei und lag im gleichen Ordner. Ich meine das ich sogar zum Testen in einem Admin-Koto eingeloogt war. Ich habe die Datei auch zweimal runter geladen, falls beim erssten Dowlod was schiegf gegangen ist. Keine Chance, immer diese Fehlermeldung. Vielleicht sollte mal jemand anders dies unter w10 testen.

  • Vielleicht sollte mal jemand anders dies unter w10 testen.

    Ich habe das jetzt mit Win10 x64 über eine virtuelle Maschine getestet und kann bestätigen, dass der Run-Time Error 339 erscheint. Allerdings nur beim allerersten Programmstart. Danach kam die Fehlermeldung auch nach dem Windows-Neustart nicht mehr.