Keine Paßwortübermittlung an SMTP-Server

  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Thunderbird-Version:45.2.0
    * Betriebssystem + Version: Linux 4.4.13-desktop-1.mga5
    * Kontenart (POP / IMAP):POP bzw. POP3
    * Postfach-Anbieter (z.B. GMX):GMX, Kabelmail (Vodafon)
    * Eingesetzte Antiviren-Software: intern deaktiviert
    * Firewall (Betriebssystem-intern/Externe Software): intern Shorewall / (PGL)
    * Router-Modellbezeichnung (bei Sende-Problemen): TP-Link AC1750 Archer C7


    Moin,


    POP und POP3 funktionieren, doch das Versenden von Mails nicht:





    Nun habe ich in den "Einstellungen" die Paßwörter für SMTP gelöscht. Jetzt müsste beim "Senden" das entsprechende Paßwort abgefragt werden, doch es kommt nur die dargestellte Fehlermeldung.



    Bis vor wenigen Tagen funktionierte TB einwandfrei. Nach dem der beschriebene Fehler auftrat habe ich die bis dahin aktivierte interne Antiviren-Software Abfrage deaktiviert. Da wurde das Paßwort abgefragt und die 2 Test-Maisl gesendet. Am nächsten Morgen PC hochgefahren mit TB Mails empfangen, einige Filter eingerichtet, Ordnereigenschaften geändert und einige Nachrichten gekennzeichnet.
    Dann wollte ich eine neu eingegangene Mail weiterleiten und da war sie wieder, die am Anfang stehende Fehlermeldung mit allen ihren beschriebenen Eigenschaften.


    Weiss Jemand Rat?


    Hier noch die SMTP-Server-Einstellungen:




    Bin für gute Vorschläge offen.


    Gruß
    Werner

    Man(n) kann sich ärgern, muss es aber nicht ...

    2 Mal editiert, zuletzt von Werner1 ()

  • Hi,


    Kabel Deutschland (oder jetzt ja eigentlich Vodafone) war bei mir (Raum Dresden) gestern zeitweise ganz tot.
    Woanders auch.
    Vielleicht gibt's einfach technische Probleme, die sich irgendwann hoffentlich in Luft auflösen.


    Gruß, muzel

  • Hi,


    Kabel Deutschland (oder jetzt ja eigentlich Vodafone) war bei mir (Raum Dresden) gestern zeitweise ganz tot.
    Woanders auch.Vielleicht gibt's einfach technische Probleme, die sich irgendwann hoffentlich in Luft auflösen

    Moin,


    In diesem Fall war es das wohl nicht da auch GMX betroffen ist und der Fehler schon länger als gestern existiert.

    Man(n) kann sich ärgern, muss es aber nicht ...

  • Werner1 schrieb:

    In diesem Fall war es das wohl nicht da auch GMX betroffen ist und der Fehler schon länger als gestern existiert.

    Wenn das Problem bei mehreren E-Mail-Anbietern auftritt, ist es sogar wahrscheinlich, daß der Internetprovider "schuld" ist - und das ist bei dir Vodafone?



    Du könntest per telnet testen, ob die smtp-Server erreichbar sind.


    Code
    1. muzel@******:~$ telnet mail.gmx.net 465
    2. Trying 212.227.17.190...
    3. Connected to mail.gmx.net.
    4. Escape character is '^]'.
    5. Connection closed by foreign host.
    6. ...
    7. muzel@******:~$ telnet smtp.kabelmail.de 465
    8. Trying 194.25.41.26...
    9. Connected to smtp.kabelmail.de.
    10. Escape character is '^]'.

    - m.

  • Hi muzel,


    nett das du helfen möchtest. Doch du hast das Problem nicht erfasst. :)


    Die Verbindungen zu den SMTP-Servern sind gegeben.


    Ohne Passwort keine Verbindung zum SMTP-Server.
    Die Abfragemaske für das Passwort wird jedoch nicht angezeigt. Und wenn auch das jeweilige Passwort in "Gespeicherte Zugangsdaten" eingetragen ist kommt es zu der entsprechenden obigen Fehlermeldung. Irgendwo hakt es im Programm, Aber wo :?:


    BTW Mein BS ist Mageia Linux.


    Gruß
    Werner

    Man(n) kann sich ärgern, muss es aber nicht ...

  • Hallo Werner,

    Doch du hast das Problem nicht erfasst.

    Das wage ich bei muzel sehr zu bezweifeln. ER weiß schon, was er schreibt.


    Ohne Passwort keine Verbindung zum SMTP-Server.

    Diese Aussage stimmt so nicht!
    Eine Verbindung zu einem Mailserver kommt bereits zustande, wenn dieser den Client nach den Authentisierungsdaten fragt. Da ist noch kein Passwort im Spiel.
    Deshalb wäre die Aussage richtiger: "Keine Authentisierung an den Mailservern möglich".


    Der Werdegang ist doch folgender:

    • Die Verbindung zw. Client und Server wird aufgebaut.
    • Der Server fragt den Client nach den Authentisierungsdaten.
    • Der Client liefert dem Server Benutzername und Passwort. Kann er diese Daten aus seinem Passwortspeicher liefern, merkt der Nutzer (bis auf die Eingabe des hoffentlich gesetzten Masterpasswortes) davon nichts.
    • Sind im Passwortspeicher keine oder nicht die aktuellen Daten gespeichert, dann leitet der Client die Anfrage des Servers an den Benutzer weiter. Dieser kann die Daten eintragen und den Haken für die Speicherung setzen. Bei der nächsten Abfrage => 3.
    • Gibt der Nutzer ungültige Auth.-Daten ein, wiederholt sich das Spiel.


    Wenn du also im PW-Manager die entsprechenden Einträge gelöscht hast und keine Abfrage nach den Auth-Daten kommt, dann wurde auch keine Verbindung zu den Servern aufgebaut (oder es liegt beim Provider ein internes Problem vor - wovon ich bei zwei unterchiedlichen Providern nicht ausgehe!)


    Hast du denn schon einmal eine andere "Verbindungssicherheit" getestet? Ich kann mich daran erinnern, dass bei gmx STARTTLS gefordert war. Einfach mal mit der geänderten Einstellung (und dann :25) testen.


    Hast du schon kontrolliert, dass dein Shorewall wirklich alle ausgehenden Verbindungen zulässt? Ich vermisse auch das Ergebnis des Tests mit telnet. So viel Zeit sollte schon sein, dieses zu posten und nicht nur zu schreiben, "Die Verbindungen zu den SMTP-Servern sind gegeben".


    Bei Verbindungsproblemen jeglicher Art gilt die alte Regel, zumindest temporär alles zu deaktivieren, was die Verbindung irgendwie behindern könnte.
    (Ich selbst habe mich auf meinen bewusst mehr als "out of the Box" gehärteten Systemen auch schon ausgesperrt ... .)




    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Werner1 schrieb:

    Die Verbindungen sind gegeben.
    ...
    Ohne Passwort keine Verbindung zum SMTP-Server.

    Kein Login, Verbindung schon:


    Code
    1. Connected to mail.gmx.net.


    Die Passwortabfrage kommt erst danach, wenn die SSL-Verschlüsselung aktiviert ist ist. Das geht natürlich "manuell" nicht mehr.
    Ich wollte nur wissen, ob die Server erreichbar sind. Wenn schon vorher z.B. eine Firewall (oder deine Antivirensoftware) dazwischenfunkt, kommt man gar nicht erst soweit.
    Anmelden ist der nächste Schritt, und die TB-Fehlermeldung ist ja auch etwas verschwommen "...nicht erreichbar oder lehnt Verbindung ab" - sagt nicht wirklich, wann und wo es klemmt.
    Daß du Linux hast, habe ich gesehen, deshalb habe ich ja Telnet ins Spiel gebracht, weil es da im Gegensatz zu aktuellen Windows-Versionen problemlos aufrufbar ist.


    - m.


    Peter war mal wieder schneller, na gut... ;)

  • Hi muzel, Hallo Peter,


    vorweg Danke für eure Antwort.

    Daß du Linux hast, habe ich gesehen, deshalb habe ich ja Telnet ins Spiel gebracht, weil es da im Gegensatz zu aktuellen Windows-Versionen problemlos aufrufbar ist.

    Ich vermisse auch das Ergebnis des Tests mit telnet. So viel Zeit sollte schon sein, dieses zu posten und nicht nur zu schreiben,

    Dies war nicht Unhöflichkeit oder Mangel an Zeit, sondern Mangel an Möglichkeit.


    Soweit Mageia und Telnet.

    Hast du schon kontrolliert, dass dein Shorewall wirklich alle ausgehenden Verbindungen zulässt?

    Bedauerlicher Weise weiss ich nicht wie man das kontrolliert und was alle ausgehenden Verbindungen sind? Doch die Frage brachte mich dazu mit den Firewall-Einstellungen im Mageia-Kontrollzentrum zu spielen, die da heißen:

    1. "Alles" markiert - Versand funktioniert über beide Server - PC runtergefahren . Mail-Versand = Fehlermeldung
    2. "E-Mailserver" markiert - weiter wie 1.
    3. "Automatische Erkennung ..." markiert - weiter wie 1.
    4. Nichts markiert - weiter wie 1.


    Bei der "Antivirus-Funktion" in TB haben spätere Veränderungen der Einstellung keinen solchen Effekt gezeigt.


    MfG
    Werner

    Man(n) kann sich ärgern, muss es aber nicht ...

  • Mir ist kein Linux bekannt, bei dem telnet nicht automatisch mit installiert wird oder zumindest in den repos enthalten ist.
    Also starte (meinetwegen per GUI) die Softwareverwaltung deines Systems und installiere telnet. Und genau so wie dein Thunderbird mit deinen Nutzerrechten läuft, braucht auch telnet keine root-Rechte.


    Das was du in deinem Screenshot (Firewall) zeigst, ist - so steht es ja auch deutlich darüber - die Öffnung der Firewall für von außen ankommende Verbindungen. Also, wenn du auf deiner Kiste selber Server betreibst. Aber das ist ja kaum der Fall.

    Dein Problem sind aber abgehende Verbindungen.
    Im Gegensatz zur WinDOSe, wo man (wegen der gerne mal "nach Hause telefonierenden" Schadsoftware) zumindest versucht, auch den abgehenden Verkehr zu reglementieren (sofern dazu ONU überhaupt in der Lage ist!) ist es unter Linux üblich, abgehenden Verkehr generell zuzulassen. Und wenn du keine Server betreibst, brauchst du auch keine Öffnung für ankommenden Verkehr.
    (Nein, ich habe von Mageia keine Ahnung, gehe aber davon aus, dass es da ebenso ist.)


    Mit dem Test mittels telnet kannst du exakt feststellen, ob dein Rechner die betreffenden Server erreicht. Das passiert auf sehr niederen Ebene, so dass evtl. Konfigurationsfehler des Thunderbird außen vor sind. Also, erreichst du mit dem Test ebenfalls die Server nicht, dann musst du die Ursache dafür (=> ein Netzwerkproblem, wo auch immer) finden und beseitigen.


    Was ist mit der alternativen Einstellung der so genannten "Verbindungssicherheit"? Alle drei Möglichkeiten durchtesten, auch KEINE.

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Vor Jahren hatte ich auch mal einen der Vorläufer, also Mandrake oder Mandriva
    (?) getestet, hat mich aber nicht wirklich überzeugt. Nun also also Mageia...
    Ein deaktiviertes Telnet kannte ich bisher nur von Windows, aber dem dürfte ja
    leicht beizukommen sein. Falls es nicht über die Paketverwaltung klappt, dann
    eben rpmfind o.ä., wenigstens um den Paketnamen herauszufinden.
    Grüße, muzel

  • Vielleicht ist es auch da, aber nicht in PATH enthalten. Das ließe sich mit locate telnet und echo $PATH überprüfen.

  • Hallo Susanne,


    Vielleicht ist es auch da, aber nicht in PATH enthalten. Das ließe sich mit locate telnet und echo $PATH überprüfen.


    es ist in den Repos von Mageia, aber nicht bereits vorinstalliert.


    Der Mageia-Nutzer kann entweder das Paket heimdal-telnet oder alternativ das Paket netkit-telnet installieren. Beide enthalten dann den telnet-Befehl.


    Gruß
    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

    Einmal editiert, zuletzt von Feuerdrache ()

  • Hier die Ausgabe von telnet aus dem Paket Netkit-Telnet - danke Feuerdrache -
    vor dem reboot

    Code
    1. bash-4.3$ telnet mail.gmx.net 465
    2. Trying 212.227.17.168...
    3. Connected to mail.gmx.net.
    4. Escape character is '^]'.
    5. Connection closed by foreign host.
    6. bash-4.3$ telnet smtp.kabelmail.de 465
    7. Trying 194.25.41.26...
    8. Connected to smtp.kabelmail.de.
    9. Escape character is '^]'.


    und nach dem reboot meines PC

    Code
    1. bash-4.3$ telnet mail.gmx.net 465
    2. Trying 212.227.17.168...
    3. telnet: connect to address 212.227.17.168: Connection refused
    4. Trying 212.227.17.190...
    5. telnet: connect to address 212.227.17.190: Connection refused
    6. bash-4.3$ telnet smtp.kabelmail.de 465
    7. Trying 194.25.41.26...
    8. telnet: connect to address 194.25.41.26: Connection refused
    9. bash-4.3$

    Ich meine zu erkennen, dass dies meine Schilderung bezüglich des Verhaltens der "Persönlichen Firewall" bestätigt. Der geschilderte Effekt ist mir ja auch nicht erklärlich! ?(



    Was ist mit der alternativen Einstellung der so genannten "Verbindungssicherheit"? Alle drei Möglichkeiten durchtesten, auch KEINE.

    Alle 3, KEINE, STARTTLS und SSL/TLS nach dem reboot getestet. Alle negativ = bekannte Fehlermeldung. :(


    MfG
    Werner

    Man(n) kann sich ärgern, muss es aber nicht ...

  • Tatsächlich ein Linux ohne standardmäßiges Telnet? =O

  • Hallo Susanne,


    Tatsächlich ein Linux ohne standardmäßiges Telnet? =O 


    jain. Es ist ja im Paketdepot vorhanden (man muss es sich also nicht umständlich aus einer vielleicht dubiosen Paketquelle holen), eben nur nicht mit der Installation des Betriebssystems bereits standardmäßig installiert.


    Ich bin da mit openSUSE natürlich auch verwöhnt, wo so etwas ganz natürlich gleich installiert ist. Aber trotzdem: Mageia ist eine feine RPM-basierende Distribution, die ich jedem gerne empfehlen kann.


    Gruß
    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

  • Hallo zusammen,


    mal ganz dumm gefragt, wofür brauche ich eine ("Personal") Firewall? Wie Peter schon erwähnte, soll verhindert werden, daß aus dem Internet ungefragt auf bestimmte Dienste zugegriffen wird. Wenn da aber nichts ist (betreibst du einen Server?), braucht man gar keine Firewall und könnte sie komplett deaktivieren oder gar (falls das geht) deinstallieren.
    Ich fürchte fast, es ist wie mit "Sicherheitssoftware" unter Windows, die oft unerklärliche Dinge tut.


    Gruß muzel

  • Moin muzel,


    wofür brauche ich eine ("Personal") Firewall?

    Die Firewall wird bei Mageia standardmäßig beim Aufsetzen des Systems eingerichtet. Ich habe damit nichts zu tun und ich betreibe keinen Server. Im Mageia-Kontrollzentrum (MCC) wird nur angezeigt in welcher "Sicherheitsstufe" der PC läuft. Von standard bis secure. Auch wird gezeigt mit wie vielen Regeln (86) die Firewall aktiviert ist. Die Regeln können bearbeitet werden, was ich aus Unkenntnis tunlichst unterlasse, doch deaktivieren kann man die Firewall soweit ich erkennen kann nicht.


    MfG
    Werner

    Man(n) kann sich ärgern, muss es aber nicht ...

    Einmal editiert, zuletzt von Werner1 ()

  • Hi,


    ich möchte an dieser Stelle den Beitrag von muzel noch ergänzen:
    Du arbeitest mit Hosenträgern, Gürtel und (Fang-)Netz ;) 

    • Du betreibst keine Server, die von außen erreichbar sein könnten;
    • du betreibst eine/n Firewall (Portfilter), welcher die wegen der nicht vorhandenen Dienste auch nicht geöffneten ("lauschenden") Ports "sicherheitshalber" zusätzlich noch einmal sperrt; und
    • du gehst bestimmt mit einem Router ins Internet, welcher definitiv nur Anfragen aus dem "bösen Netz" an die Geräte deines Netzes weiterleitet, für die du bewusst eine Portweiterleitung (bspw.: ankommende http-Anfragen auf Port 80 werden auf Gerät xyz (hier: der eigene Webserver) auf dessen Port 80 weitergeleitet) angelegt hast. Da du so etwas bestimmt wüsstest, hast du also auch keine derartigen Weiterleitungen und somit blockiert der Router alles, was aus dem Netz ankommt und von deinen eigenen Geräten auch nicht angefordert wurde. Er lässt aber auch alles gehend passieren.

    Sicherlich, wenn bei der Installation des Betriebssystems ein derartiges Portfilter installiert wurde, dann gibt es keinen Grund, dieses wieder zu deinstallieren. Grundsätzlich sind derartige "Firewalls" so eingestellt, dass sie sämtlichen abgehenden Traffic durchlassen und sämtliche ohne Anforderungen durch die eigenen Geräte ankommenden Pakete blockieren. Das System bekommt von diesem Portfilter damit gar nichts mit.
    Zumindest so lange, wie der unbedarfte Nutzer daran nicht herumspielt!


    Jetzt wieder zu deinem Problem und meiner oft geäußerten Bemerkung, zumindest testweise und zur Ursachenfindung alles zu beseitigen, was die Verbindungen irgendwie stören könnte.



    Bei meinem Betriebssystem kann ich über einen einzigen Befehl als root und auch über das grafische Einstelltool "Yast" den Firewall komplett deaktivieren. Das muss auch bei deinem System irgendwie funktionieren.
    Also ausschalten und noch mal testen.


    OK?


    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Hi,


    @muzel und Peter_Lehmann. Danke für die Erläuterungen zur Firewall.


    Jetzt wieder zu deinem Problem und meiner oft geäußerten Bemerkung, zumindest testweise und zur Ursachenfindung alles zu beseitigen, was die Verbindungen irgendwie stören könnte.

    Bedauerlicher Weise weiss ich nicht wie man das kontrolliert und was alle ausgehenden Verbindungen sind?

    Bei meinem Betriebssystem kann ich über einen einzigen Befehl als root und auch über das grafische Einstelltool "Yast" den Firewall komplett deaktivieren. Das muss auch bei deinem System irgendwie funktionieren.
    Also ausschalten und noch mal testen.

    Dazu konnte ich diese Information erlangen: "Dauerhaft schaltest du das Teil im MCC ab, indem du bei den Nutzereinstellungen alle Ports frei gibst." Das sieht so aus, was ich nicht wusste:



    Dies für zu diesem Jo-Jo-Effekt :



    Die Firewall ist deaktiviert und der SMTP-Server von zum Beispiel GMX wird via telnet erreicht.


    Nach einem reboot wird der Status von Shorewall weiter als "stopped" angezeigt aber telnet kann nicht mit dem GMX-Server verbinden


    Bei "Persönliche Firewall einrichten" brauche ich jetzt nur "OK" anklicken und der GMX-Server ist wieder erreicbar. Bis zum nächsten reboot. :-(
    Wie diese Problem entstanden ist - keine Ahnung. Vor einer Woche existierte es noch nicht.
    MfG
    Werner

    Man(n) kann sich ärgern, muss es aber nicht ...