seit Update funktioniert SMTP-Server nicht mehr

Hallo,

ich tippe eher auf Comodo als Problemquelle. Schau dort mal nach, ob das den Mailverkehr überwachen will und deaktiviere diese Option ggf.

MfG
Drachen

Hallo ergy1983,

Ich kann mir wirklich nicht vorstellen, dass du dieses da:

Zitat von ergy1983

Und die Authentifikation auf "keine" gesetzt haben.

... bei uns im Forum (als erfolgreiche Lösung) gelesen hast.
Vor gefühlten 25 Jahren brauchten wir uns am Postausgangsserver nicht anmelden (also Authentifikation = keine), um Mails zu versenden. Jeder konnte einfach so seine Mails versenden. Mit dem Aufkommen von SPAM wurde die Pflicht zur Auth. eingeführt. Ohne dieses geht wirklich nichts!
Im Internet ist bei fast allen Providern üblich: Auth.: "Passwort, normal". Also die Anmeldung am Server mit Benutzernamen und unverschlüsseltem Passwort.

Was die anderen Einstellungen:
- Servernamen
- Format und Inhalt des Benutzernamens (es kann, muss aber bei allen Providern keinesfalls die Mailadresse sein. GMX: Kundennummer empfohlen!)
- die vorgeschriebene Verbindungssicherheit (fast alle Provider erzwingen SSL/TLS oder STARTTLS => genau wie verlangt eintragen!)
- den Port (wird in der Regel durch den TB korrekt eingestellt, trotzdem vergleichen)
- Art der Authentifizierung (s. oben)
- Passwort (es schadet keinesfalls dieses als Anlass zu nutzen, beim Provider je Konto ein neues Passwort zu hinterlegen. Mancher macht das regelmäßig ...)

betrifft, empfehle ich dir, dir die aktuellen Vorgaben sämtlicher Provider von deren Webseite zu holen (*) und diese penibel mit deinen Einträgen zu vergleichen.
(*) Ich empfehle, dabei gleich eine Liste (in einem Heft oder einer verschlüsselten Datei) anzulegen, wo du in einer tabellarischen Übersicht alle diese Fakten sauber einträgst. Das erleichtert spürbar ein evtl.Neueinrichten deiner Mailkonten!

Wenn du jetzt immer noch keinen Erfolg hast, dann mache gleich mal den in unserer Dokumentation beschriebenen Test mit telnet. Im Prinzip sieht das dann so aus:

peter@tuxedo:~> telnet smtp.1und1.de 587 <= entweder diesen oder den Standardport 25, beide gelten auch bei STARTTLS
Trying 212.227.15.183...
Connected to smtp.1und1.de. <= Bestätigung der erfolgreichen Verbindung
Escape character is '^]'.
220 kundenserver.de (mreue003) Nemesis ESMTP Service ready




quit <= Befehl zur Trennung oder einfach auf den timeout warten
221 kundenserver.de Service closing transmission channel
Connection closed by foreign host.
peter@tuxedo:~>

Wenn das so aussieht, erreicht dein Client den Server. Wenn nicht, hast du ein "Verbindungsproblem". Und da hierbei kein Thunderbird benutzt wurde, musst du jetzt auf Betriebssystemebene weitersuchen.

Wie ich lese, benutzt du neben dem Firewall deines Betriebssystems auch noch zusätzlich (oder an Stelle?) das Produkt eines Fremdanbieters.
Hast du dafür wirklich gute Gründe? Mir fallen wirklich keine ein!
Der "Firewall" der moderneren WinDOSen ist völlig ausreichend und es gibt keinen Grund für einen anderen und schon gar nicht für einen zweiten!

Auf jeden Fall solltest du, wenn du noch immer kein positives Ergebnis hast, zuerst den Firewall und dann später auch noch den AV-Scanner komplett deaktivieren (darf nicht mit dem Betriebssystem starten!) und erneut testen.
Oder deinstalliere zumindest zum Test beides und boote auf jeden Fall die Kiste neu.

Und was ist jetzt?

MfG Peter

Nun, es wäre nett gewesen, wenn du bei deinem Eingangsposting schon erwähnt hättest, dass du den Test mit Telnet bereits gemacht hast. Hätte mir einiges an Tipparbeit gespart ... .

Zitat von ergy1983

Mit Telnet von einem anderen Rechner geht alles.

Das bedeutet (vorausgesetzt, dass der andere Rechner am gleichen Netz/Router angeschlossen ist), dass du nicht etwa einen Router der Telekom hast, welcher diverse "nicht-Telekom-Server" blockiert. Also hast du, was die Verbindung zu den SMTP-Servern betrifft, kein Netzwerkproblem. Das Problem liegt also "nur" bei dem betroffenen Rechner.

Zitat

Habe dann Antivir deinstalliert und nun gehen die Standardmailadressen bei Web und Arcor wieder (Ich wurde bei beiden interessanterweise nach dem Passwort gefragt).

Meine Meinung zu dem zweiten zusätzlichen "Firewall" habe ich dir ja schon geschrieben.
Ein AV-Scanner kann niemals den verschlüsselten Traffic der Verbindungen zu den Mailservern überwachen. Deshalb wenden diese Programme einen üblen Trick nach der Art eines "Man in the Middle-Angriffs" an. Nicht dein Mailclient stellt die Verbindung zu den Servern her, sondern der AV-Scanner. Dann verschlüsselt dieser die Verbindugn wieder und der Mailclient verbindet sich mit dem AV-Scanner. Eben "Man in the Middle".
Ein Ergebnis dieser üblen Verfahrensweise spürst du jetzt!
Wenn auch die Überwachung des eingehenden Mailtraffics (also die Verbindung zu den Posteingangsservern) für den Windows-Nutzer den kleinen Vorteil bringt, dass eine Art Vorprüfung auf Schadcode erfolgt, so bezeichne ich die Überwachung des ausgehenden Mailtraffics (also die Verbindung zu den SMTP-Servern) als absolut sinnfrei. Wer sich nicht sicher ist, dass seine Mailanhänge keinen Schadcode enthalten, der sollte besser keine Mails versenden! Oder deutlicher: wer eine als Mailanhang vorgesehene Datei nicht unmittelbar vor dem Anhängen an eine Mail mit einem aktuellen AV-Scanner prüft, der handelt gegenüber seinen Mailpartnern einfach nur fahrlässig! Und wer aber diese Prüfung duirchführt, der kann auf die wesentlich weniger aussagefähige Überwachung des ausgehenden Mailtraffics verzichten!
Also konfiguriere deinen "Virenschutz" so, dass:
- keinesfalls das TB-Userprofil überwacht wird. Also dieses als Ausnahme definieren. Und zwar beim bewussten "on-demand-Scann", wie auch beim "Virenwächter", dem "on-access-Scan".
- keinesfalls der ausgehenden Mailtraffic überwacht wird
- die Überwachung des eingehenden Mailtraffics aktiv ist (zumindest, wenn dieser keine Probleme bereitet)

Was den privaten Mailserver betrifft, solltest du dich mal mit dessen Administrator in Verbindung setzen. Denke mal, dass du diesen persönlich kennst ... .
Ich vermute mal, dass dieser (was bei derartigen Servern gerne mal passiert), noch mit einer veralteten SSL-Version arbeitet, welche die aktuellen TB-Versionen nicht mehr unterstützen.

Noch ein Wort zum Passwort:
Im Unterschied zu den meisten anderen Mailclients erfolgt die erstmalige Abfrage des PW (mit der Möglichkeit der Speicherung im PW-Manager, also dem bekannten zu setzenden "Haken") erst dann, wenn der Server erstmalig vom Client die Benutzerdaten anfordert. Der Client kann das PW noch nicht liefern und leitet diese Abfrage an den Benutzer weiter. Dieser tippt es ein, setzt den Haken für die Speicherung und der Client sendet das PW an den Server. Wenn dieser mit den Anmeldedaten einverstanden ist, fragt dich der TB nie wieder danach (so lange, du das Passwort oder auch den Server nicht änderst).
Wenn der Server aber nun ein anderer ist (z. Bsp. weil dieser jetzt verschlüsselt betrieben wird), wird gefragt.
Erreichst du also (warum auch immer) den Server nicht, kann dieser auch nicht nach dem Passwort fragen ... .
Letzteres zeigt auch das Log. => timeout

MfG Peter