Mailversand über Freenet nicht mehr möglich

  • Verwende Version 5.3.6.0


    Bei meinem Freenet-Account geht seit ich aus dem Urlaub zurück bin das Mailversenden nicht mehr! (ich denke dass ich da nichts geändert habe)
    Kann mir bitte jemand helfen, das wieder in Betrieb zu bekommen?


    Was geht:
    - Senden/Empfangen bei allen möglichen anderen Accounts (z.B. Yahoo)
    - Empfangen beim Freenet-Account über The Bat!
    - Senden/Empfangen beim Freenet-Account über iPhone und iOS-Mail


    - Senden/Empfangen beim Freenet-Account über Freenet-Webmail



    Problemfall ist also nur Senden von The Bat! aus.


    Einstellungen waren früher:
    - SMPT-Server mx.freenet.de
    - SMTP-Auth aktiv
    - Geschützter Port (TSL)
    - Port 465


    Wenn ich das mache bekomme ich folgende Protokollmeldungen:

    Code
    07.09.2017, 18:46:24: SEND  - Sende Nachricht(en) - 1 Nachricht(en) in der Warteschlange
     07.09.2017, 18:46:24: SEND  - Connecting to SMTP server mx.freenet.de on port 465
     07.09.2017, 18:46:24: SEND  - Einleitung TLS-Handshake
     07.09.2017, 18:46:24: FETCH - Verbindung beendet - 0 Nachricht(en) empfangen
    >07.09.2017, 18:46:24: SEND  - Zertifikat S/N: 9F6D66FC094CC7CC, Algorithmus: RSA (2048 Bits), ausgestellt von 03.03.2017 06:00:38 bis 08.03.2020 23:59:59, für 2 Host(s): *.freenet.de, freenet.de.
    >07.09.2017, 18:46:24: SEND  - Besitzer: DE, freenet.de GmbH, Hamburg, Hamburg, *.freenet.de.
    >07.09.2017, 18:46:24: SEND  - Aussteller: DE, T-Systems International GmbH, T-Systems Trust Center, Nordrhein Westfalen, 57250, Netphen, Untere Industriestr. 20, TeleSec ServerPass Class 2 CA.
    >07.09.2017, 18:46:24: SEND  - Root: DE, T-Systems Enterprise Services GmbH, T-Systems Trust Center, T-TeleSec GlobalRoot Class 2
    !07.09.2017, 18:46:24: SEND  - Server meldet TLS-Fehler: Entschlüsselungsfehler
    !07.09.2017, 18:46:24: SEND  - TLS-Handshakefehler. Verbindung fehlgeschlagen



    Stelle ich auf TSL Port 587, wie es auf der freenet-Hilfeseite (Hilfe) steht bekomme ich


    Code
    07.09.2017, 18:41:41: SEND  - Sende Nachricht(en) - 1 Nachricht(en) in der Warteschlange
     07.09.2017, 18:41:41: SEND  - Connecting to SMTP server mx.freenet.de on port 587
     07.09.2017, 18:41:41: SEND  - Einleitung TLS-Handshake
    !07.09.2017, 18:41:41: SEND  - TLS-Protokollfehler: Unerwartete Nachricht SessionUnknownContentType ct (53)


    Und wenn ich auf STARTTSL mit Port 587 gehe das:




    Also Entweder: Entschlüsselungsfehler oder Protokollfehler 52 oder Protokollfehler 53...
    ... so und jetzt weiß ich nicht mehr weiter.



    Bin für jeden Tipp dankbar,


    FMaus

  • Kann sein, das die SSL-Zertifikate sich geändert haben, aber dein Windows sollte ja was Aktuelles haben.


    Versuche mal folgendes.
    Optionen → S/MIME und TLS…
    (•) Microsoft Crypto API
    OK

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


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

  • Ich habe jetzt eine Nachricht mit v7.4.16 erfolgreich versenden können. Das Protokoll sieht mehr oder weniger genauso wie bei dir aus:

    Insbesondere scheinen auch die Zertifikate zu stimmen. Ich habe übrigens bei "Authentifikation" MD-5 APOP anstelle von Standard aktiviert. Vielleicht hilft's dir.


    Die Fehlermeldungen "SessionUnknownContentType ct (xx)" beziehen sich übrigens darauf, dass die Ports nicht stimmen. Die richtige Einstellung ist daher TLS mit 465. Ganz ohne Verschlüsselung geht's mittlerweile auch bei freenet.de nicht mehr und STARTTLS hat IMO noch nie funktioniert.

  • Kann sein, das die SSL-Zertifikate sich geändert haben, aber dein Windows sollte ja was Aktuelles haben.


    Versuche mal folgendes.
    Optionen → S/MIME und TLS…
    (•) Microsoft Crypto API
    OK

    Hm, dabei ändert sich leider gar nichts. Genau dieselben Fehlermeldungen.



    Ich habe jetzt eine Nachricht mit v7.4.16 erfolgreich versenden können. Das Protokoll sieht mehr oder weniger genauso wie bei dir aus:

    Insbesondere scheinen auch die Zertifikate zu stimmen. Ich habe übrigens bei "Authentifikation" MD-5 APOP anstelle von Standard aktiviert. Vielleicht hilft's dir.


    Die Fehlermeldungen "SessionUnknownContentType ct (xx)" beziehen sich übrigens darauf, dass die Ports nicht stimmen. Die richtige Einstellung ist daher TLS mit 465. Ganz ohne Verschlüsselung geht's mittlerweile auch bei freenet.de nicht mehr und STARTTLS hat IMO noch nie funktioniert.

    TSL mit 465 war auch die Einstellung die zuletzt vor meinem Urlaub funktionierte... :(


    Wo finde ich das "MD-5 APOP"?
    Ist das das "Erweiterte SMPT Optionen" - "Pop vor SMPT"? (hab ne 5.3 Version)
    Falls ja, das hab ich an und es hilft nicht :(


    Danke FMaus

  • Hast du einen Virenscanner/Programm in Verwendung, das die SSL-Verbindungen prüft?

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


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

  • Wo finde ich das "MD-5 APOP"?

    Bei der Authentifikation für den Nachrichtenversand ist bei dir höchstwahrscheinlich eingestellt, dass gleiche Einstellungen wie zum Nachrichtenempfang verwendet werden sollen. Bei der Authentifikation für den Nachrichtenempfang kannst du daher MD-5 APOP aktivieren. POP vor SMPT ist bei mir deaktiviert. Das ist und war auch nie erforderlich bei freenet.de.



    -> Server meldet TLS-Fehler: Entschlüsselungsfehler

    Wenn nichts hilft, muss man diesen Fehler analysieren. In Wiki steht, dass diese Fehlermeldung, die im Original decrypt_error heißt, in der Spezifikation von TLS 1.0 ergänzt wurde. Jetzt muss man die Spezifikation von TLS 1.0 finden (das müsste RFC-2246 sein) und nachschauen, ob dort etwas Konkretes zu diesem Fehler steht, vor allem was ihn hervorrufen kann.

  • Ich habe jetzt etwas gefunden. Auszug aus RFC-2246 (TLS 1.0):

    Code
    decrypt_error
           A handshake cryptographic operation failed, including being
           unable to correctly verify a signature, decrypt a key exchange,
           or validate a finished message.


    Auszug aus RFC-5246 (TLS 1.2):

    Code
    decrypt_error
          A handshake cryptographic operation failed, including being unable
          to correctly verify a signature or validate a Finished message.
          This message is always fatal.


    Klingt also nicht gut. Versuch's mit dem freenet.de Support.

  • Ich tippe bei The Bat! 5.x + Freenet auf inkompatible SSL-Chiffren.


    Bei mir streikt The Bat! 5.8.8 auch. ist aber nur ein unwichtiger Testaccount. Ich werde ihn sowieso löschen da ich nicht zufrieden bin.

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


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

  • Ich tippe bei The Bat! 5.x + Freenet auf inkompatible SSL-Chiffren.

    Daran habe ich auch schon gedacht. Vielleicht haben sie neulich etwas umgestellt. Allerdings hat freenet.de die gleiche Serveradresse für den Versand und Empfang, nämlich mx.freenet.de. Dann müsste auch der Empfang nicht mehr funktionieren, tut er aber.

  • Bei der Authentifikation für den Nachrichtenversand ist bei dir höchstwahrscheinlich eingestellt, dass gleiche Einstellungen wie zum Nachrichtenempfang verwendet werden sollen. Bei der Authentifikation für den Nachrichtenempfang kannst du daher MD-5 APOP aktivieren. POP vor SMPT ist bei mir deaktiviert. Das ist und war auch nie erforderlich bei freenet.de.

    Ah stimmt, beim Empfang gefunden.
    Ok - beim Senden waren spezielle einstellungen gewählt. Aber auch wenn ich auf dieselben gehen klappt's nicht.


    Danke erstmal für Eure Hilfe... werde morgen mal freenet-Support bemühen :(

  • ...


    Nach langer und wenig Information bringender Diskussion mit Freenet-Leuten habe ich als einzige Information bekommen "Im August wurden Sicherheitsstandards aktualisiert".
    Was auch immer das heißen mag... ob ich da mein The Bat! wohl irgendwie drauf anpassen kann?

  • beim Senden waren spezielle einstellungen gewählt. Aber auch wenn ich auf dieselben gehen klappt's nicht.


    Ein kurzer Abgleich. Bei der SMTP-Authentifikation müssen aktiviert sein:


    [x] SMTP-Authentifikation nach RFC 2554
    [x] Gleiche Einstellungen wie zum Nachrichtenempfang verwenden
    [x] Erfordert sichere Authentifikation


    POP vor SMTP hingegen nicht.


    Bei der POP-Authentifikation muss aktiviert sein:


    [x] MD-5 APOP Abfrage/Rückmeldung (RFC 1734)


    Versuch's auch mit MD-5 CRAM. Standard war ja bei dir bereits eingestellt.



    ob ich da mein The Bat! wohl irgendwie drauf anpassen kann?

    Nur durch eine Aktualisierung. Bereits in v6.2.2 wurden neue SSL-/TLS-Standards implementiert. Ich nehme an, dass wenn du testweise v6.8.8 installierst, du damit problemlos senden würdest. Mit der aktuellen v7 sowieso.


    Du könntest auch über einen alternativen Mailserver versenden, der Alias-Adressen zulässt, so z.B. GMail. Wenn du dort deine freenet.de Adresse aktivierst, dann kannst du damit als Absender Nachrichten über den GMail-Server schicken.


    Früher konnte man das auch über freenet.de machen, also als Absender eine andere Mail-Adresse verwenden. Im Januar haben sie das aber abgeschafft, obwohl in den freenet-Einstellungen weiterhin alternative Absenderadressen aktiviert werden konnten. Diesen Dienst bieten sie jetzt wohl nur in ihren kostenpflichtigen Angeboten an. Man bekam jedenfalls eine andere Fehlermeldung, nämlich "Incorrect authentication data". Deswegen trifft das wahrscheinlich in deinem fall nicht zu. Falls doch, musst du die Absenderadresse ändern.

  • Vielleicht bin ich etwas weitergekommen. Der Server mx.freenet.de unterstützt auf dem Port 465 (SMTP) folgende TLS-Versionen und Chiffrensammlungen:


    Und auf dem Port 995 (POP3) folgende:

    Es sind in beiden Fällen zwar 46 Zeilen und alles sieht fast identisch aus, jedoch bemerkt man bei näherer Untersuchung, dass bei SMTP DHE mit 2236 bits, während bei POP3 nur mit 2048 bits ist. Das ist wahrscheinlich das, was im Sommer aktualisiert wurde.


    Ich gehe davon aus, dass v5.3.6.0 bzw. v5.8.8 max. nur 2048 bits unterstützt, so dass zwar der Nachrichtenempfang weiterhin klappt, jedoch nicht der Versand. Vielleicht ändern sie das irgendwann aber auch für POP3, so dass man dann auch nicht mehr empfangen können wird.


    Vielleicht kann dir Ritlabs beantworten, ob das mit v5 stimmt. Wenn ja, dann hilft nur ein Update auf die aktuelle Version oder das, was ich oben vorgeschlagen habe.

  • Und wenn ich auf STARTTSL mit Port 587 gehe das:

    Ich habe jetzt einen Test ohne Verschlüsselung mit dem Standard-Port 25 gemacht und bekam die Fehlermeldung, dass STARTTLS erforderlich ist. Darauf hin habe ich zwar den Verbindungstyp auf STARTTLS umgestellt, jedoch den Port bei 25 belassen. Mit dieser Einstellung konnte ich ebenfalls senden.


    Du hast es mit STARTTLS und 587 versucht. Versuch's also mit 25.

  • Nur durch eine Aktualisierung. Bereits in v6.2.2 wurden neue SSL-/TLS-Standards implementiert. Ich nehme an, dass wenn du testweise v6.8.8 installierst, du damit problemlos senden würdest. Mit der aktuellen v7 sowieso.


    Ok, nachdem das alles irgendwie nicht ging, habe ich mir jetzt dann doch die 7.x-Lizenz gekauft.
    (angeblich gilt die ja sogar für zukünftige 8.x ?)


    Jetzt geht alles wieder, wie es soll.


    Vielen Dank für Eure Hilfe!



    ... so und jetzt muss ich mal forschen gehen, was die 7.x gegenüber der 5.x so neues kann. Ob sich da wohl was lohnt?


    Danke, FMaus

  • nachdem das alles irgendwie nicht ging

    STARTTLS mit 25 klappte also auch nicht?



    angeblich gilt die ja sogar für zukünftige 8.x

    Ist eigentlich umgekehrt. Wer jetzt eine Lizenz erwirbt, bekommt eine v8 Lizenz, die auch für v7 gilt, da es noch keine v8 gibt. In der eMail mit dem Registrierungsschlüssel müsste bei dir The Bat! v8 Key Block stehen.



    was die 7.x gegenüber der 5.x so neues kann

    Die wichtigste Neuerung ist, dass es jetzt eine 32- und eine 64-Bit Version des Programms gibt. Die restlichen Neuerungen ergeben sich aus den jeweiligen Changelogs (vor allem GPGv2-, RSS-, EWS-, CardDav-, OAuth- und 4k-Unterstützung sowie Verknüpfung mit der dt. Online-Hilfe im Programm, wenn man irgendwo auf die Schaltfläche "Hilfe" oder F1 klickt). Ansonsten gab es fast nur Bugfixes.

  • Ist eigentlich umgekehrt. Wer jetzt eine Lizenz erwirbt, bekommt eine v8 Lizenz, die auch für v7 gilt, da es noch keine v8 gibt. In der eMail mit dem Registrierungsschlüssel müsste bei dir The Bat! v8 Key Block stehen.

    Mein alter Schlüssel hatte noch das als Start "The Bat! v5 Key Block:"


    Der Neue hat so etwas nicht... der kommt in einer HTML-Mail und sieht nur noch so aus: "Ihr Produktschlüssel: Bsb....".
    Auch in der Quellcode-Ansicht der Mail ist kein so ein Block zu sehen.

  • der kommt in einer HTML-Mail und sieht nur noch so aus: "Ihr Produktschlüssel: Bsb....".

    Es steht in dieser eMail auch nirgends so etwas wie "Dieser Code ist gültig ab Version xxx bis zu xxx"? Zudem müsste auch im Betreff etwas zu TB!-Version stehen.


    Jedenfalls kann man nach der Schlüsseleingabe unter "Hilfe | Info" zumindest sehen, bis wann dieser Schlüssel gültig ist. Dort müsste "Gültig bis Version 8.9" stehen. Und da der Schlüssel in v7 eingegeben und akzeptiert wurde, gilt er auch für v7.


    In der Nachricht auf der Ritlabs-Webseite steht, dass seit dem 22.08.2017 nur noch Lizenzen für TB! v8.x verkauft werden, die aber auch für v7.x gültig sind, was auch logisch ist, denn es gibt noch keine v8.


    Wenn du also deine nach diesem Datum erworben hast, hast du eine für v7 und v8 erhalten. So etwas müsste aber eigentlich in der eMail mit dem Schlüssel stehen.