Mailversand über Freenet nicht mehr möglich

  • 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:

    Quellcode

    1. 07.09.2017, 18:46:24: SEND - Sende Nachricht(en) - 1 Nachricht(en) in der Warteschlange
    2. 07.09.2017, 18:46:24: SEND - Connecting to SMTP server mx.freenet.de on port 465
    3. 07.09.2017, 18:46:24: SEND - Einleitung TLS-Handshake
    4. 07.09.2017, 18:46:24: FETCH - Verbindung beendet - 0 Nachricht(en) empfangen
    5. >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.
    6. >07.09.2017, 18:46:24: SEND - Besitzer: DE, freenet.de GmbH, Hamburg, Hamburg, *.freenet.de.
    7. >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.
    8. >07.09.2017, 18:46:24: SEND - Root: DE, T-Systems Enterprise Services GmbH, T-Systems Trust Center, T-TeleSec GlobalRoot Class 2
    9. !07.09.2017, 18:46:24: SEND - Server meldet TLS-Fehler: Entschlüsselungsfehler
    10. !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

    Quellcode

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

    Und wenn ich auf STARTTSL mit Port 587 gehe das:

    Quellcode

    1. 07.09.2017, 18:35:01: SEND - Sende Nachricht(en) - 1 Nachricht(en) in der Warteschlange
    2. 07.09.2017, 18:35:01: SEND - Connecting to SMTP server mx.freenet.de on port 587
    3. 07.09.2017, 18:35:01: FETCH - Verbindung beendet - 0 Nachricht(en) empfangen
    4. 07.09.2017, 18:35:01: SEND - Einleitung TLS-Handshake
    5. >07.09.2017, 18:35:01: 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.
    6. >07.09.2017, 18:35:01: SEND - Besitzer: DE, freenet.de GmbH, Hamburg, Hamburg, *.freenet.de.
    7. >07.09.2017, 18:35:01: SEND - Aussteller: DE, T-Systems International GmbH, T-Systems Trust Center, Nordrhein Westfalen, 57250, Netphen, Untere Industriestr. 20, TeleSec ServerPass Class 2 CA.
    8. >07.09.2017, 18:35:01: SEND - Root: DE, T-Systems Enterprise Services GmbH, T-Systems Trust Center, T-TeleSec GlobalRoot Class 2
    9. !07.09.2017, 18:35:01: SEND - Server meldet TLS-Fehler: Entschlüsselungsfehler
    10. !07.09.2017, 18:37:01: SEND - TLS-Protokollfehler: Unerwartete Nachricht SessionUnknownContentType ct (52)
    11. 07.09.2017, 18:37:01: SEND - Verbindung beendet - 0 Nachricht(en) versandt
    12. 07.09.2017, 18:37:01: SEND - Einige Nachrichten wurden nicht versendet - prüfen Sie die Logdatei nach Informationen
    Alles anzeigen



    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
    TheBat! Pro 7.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.0.x • XMP,Regula


    Ich bin Gwendolyn. Wer mich 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:

    Quellcode

    1. 07.09.2017, 19:21:27: SEND - Sende Nachricht(en) - 1 Nachricht(en) in der Warteschlange
    2. 07.09.2017, 19:21:27: SEND - Verbinde mit SMTP-Server mx.freenet.de auf Port 465
    3. 07.09.2017, 19:21:27: SEND - Einleitung TLS-Handshake
    4. 07.09.2017, 19:21:27: 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.
    5. 07.09.2017, 19:21:27: SEND - Besitzer: "DE", "freenet.de GmbH", "Hamburg", "Hamburg", "*.freenet.de".
    6. 07.09.2017, 19:21:27: SEND - Aussteller: "DE", "T-Systems International GmbH", "T-Systems Trust Center", "Nordrhein Westfalen", "57250", "Netphen", "Untere Industriestr. 20", "TeleSec ServerPass Class 2 CA". Gültig ab 11.02.2014 14:39:10 bis 11.02.2024 23:59:59.
    7. 07.09.2017, 19:21:27: SEND - Root: "DE", "T-Systems Enterprise Services GmbH", "T-Systems Trust Center", "T-TeleSec GlobalRoot Class 2" Gültig ab 01.10.2008 10:40:14 bis 01.10.2033 23:59:59.
    8. 07.09.2017, 19:21:27: SEND - TLS-Handshake vollständig
    9. 07.09.2017, 19:21:27: SEND - Verbunden mit dem SMTP-Server
    10. 07.09.2017, 19:21:34: SEND - authentifizieren (Software CRAM-MD5)...
    11. 07.09.2017, 19:21:34: SEND - Sende Nachricht an test
    12. 07.09.2017, 19:21:35: SEND - Nachricht an test versandt (438 Byte)
    13. 07.09.2017, 19:21:35: SEND - Verbindung beendet - 1 Nachricht(en) versandt
    Alles anzeigen
    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.
  • GwenDragon schrieb:

    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.


    sanyok schrieb:

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

    Quellcode

    1. 07.09.2017, 19:21:27: SEND - Sende Nachricht(en) - 1 Nachricht(en) in der Warteschlange
    2. 07.09.2017, 19:21:27: SEND - Verbinde mit SMTP-Server mx.freenet.de auf Port 465
    3. 07.09.2017, 19:21:27: SEND - Einleitung TLS-Handshake
    4. 07.09.2017, 19:21:27: 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.
    5. 07.09.2017, 19:21:27: SEND - Besitzer: "DE", "freenet.de GmbH", "Hamburg", "Hamburg", "*.freenet.de".
    6. 07.09.2017, 19:21:27: SEND - Aussteller: "DE", "T-Systems International GmbH", "T-Systems Trust Center", "Nordrhein Westfalen", "57250", "Netphen", "Untere Industriestr. 20", "TeleSec ServerPass Class 2 CA". Gültig ab 11.02.2014 14:39:10 bis 11.02.2024 23:59:59.
    7. 07.09.2017, 19:21:27: SEND - Root: "DE", "T-Systems Enterprise Services GmbH", "T-Systems Trust Center", "T-TeleSec GlobalRoot Class 2" Gültig ab 01.10.2008 10:40:14 bis 01.10.2033 23:59:59.
    8. 07.09.2017, 19:21:27: SEND - TLS-Handshake vollständig
    9. 07.09.2017, 19:21:27: SEND - Verbunden mit dem SMTP-Server
    10. 07.09.2017, 19:21:34: SEND - authentifizieren (Software CRAM-MD5)...
    11. 07.09.2017, 19:21:34: SEND - Sende Nachricht an test
    12. 07.09.2017, 19:21:35: SEND - Nachricht an test versandt (438 Byte)
    13. 07.09.2017, 19:21:35: SEND - Verbindung beendet - 1 Nachricht(en) versandt
    Alles anzeigen
    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
  • Fmaus schrieb:

    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.


    Fmaus schrieb:

    -> 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):

    Quellcode

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

    Auszug aus RFC-5246 (TLS 1.2):

    Quellcode

    1. decrypt_error
    2. A handshake cryptographic operation failed, including being unable
    3. to correctly verify a signature or validate a Finished message.
    4. 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.
    TheBat! Pro 7.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.0.x • XMP,Regula


    Ich bin Gwendolyn. Wer mich der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • sanyok schrieb:

    Fmaus schrieb:

    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.

    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 :(
  • Fmaus schrieb:

    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.


    Fmaus schrieb:

    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:

    Quellcode

    1. Supported Server Ciphers:
    2. Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-521 DHE 521
    3. Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-521 DHE 521
    4. Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-521 DHE 521
    5. Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
    6. Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 DHE 2048 bits
    7. Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA DHE 2048 bits
    8. Accepted TLSv1.2 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2048 bits
    9. Accepted TLSv1.2 256 bits AES256-GCM-SHA384
    10. Accepted TLSv1.2 256 bits AES256-SHA256
    11. Accepted TLSv1.2 256 bits AES256-SHA
    12. Accepted TLSv1.2 256 bits CAMELLIA256-SHA
    13. Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-521 DHE 521
    14. Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-521 DHE 521
    15. Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-521 DHE 521
    16. Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 2048 bits
    17. Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 2048 bits
    18. Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 2048 bits
    19. Accepted TLSv1.2 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2048 bits
    20. Accepted TLSv1.2 128 bits AES128-GCM-SHA256
    21. Accepted TLSv1.2 128 bits AES128-SHA256
    22. Accepted TLSv1.2 128 bits AES128-SHA
    23. Accepted TLSv1.2 128 bits CAMELLIA128-SHA
    24. Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve P-521 DHE 521
    25. Accepted TLSv1.1 256 bits DHE-RSA-AES256-SHA DHE 2048 bits
    26. Accepted TLSv1.1 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2048 bits
    27. Accepted TLSv1.1 256 bits AES256-SHA
    28. Accepted TLSv1.1 256 bits CAMELLIA256-SHA
    29. Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve P-521 DHE 521
    30. Accepted TLSv1.1 128 bits DHE-RSA-AES128-SHA DHE 2048 bits
    31. Accepted TLSv1.1 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2048 bits
    32. Accepted TLSv1.1 128 bits AES128-SHA
    33. Accepted TLSv1.1 128 bits CAMELLIA128-SHA
    34. Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve P-521 DHE 521
    35. Accepted TLSv1.0 256 bits DHE-RSA-AES256-SHA DHE 2048 bits
    36. Accepted TLSv1.0 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2048 bits
    37. Accepted TLSv1.0 256 bits AES256-SHA
    38. Accepted TLSv1.0 256 bits CAMELLIA256-SHA
    39. Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve P-521 DHE 521
    40. Accepted TLSv1.0 128 bits DHE-RSA-AES128-SHA DHE 2048 bits
    41. Accepted TLSv1.0 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2048 bits
    42. Accepted TLSv1.0 128 bits AES128-SHA
    43. Accepted TLSv1.0 128 bits CAMELLIA128-SHA
    Alles anzeigen

    Und auf dem Port 995 (POP3) folgende:

    Quellcode

    1. Supported Server Cipher(s):
    2. Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-521 DHE 521
    3. Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-521 DHE 521
    4. Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-521 DHE 521
    5. Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 2236 bits
    6. Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 DHE 2236 bits
    7. Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA DHE 2236 bits
    8. Accepted TLSv1.2 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2236 bits
    9. Accepted TLSv1.2 256 bits AES256-GCM-SHA384
    10. Accepted TLSv1.2 256 bits AES256-SHA256
    11. Accepted TLSv1.2 256 bits AES256-SHA
    12. Accepted TLSv1.2 256 bits CAMELLIA256-SHA
    13. Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-521 DHE 521
    14. Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-521 DHE 521
    15. Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-521 DHE 521
    16. Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 2236 bits
    17. Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 2236 bits
    18. Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 2236 bits
    19. Accepted TLSv1.2 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2236 bits
    20. Accepted TLSv1.2 128 bits AES128-GCM-SHA256
    21. Accepted TLSv1.2 128 bits AES128-SHA256
    22. Accepted TLSv1.2 128 bits AES128-SHA
    23. Accepted TLSv1.2 128 bits CAMELLIA128-SHA
    24. Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve P-521 DHE 521
    25. Accepted TLSv1.1 256 bits DHE-RSA-AES256-SHA DHE 2236 bits
    26. Accepted TLSv1.1 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2236 bits
    27. Accepted TLSv1.1 256 bits AES256-SHA
    28. Accepted TLSv1.1 256 bits CAMELLIA256-SHA
    29. Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve P-521 DHE 521
    30. Accepted TLSv1.1 128 bits DHE-RSA-AES128-SHA DHE 2236 bits
    31. Accepted TLSv1.1 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2236 bits
    32. Accepted TLSv1.1 128 bits AES128-SHA
    33. Accepted TLSv1.1 128 bits CAMELLIA128-SHA
    34. Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve P-521 DHE 521
    35. Accepted TLSv1.0 256 bits DHE-RSA-AES256-SHA DHE 2236 bits
    36. Accepted TLSv1.0 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2236 bits
    37. Accepted TLSv1.0 256 bits AES256-SHA
    38. Accepted TLSv1.0 256 bits CAMELLIA256-SHA
    39. Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve P-521 DHE 521
    40. Accepted TLSv1.0 128 bits DHE-RSA-AES128-SHA DHE 2236 bits
    41. Accepted TLSv1.0 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2236 bits
    42. Accepted TLSv1.0 128 bits AES128-SHA
    43. Accepted TLSv1.0 128 bits CAMELLIA128-SHA
    Alles anzeigen
    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.
  • Fmaus schrieb:

    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.
  • sanyok schrieb:

    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
  • Fmaus schrieb:

    nachdem das alles irgendwie nicht ging
    STARTTLS mit 25 klappte also auch nicht?


    Fmaus schrieb:

    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.


    Fmaus schrieb:

    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.