Problem: Wählerischer SMTP-Server

[Bernhard]

Hi!

Ich habe momentan ein Problemchen mit dem Versenden von E-Mails:

Ich verwende den Mozilla Thunderbird Portable (version 2.0.0.21 (20090302)) und seit einiger Zeit kann ich keine E-Mails mehr verschicken, obwohl der Empfang problemlos funktioniert. Ich werde ein paar Mal nach dem Passwort gefragt, dann verweigert der SMTP-Server die Verbindung ("authentication failed", Log siehe unten). Laut Auskunft meines Providers wird Thunderbird angeblich "nicht unterstützt"; ein Versuch mit MS Outlook Express und identischen Einstellungen war auch tatsächlich erfolgreich (ich habe die Einstellunge im Thunderbird oft überprüft, dort ist wirklich alles identisch: Benutzername, Passwort, Servername, -port und jeweils keine verschlüsselte Verbindung eingestellt). Mit einem herkömmlichen (nicht portablen) Thunderbird geht nix.

Bisher habe ich nicht gewusst, dass auch SMTP-Server irgendwie Clients identfizieren können. Wikipedia hat aber meine Vermutung bestätigt, dass das Konzept des "User Agent Strings" auch bei E-Mails angewendet wird. Also will ich diesen String spoofen. Leider funktioniert der Versand trotzdem immer noch nicht. MSOE identifiziert sich nämlich mit einem Eintrag "X-Mailer" statt "User-Agent" im Header, außerdem schreibt der T-Bird einige zusätzliche Einträge mit "X-Mozilla", die möglicherweise auch zum Identifizieren dienen können. Jedenfalls ändert es nichts, wenn ich den User-Agent gänzlich weglasse.

Kann mir jemand sagen, ob/wie ich Thunderbird trotzdem als Outlook tarnen kann? Oder dass mein Problem vielleicht gar nicht mit dem Header-Eintrag zusammenhängt (telepathische Kräfte des Servers o.ä)? Muss ich mich vielleicht sogar von meinem Provider nötigen lassen, einen bestimmten Client zu verwenden??

Wäre für diesbezügliche Tipps wirklich sehr dankbar...

Gruß
Bernhard

Auszug aus dem Thunderbird-Log (nach dieser Anleitung erstellt):
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250-ENHANCEDSTATUSCODES
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250-PIPELINING
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250-8BITMIME
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250-SIZE 16777216
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250-DSN
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250-AUTH LOGIN PLAIN
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250-DELIVERBY
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 250 HELP
0[234488]: SMTP entering state: 4
0[234488]: SMTP entering state: 22
0[234488]: SMTP entering state: 17
0[234488]: Logging suppressed for this command (it probably contained authentication information)
0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 535 5.7.0 authentication failed
0[234488]: SMTP entering state: 19
0[234488]: SMTP entering state: 22
0[234488]: SMTP entering state: 16
0[234488]: SMTP Send: AUTH LOGIN0[234488]: SMTP entering state: 0
(... dergleichen mehr)
0[234488]: SMTP Send: AUTH LOGIN0[234488]: SMTP entering state: 0
0[234488]: SMTP Response: 421 4.7.0 txyz.com Too many bad commands; closing connection
0[234488]: SMTP entering state: 14
0[234488]: SMTP entering state: 19
0[234488]: SMTP entering state: 22
0[234488]: SMTP entering state: 17
0[234488]: Logging suppressed for this command (it probably contained authentication information)
0[234488]: SMTP connection dropped after 541 total bytes read

[Rouven]

Hello,

ich frag nur mal interessehalber, weil jemand bei mir in der Familie mit einem Outlook 2000 ähnliche Probleme hat: T-Online?

MfG
Rouven

[Bernhard]

Hi!

ich frag nur mal interessehalber, weil jemand bei mir in der Familie mit einem Outlook 2000 ähnliche Probleme hat: T-Online?

Nein - zumindest nicht direkt. Telering wurde meines Wissens aber vor ein oder zwei Jahren von T-Mobile gekauft.

Gruß
Bernhard

[Der Martin]

Hallo,

Ich werde ein paar Mal nach dem Passwort gefragt, dann verweigert der SMTP-Server die Verbindung ("authentication failed", Log siehe unten). Laut Auskunft meines Providers wird Thunderbird angeblich "nicht unterstützt"

das halte ich a) für eine technisch unqualifizierte Auskunft und b) für eine Frechheit, wenn's wirklich so wäre. Solange ein x-beliebiger Client das Protokoll korrekt einhält (und T-Bird tut das, soweit ich ihn kenne), dann geht es den Server einen Dreck an, *wer* der Client ist.

ein Versuch mit MS Outlook Express und identischen Einstellungen war auch tatsächlich erfolgreich (ich habe die Einstellunge im Thunderbird oft überprüft, dort ist wirklich alles identisch: Benutzername, Passwort, Servername, -port und jeweils keine verschlüsselte Verbindung eingestellt).
Mit einem herkömmlichen (nicht portablen) Thunderbird geht nix.

Sehr seltsam.

Bisher habe ich nicht gewusst, dass auch SMTP-Server irgendwie Clients identfizieren können.

Können sie auch nicht wirklich.

Wikipedia hat aber meine Vermutung bestätigt, dass das Konzept des "User Agent Strings" auch bei E-Mails angewendet wird.

Ja, aber hier wird dieser User Agent erst mit dem Nutzinhalt der Mailnachricht als X-Header übermittelt, nicht im SMTP-Dialog, d.h. nicht schon beim Verbindungsaufbau bzw. bei der Authentifizierung. Hast du vielleicht SMTP über SSL eingestellt, und der Server will lieber eine unverschlüsselte Verbindung? Oder umgekehrt?

Also will ich diesen String spoofen. Leider funktioniert der Versand trotzdem immer noch nicht. MSOE identifiziert sich nämlich mit einem Eintrag "X-Mailer" statt "User-Agent" im Header, außerdem schreibt der T-Bird einige zusätzliche Einträge mit "X-Mozilla", die möglicherweise auch zum Identifizieren dienen können.

Kann ich bei den Mails, die ich von einem T-Bird 2.0.0.22 erhalten habe, nicht bestätigen. Okay, "User-Agent" anstatt "X-Mailer" schon, aber nicht die zusätzlichen Einträge mit "X-Mozilla".

Jedenfalls ändert es nichts, wenn ich den User-Agent gänzlich weglasse.

Das deutet darauf hin, dass das Problem ganz woanders liegt.

Muss ich mich vielleicht sogar von meinem Provider nötigen lassen, einen bestimmten Client zu verwenden??

Wenn es so wäre, würde ich eher den Provider als den Mailclient wechseln. Das wäre eine Unverschämtheit.

So long,
 Martin

[Bernhard]

Hi!

Laut Auskunft meines Providers wird Thunderbird angeblich "nicht unterstützt"
das halte ich a) für eine technisch unqualifizierte Auskunft und b) für eine Frechheit, wenn's wirklich so wäre. Solange ein x-beliebiger Client das Protokoll korrekt einhält (und T-Bird tut das, soweit ich ihn kenne), dann geht es den Server einen Dreck an, *wer* der Client ist.

a) hätte ich bis zu dieser Erfahrung genauso eingeschätzt; offensichtlich gibt es aber Mittel und Wege für einen Provider, seinen Kunden ziemlich einzuschränken. Zu b) ist nichts hinzuzufügen.

Ja, aber hier wird dieser User Agent erst mit dem Nutzinhalt der Mailnachricht als X-Header übermittelt, nicht im SMTP-Dialog, d.h. nicht schon beim Verbindungsaufbau bzw. bei der Authentifizierung.

In der Tat. Ich kann leider nicht genug SMTP, um aus dem Log rauszukriegen, ob der Server nicht möglicherweise ein fehlgeschlagenes Login vorgaukelt, obwohl er eigentlich den T-Bird nicht mag. Klingt vielleicht etwas weit hergeholt, aber die Frage bleibt: Wieso sollte ich mich sonst mit MSOE authentifizieren können und mit dem T-Bird nicht?

Hast du vielleicht SMTP über SSL eingestellt, und der Server will lieber eine unverschlüsselte Verbindung? Oder umgekehrt?

Nein, siehe erster Absatz: Habe bei T-Bird wie bei MSOE eine unverschlüsselte Verbindung eingestellt.

Kann ich bei den Mails, die ich von einem T-Bird 2.0.0.22 erhalten habe, nicht bestätigen. Okay, "User-Agent" anstatt "X-Mailer" schon, aber nicht die zusätzlichen Einträge mit "X-Mozilla".

Ein Testmail, das ich nach den erfolglosen Sendeversuchen in den Drafts gespeichert habe, beginnt z.B. mit:
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Jedenfalls ändert es nichts, wenn ich den User-Agent gänzlich weglasse.
Das deutet darauf hin, dass das Problem ganz woanders liegt.

Möglich. Nur wo??

Muss ich mich vielleicht sogar von meinem Provider nötigen lassen, einen bestimmten Client zu verwenden??
Das wäre eine Unverschämtheit.

Jo, das wäre es.

Gruß
Bernhard

[Der Martin]

Hallo,

Ja, aber hier wird dieser User Agent erst mit dem Nutzinhalt der Mailnachricht als X-Header übermittelt, nicht im SMTP-Dialog, d.h. nicht schon beim Verbindungsaufbau bzw. bei der Authentifizierung.
In der Tat. Ich kann leider nicht genug SMTP, um aus dem Log rauszukriegen, ob der Server nicht möglicherweise ein fehlgeschlagenes Login vorgaukelt, obwohl er eigentlich den T-Bird nicht mag.

mein Problem ist, dass das, was du gepostet hast, kein Log des SMTP-Dialogs ist, sondern eher eine Abfolge von Debug-Ausgaben von T-Bird, aus der man bestenfalls erraten kann, was wirklich passiert. Die SMTP-Protokolle von Outlook Express sind da wesentlich informativer, weil sie einen 1:1-Mitschnitt der Client/Server-Kommunikation darstellen (was ein Sicherheitsproblem sein kann, weil auch Kennwörter darin unverschlüsselt protokolliert werden).

Kann ich bei den Mails, die ich von einem T-Bird 2.0.0.22 erhalten habe, nicht bestätigen. Okay, "User-Agent" anstatt "X-Mailer" schon, aber nicht die zusätzlichen Einträge mit "X-Mozilla".
Ein Testmail, das ich nach den erfolglosen Sendeversuchen in den Drafts gespeichert habe, beginnt z.B. mit:
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Ach das meinst du. Das speichert der T-Bird nur zu seinem eigenen Vergnügen in seiner Mailbox-Datei. Diese Zeilen werden nicht mit übertragen - weder sende- noch empfangsseitig. Kann man leicht nachprüfen - zum einen mit Wireshark, zum anderen dadurch, dass diese Headerzeilen beim "gegnerischen" Mailclient nicht im Protokoll auftauchen.

Das deutet darauf hin, dass das Problem ganz woanders liegt.
Möglich. Nur wo??

Kann ich so noch nicht sagen. Ein *echtes* SMTP-Protokoll könnte vielleicht helfen. Da T-Bird anscheinend keins produzieren will, hilft wohl nur noch die schwere Netzwerk-Panzerfaust: Wireshark.

Ciao,
 Martin

[Bernhard]

Hi!

Das deutet darauf hin, dass das Problem ganz woanders liegt.
Möglich. Nur wo??

Kann ich so noch nicht sagen. Ein *echtes* SMTP-Protokoll könnte vielleicht helfen. Da T-Bird anscheinend keins produzieren will, hilft wohl nur noch die schwere Netzwerk-Panzerfaust: Wireshark.

Oioi, dann muss ich mich wohl im Laufe der Woche mal mit Wireshark auseinandersetzen (ich hatte noch nie das Vergnügen). Ich frage nochmal, sobald ich so ein Wireshark-Log produziert habe.

Gruß
Bernhard

[Bernhard]

Hi!

Oioi, dann muss ich mich wohl im Laufe der Woche mal mit Wireshark auseinandersetzen (ich hatte noch nie das Vergnügen). Ich frage nochmal, sobald ich so ein Wireshark-Log produziert habe.

So, Wireshark hat mich schon etwas schlauer gemacht:

Thunderbird meldet sich per EHLO und spricht wie in den Beispielen auf dieser Seite mit dem Server. Zuerst versucht er AUTH PLAIN, dann AUTH LOGIN. Der Server sagt allerdings nicht wie im Beispiel OK sondern jeweils:
"535 5.7.0 authentication failed"

Passwort und Benutzer werden korrekt übertragen (natürlich base64-kodiert). Ich sehe keine Möglichkeit, wie Thunderbird am Nichtzustandekommen der Anmeldung Schuld sein könnte. Nach Benutzer und Passwort folgt jeweils ein "\r\n", aber das ist bei allen anderen SMTP-Paketen und auch bei MSOE genauso. Sonst gibts da nix, was nicht passen könnte. Der Server antwortet jedenfalls auf das EHLO mit einer "Response: 250-AUTH LOGIN PLAIN\r\n", was zumindest eines der zwei Verfahren (PLAIN oder LOGIN) ermöglichen sollte.

Preisfrage: Warum funktioniert das mit Outlook Express? =>Weil OE auf ESMTP verzichtet und sich beim Server am Anfang einfach mit HELO statt EHLO meldet.

Lösung für das Problem hab ich keine gefunden; bei Mozilla findet sich zwar ein Eintrag zur Option mail.auth_login, die angeblich SMTP-AUTH deaktivieren kann, allerdings ändert es nichts am Ablauf des Authentifikationszwiegesprächs, wenn man sie auf false setzt (auch in Kombination mit der Option mail.server.default.auth_login).

Ich bin ziemlich ratlos. Das einzige, was mir noch einfällt, ist, andere Clients zu Vergleichszwecken auszuprobieren, und zu schauen, was mit denen rauskommt. Hat vielleicht noch jemand andere Tipps?

Gruß
Bernhard

[Bernhard]

Hallo!

Ich habs doch noch hinbekommen (aber auch ein paar Nerven weniger): Mit der Integer-Option "mail.smtpserver.smtp1.auth_method" kann man Thunderbird ESMTP abgewöhnen -- einfach auf 0 setzen.

Vielen Dank für die Geburtshilfe an Martin, der Hinweis auf Wireshark wars einfach. :-)

Schöne Grüße und gute Nacht/guten Morgen
Bernhard

[Rouven]

Hello,

Vielen Dank für die Geburtshilfe an Martin, der Hinweis auf Wireshark wars einfach. :-)

und dir vielen Dank dafür, dass du nach der erfolgreichen Selbstlösung deines Problems die Lösung dem Forum mitteilst, so haben wir alle was davon!

MfG
Rouven

[Der Martin]

Hallo Bernhard,

So, Wireshark hat mich schon etwas schlauer gemacht:

freut mich, dass du nun doch weitergekommen bist. Zwar habe ich durch deine Ausführungen auch profitiert, aber sie haben für mich auch einige neue Fragen aufgeworfen.

Thunderbird meldet sich per EHLO und spricht wie in den Beispielen auf dieser Seite mit dem Server. Zuerst versucht er AUTH PLAIN, dann AUTH LOGIN.

Ich habe jahrelang primär Outlook Express verwendet und auch oft seine POP3- und SMTP-Logs konsultiert (und damit so das eine oder andere Problem aufdecken können). Dabei habe ich gesehen, dass OE sich beim SMTP-Server auch mit EHLO meldet und dann AUTH LOGIN versucht (natürlich nur, wenn man die Option "Outgoing Mail server server needs authentication" aktiviert hat).
Der Unterschied zu T-Bird, wenn ich mit deinen Ergebnissen vergleiche, ist also nur, dass letzterer als erstes AUTH PLAIN versucht und dabei schon abgewiesen wird.

Der Server antwortet jedenfalls auf das EHLO mit einer "Response: 250-AUTH LOGIN PLAIN\r\n", was zumindest eines der zwei Verfahren (PLAIN oder LOGIN) ermöglichen sollte.

Sehe ich auch so; nicht einzusehen, warum er dann so gallig reagiert, wenn tatsächlich jemand mit AUTH PLAIN daherkommt.

Preisfrage: Warum funktioniert das mit Outlook Express? =>Weil OE auf ESMTP verzichtet und sich beim Server am Anfang einfach mit HELO statt EHLO meldet.

Genau das widerspricht meinen Erfahrungen bzw. meinen OE-Logs. Denn das ursprüngliche SMTP-Protokoll sieht überhaupt keine Authentifizierung vor, die Begrüßung mit EHLO anstatt HELO ist eigentlich der Schlüssel, der den Server erkennen lässt, dass da jemand ESMTP mit der Möglichkeit der Authentifizierung mit ihm sprechen will.

Wie gesagt: Schön, dass du nun eine funktionierende Konfiguration gefunden hast. Wirklich schlüssig ist die Lösung IMHO nicht. Und ich bin immer noch überzeugt, dass das Verhalten des SMTP-Server hier einfach nicht korrekt ist.

Um welchen Provider ging's noch gleich? ;-)

So long,
 Martin

[Bernhard]

Hi!

Preisfrage: Warum funktioniert das mit Outlook Express? =>Weil OE auf ESMTP verzichtet und sich beim Server am Anfang einfach mit HELO statt EHLO meldet.

Genau das widerspricht meinen Erfahrungen bzw. meinen OE-Logs.

Ich hab eine relative alte MSOE-Version (6.irgendwas; halt den Stand, den man mit W2K SP4 und diversen Hotfixes bekommt). Vielleicht liegts daran.

Wie gesagt: Schön, dass du nun eine funktionierende Konfiguration gefunden hast. Wirklich schlüssig ist die Lösung IMHO nicht. Und ich bin immer noch überzeugt, dass das Verhalten des SMTP-Server hier einfach nicht korrekt ist.

"Schlüssig" ist ziemlich wenig an der ganzen Sache. Solange HELO keine gravierenden Nachteile gegenüber EHLO hat, kann ich aber mit der Lösung leben. Zumindest unsicherer sollte HELO nicht sein; weniger als Passwörter unverschlüsselt übertragen geht meiner Einschätzung nach nicht. ;-)

Dass die Schuld bei der ganzen Sache beim Server liegt, sehe ich aber ganz wie du.

Gruß
Bernhard

[Der Martin]

EHLO,

Preisfrage: Warum funktioniert das mit Outlook Express? =>Weil OE auf ESMTP verzichtet und sich beim Server am Anfang einfach mit HELO statt EHLO meldet.
Genau das widerspricht meinen Erfahrungen bzw. meinen OE-Logs.
Ich hab eine relative alte MSOE-Version (6.irgendwas; halt den Stand, den man mit W2K SP4 und diversen Hotfixes bekommt).

okay, ich habe hier eine 5.5-irgendwas (aber schon über 2 Jahre nicht mehr benutzt).

Vielleicht liegts daran.

Ich hätte nicht gedacht, dass die sich hier unterschiedlich verhalten. Aber wer weiß, irgendwo muss ja die Erklärung liegen.

Schönes Wochenende,
 Martin