• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] Thunderbird sendet nicht mehr (gmx)

S

scrampop

Newbie
Zustand: mein Thnuderbird unter opensuse 12.3 sendet seit ca. einer Woche keine Mails mehr über gmx.
Die Fehlerkonsole gibt folgendes aus:
------------------------
Ein Fehler ist während einer Verbindung mit mail.gmx.net:465 aufgetreten.
Der Schlüssel unterstützt den angeforderten Arbeitsschritt nicht.
(Fehlercode: sec_error_invalid_key)
------------------------
Nachdem freilich alle Einstellungen überprüft wurden, Thunderbird Verzeichnis gelöscht, Thunderbird neu installiert und neu eingerichtet wurde, bleibt alles beim Alten. Das senden über gmail Accounts funktioniert. Auch werden beide gmx Konten korrekt über imap abgerufen, nur eben das Senden klappt ums verrecken nicht.

Ich habe mein gmx Konto dann mit den selben Einstellungen für imap uns smtp unter Evolution eingerichtet und hier funktioniert alles tadellos.
Zusätzlich habe ich dann Thunderbird in einer VM unter Xp installiert und eingerichtet, da klappt alles.
Stundenlanges googeln zur Fehlermeldung brachten keinen Erfolg. Jetzt bin ich echt ratlos.
--------------------------------
hier meine smtp Konfig:
Server: mail.gmx.net
Port: 465
Benutzername: xxxx@gmx.de oder Wahlweise die gmx Knd. Nummer
Authentifizierung: Passwort, normal
Verbindungssicherheit SSL/TLS
---------------------------------
Wird das Passwort ungesichert übertragen, klappt es, aber das ist ja kein Zustand

Das gestrige Update von Thunderbird (17.0.7) hat leider auch nichts daran geändert.

Wäre schön, wenn jemand helfen könnte.
 
OP
S

scrampop

Newbie
ich habs mal probiert, gleiches Ergebnis
--------------------------------
Ein Fehler ist während einer Verbindung mit mail.gmx.net:25 aufgetreten.
Der Schlüssel unterstützt den angeforderten Arbeitsschritt nicht.
(Fehlercode: sec_error_invalid_key)
-------------------------------
 
S

spoensche

Moderator
Teammitglied
Dann wirst du wohl unverschlüsselt versenden müssen. Mir ist auch nicht bekannt, das GMX Verschlüsselung und Imap für das Freemail Produkt anbietet.
 
/dev/null

/dev/null

Moderator
Teammitglied
Hallo,

Nun, ob unser Grufti POP3 oder IMAP zum Empfangen bzw. Verwalten der Mails benutzt werden soll, spielt hier keine Rolle. Gesendet wird ja immer per SMTP ... .
Und es ist auch so, dass obwohl fast alle (deutschen) Provider in den AGB für ihre zahlungsunwilligen Kostnix-Kunden immer nur POP3 anbieten und das leistungsfähigere IMAP nur für die kostenpflichtigen Verträge. Und das ist auch verständlich so! Von "irgendwas" wollen die Provider ja leben. Und dazu gehören auch Areize zum Wechseln in kostenpflichtige Verträge.
Trotzdem funktioniert bei web.de & Co. in der Regel auch bei den kostenlosen Verträgen IMAP. Einfach probieren ... .

Das steht in der entsprechenden Übersicht bei http://www.patshaping.de zu GMX:
  • Posteingangsserver: POP3: pop.gmx.net (bei SSL Port 995), IMAP: imap.gmx.net (bei SSL Port 993)
  • Postausgangsserver: mail.gmx.net (SSL über Port 25, 587 oder 465) (Anm.: müsste heißen: bei SSL Port 465)
  • Benutzername: GMX-Kundennummer oder GMX-E-Mail-Adresse
  • Besonderheiten: Verwendet SMTP-Authentifizierung oder "POP3 vor SMTP", je nachdem, wie Sie Ihren Account eingestellt haben.
    SMTP steht auch über den alternativen Port 587 zur Verfügung.
    Sollte es beim Anmelden Probleme geben, sollten Sie in jedem Fall beide Möglichkeiten für den Benutzernamen ausprobieren.
    IMAP ist laut GMX nur in den Tarifen ProMail und TopMail verfügbar. Im Tarif FreeMail ist IMAP offiziell nicht verfügbar, aber es scheint bei vielen Konten trotzdem zu funktionieren (Stand: 10.11.2012).

Also ist die verwendete Einstellung "Verbindungssicherheit SSL/TLS" schon richtig. Ich verwende sie auch, nutze allerdings "nur" ein Konto bei gmx.com
Trotzdem empfehle ich bei Sendeproblemen immer, alle drei Möglichkeiten auszutesten.

Ich definiere die Fehlermeldung (Fehlercode: sec_error_invalid_key) so, dass hier ein Problem mit der SSL-Verschlüsselung oder konkret mit einem "falschen" Schlüssel auftritt.
- stimmt die Zeit des Rechners?
- ist das Herausgeberzertifikat vorhanden und gültig?
- ist vlt. das Zertifikat für mail.gmx.net gespeichert, und stimmt nicht (mehr)? => Löschen!
- auf der Webseite des Providers nach Informationen über deren Zertifikate gesucht? => evtl. nachinstallieren!
- auch mal mit dem Server mail.gmx.de getestet? (vlt. ist das Zertifikat auf mail.gmx.de ausgestellt?)
- hast du die aktuellen Bibliotheken "ca-certificates-mozilla", "mozilla-nss-certs" und "mozilla-nss" installiert (automatisch, wenn Installation aus akt. Repo)
Die integrierte Routine für die Zertifikatsprüfung "schlägt also an", eigentlich ein gutes Zeichen!

Sicherlich bekommst du das Problem mit einer Suche in dieser Richtung in den Griff.
Nur wozu der ganze Aufwand?
Dass du mit der Verschlüsselung der Verbindung zu den Servern im Endeffekt lediglich dein PW für das Mailkonto vor dem Mitsniffen schützt, und keinesfalls die Vertraulichkeit deiner Mails, hast du ja schon erkannt. Nur, welchen Sinn macht das noch? Nach der aktuellen Gesetzeslage müssen die Provider seit dem 01.07.2013 deine Passwörter den "dazu berechtigten Stellen" auf dem Silbertablett rüberreichen. So oft können wir diese gar nicht wechseln.
Wenn ich nicht gerade per unverschlüsseltem WLAN (Hotspots!) oder aus einem Firmen-, Uni- usw. Intranet sende, würde ich mir da gar keine Gedanken machen. Kleine Unbefugte (mitsniffende WLAN-Nutzer oder die es vielleicht doch gebenden "gelangweilten Admins") können selbstverständlich in der o.g. Umgebung deine PW mitlesen. (Dagegen gibt es VPN!) Aber nutzt du deinen eigenen DSL- (o.ä.) Zugang, dann kannst du diesen Abfluss vergessen. Und die "großen Unbefugten" lassen sich von der Verschlüsselung dieser Verbindung nicht beeindrucken (s. oben.)


MfG Peter
 
R

RalfonLinux2

Newbie
Wißt ihr eigentlich, dass ihr ein alleine bei google für diesen Fehler auftaucht ?
"web.de smtp sec_error_invalid_key"

@Peter
Schöne Erklärung, muss aber nicht ganz passen.
Die Kennwörter liegen doch bei web.de/gmx.de vor, pop3/imap/smtp müssen doch gegen die Passwortdatenbank des Anbieters vergleichen.
Somit haben sie die schon.
Selbst wenn du die Verbindung verschlüsselst, der gelangweilte Admin somit nicht mehr mitlesen kann, der gelangweilte web/gmx-Admin schaut einfach in die DB ;-)
Und liegen sie dort verschlüsselt vor, dann gibt der Admin doch den Schlüssel vor z.B. ROT13 mit XOR ;-)

Nun zum Problem
Durch das Umstellen auf plain-smtp, wird das Zertifikat nicht mehr vom Server gezogen.
Vergleichbar einem http und einem https
Im letzten Fall wird ein Zertifikat ausgetauscht und nur wenn du dem Aussteller vertraust, dann geht es Nahtlos weiter, ansonsten bekommst du die entsprechende Fehlermeldung.
Also z.B. "Dem Aussteller wird nicht vertraut, ..." oder auch "Das Zertifikat gilt nur für foo.bar, nicht für http://www.foo.bar"

Ich habe hier (12.2) nämlich das selbe Problem seit ich ein Update von Thunderbird gemacht habe
Bis zum 19.7.2013 klappte es definitiv mit der Version MozillaThunderbird-17.0.2-49.27.2.x86_64(@System)
seit meinem Update (25.7.2013) auf MozillaThunderbird-17.0.7-49.47.1.x86_64.rpm ist es damit aber vorbei.

Ob das Update und ein möglicher Key-Change bei web.de zufällig zusammen gefallen sind weiß ich nicht.
Ein Test besagt:
Server certificate
subject=/C=DE/ST=Baden-Wuerttemberg/L=Karlsruhe/O=1&1 Mail & Media GmbH/OU=WEB.DE/CN=smtp.web.de
issuer=/C=US/O=Thawte, Inc./CN=Thawte SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3987 bytes and written 549 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 38A8715ED5F4F94E11939C895F76EAFF048F118E01788E0FF619B2EEFF4ED36C
Session-ID-ctx:
Master-Key: DBEFFA19CD7FB0EF4737457B07224D0399660590B0B863E3919F10486EAD8D1D32DDD51A31D6D3659EBF9C87EE3EF07B
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1374846570
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
250 STARTTLS
421 web.de Service closing transmission channel - command timeout
closed
Zum Vergrößern anklicken....

Also im Zertifikatsspeicher des Thunderbirds nachgesehen und dort ist ein Thawte Root CA und auch ein SSL CA

Das SSL CA exportiert und ein neuer Test ergibt:
Server certificate
subject=/C=DE/ST=Baden-Wuerttemberg/L=Karlsruhe/O=1&1 Mail & Media GmbH/OU=WEB.DE/CN=smtp.web.de
issuer=/C=US/O=Thawte, Inc./CN=Thawte SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3987 bytes and written 549 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 140F8F03136134B4B6CF8CC218E1A9A9AB35E9D4752EBAEC932F5A82C62278B1
Session-ID-ctx:
Master-Key: 917C2DD291CF474FF25496D3BF41E295F002D0769AA35807045B7F926C0B84B07D5ABEDB75A0D37328F81FBC964BF8A4
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1374848490
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 STARTTLS
Zum Vergrößern anklicken....
Also scheint mit den Zertifikaten von web/gmx alles okay zu sein.
Sein Test mit Evolution hat dies auch bestätigt, dort hat es ja geklappt

Im Store von Thunderbird liegen auch die entsprechenden Zertifikate, daher habe ich sie ja exportiert.
Scheinbar weiß der Thunderbird mehr über die Zertifikate als openssl.

Möglicherweise gibt es durch das Update ein Problem mit der cert8.db ? Dort speichert der Thunderbird seine Zertifikate.

Mein nächster Schritt wird wohl ein Downgrade auf 17.0.2 sein, mal schauen ob es dann wieder klappt.
In der 17.0.3 gab es eine Änderung "MFSA 2013-27 Phishing on HTTPS connection through malicious proxy"
Möglicherweise ist das der Grund, ich sitze hier hinter einem Proxy.
Zu den Release-Dates bei 12.2 / 12.3
17.0.2 war am 11.1.2013 / k.A.
17.0.3 war am 22.2.2013 / 15.3.2013
17.0.4 war am 15.3.2013 / 15.3.2013
17.0.5 war am 5.4.2013 / 5.4.2013
17.0.6 war am 27.5.2013 / 27.5.2013
17.0.7 war am 25.7.2013 / 4.7.2013
Wenn es bei scrampop ein 12.3 x64 hat und bis zum 7.7.2013 gelaufen haben soll, sollte die 17.0.6 die letzte funktionierende Version sein ?
Oder er updated unregelmäßig und bei ihm war auch noch die 17.0.2 am werkeln.
Hilfreich wäre ein
Code: 
xzcat /var/log/zypper.log-*.xz | grep -i "uninstall.*Thunderbird"

Ralf
 
T

Tantris

Member
Hi,

hast Du Dein Problem lösen können? Ich stehe vor dem selben Problem; habe ~/.thunderbird mal weggesichert und ganz frisch das Konto eingerichtet -> SMTP mit mail.gmx.net:465 / SSL / einfaches Passwort geht nicht mit der entsprechenden Security-Meldung in der Fehlerkonsole. Ohne SSL auf Port 25 kein Problem, unter KMail mit SSL auf Port 465 kein Problem. Habe sogar unter Einstellungen > Zertifikate > Zertifikate > Server > Ausnahme hinzufügen ein "mail.gmx.net:465" eingetragen, Zertifikat heruntergeladen und eine Ausnahme hinzugefügt - vollkommen egal.

Dann Thunderbird Beta ausgetestet (version "18.99") - gleicher Fehler.
 
L

luwa

Member
Moin
und sorry,

ich benutze Thunderbird portable 17.07 und versende meine Mails via Postfix und meinen Provider als relayhost.
Gemessen an dem was ich hier lese sieht es für mich nach einem Problem mit dem Thunderbird bzw. einem Problem mit den richtigen Ports aus.

Wie schon angedacht würde ich es mit einem Downgrade des Thunderbird versuchen.
Das Ergebnis würde mich interessieren.
Jetzt kommt der "luwa" mit der Verschwörung. MS lädt im Hintergrund irgendwelche CA's nach / damit die NSA mitlesen kann. Mozilla und damit Thunderbird scheint, nach "heise", davor gefeit.
Wenn es nach einem Downgrade und sowieso unter Linux nicht geht bleibt die Frage ob gmx abgelaufene Zertifikate im Umlauf hat. Zumindest verweigert MS dann die Zusammenarbeit.

Tschuldigung, nur Ideen. Bitte drüber nachdenken aber nicht über die Verschwörung.

wie schon im Eingang SORRY
nach dem lesen der Beiträge sieht es für mich nach einem Thunderbird Problem bzw Port-Problem aus.

Gruß
luwa

[Edit] ich hätte den Browser schließen sollen ohne den Beitrag abzusenden. Wäre gern hilfreicher gewesen.
 
T

Tantris

Member
Hi,

es ist kein Port-Problem - es ist imho ein Zertifikats- oder Thunderbird-auf-Linux-Problem.

Ich hatte die Einstellungen jahrelang unverändert, update dann TB und dann geht es plötzlich nicht mehr. Ich schmeiße die alte Konfiguration weg und setze komplet neu SMTP per SSL, mail.gmx.net:465 mit Login. Das lustige: Er schmeißt den Fehler, bevor er überhaupt nach einem Passwort fragt, d.h. er lehnt die Kommunikation mit dem Server ab (aus Zertifikatsgründen). Der Server stimmt, der Port stimmt, auf einer Windows-Schüssel funktionieren exakt die gleichen Einstellungen, unter KMail auch. Definitiv kein Portproblem, das können wir ausschließen...

Viele Grüße,
tantris
 
A

an9dn8

Newbie
Hallo,

ich habe das gleiche Problem hier, allerdings mit Seamonkey 2.19 und etwas merkwürdiger:

Auf einem Rechner mit opensuse 12.2 und Seamonkey 2.19 kann ich Mails über GMX und WEB.DE versenden mit den gleichen Einstellungen wie oben beschrieben, also:

Code: 
Server: mail.gmx.net (smtp.web.de)
  Port: 465 (587)
  Authentifizierung: Passwort, normal
  Verbindungssicherheit SSL/TLS (STARTTLS)

Aber auf einem anderen Rechner mit opensuse 12.3 und Seamonkey 2.19 erhalte ich für WEB.DE und GMX die gleiche Fehlermeldung wie oben:

Code: 
Ein Fehler ist während einer Verbindung mit mail.gmx.net:465 aufgetreten.
  Der Schlüssel unterstützt den angeforderten Arbeitsschritt nicht.
  (Fehlercode: sec_error_invalid_key)
Im Gegensatz dazu ist der Versand über KMail mit SSL bei diesem Rechner kein Problem.

Für Seamonkey scheint es aber einen Workaround zu geben:
Wenn ich unter "Bearbeiten"->"Einstellungen"->"Datenschutz & Sicherheit"->"SSL" den Haken bei "TLS 1.0 aktivieren" wegnehme (bei "SSL 3.0 aktivieren" lass ich ihn drin), dann funktioniert der Mailversand über beide Mailserver.

D.h. die Kombination aus auf Mozilla-Code basierenden Mail-Clients, TLS 1.0, openSuSE 12.3 und WEB.DE/GMX klemmt irgendwo. :???:

CU
 
OP
S

scrampop

Newbie
im Moment würde ich sagen, das sieht danach aus, das Thema auszusitzen… leider.
Ich habe es jedenfalls noch nicht gefixt bekommen, derzeit beschränke ich mich darauf nach einem Update von Thunderbird, zu probieren, ob es wieder funktioniert.

Danke dennoch an Alle, die sich Zeit genommen haben…
 
R

RalfonLinux2

Newbie
Sorry dass ich mich nicht mehr so schnell gemeldet habe, aber war einige Tage unterwegs.

Mein Versuch mit dem Downgrade auf 17.0.2 brachte auch nichts.
Ich habe mich dann mal etwas mit den Innereien beschäftigt und spasseshalber die 17.0.7 mit der 17.0.7 aus den Win-PortableApps verglichen.

Dafür werden auf "beiden" Systemen folgende Befehle ausgeführt.
Code: 
export NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,nsHostResolver:5,IMAP:5,POP3:5,SMTP:5
export NSPR_LOG_FILE=/tmp/thunderbirdlog_smtp1.txt
thunderbird -ProfileManager
Für windows entsprechend set und nicht export

Dabei bin ich auf folgenden Unterschied gestossen.
linux ohne Proxy schrieb:
2013-08-01 06:49:13.466496 UTC - 468297536[7fdb1953c150]: SMTP Connecting to: smtp.web.de
2013-08-01 06:49:13.625353 UTC - 468297536[7fdb1953c150]: SMTP entering state: 0
2013-08-01 06:49:13.625365 UTC - 468297536[7fdb1953c150]: SMTP Response: 220 web.de (mrweb002) Nemesis ESMTP Service ready
2013-08-01 06:49:13.625379 UTC - 468297536[7fdb1953c150]: SMTP entering state: 14
2013-08-01 06:49:13.625392 UTC - 468297536[7fdb1953c150]: SMTP Send: EHLO PCNAME.DOMAIN
2013-08-01 06:49:13.690274 UTC - 468297536[7fdb1953c150]: SMTP entering state: 0
2013-08-01 06:49:13.690298 UTC - 468297536[7fdb1953c150]: SMTP Response: 250-web.de Hello PCNAME.DOMAIN [87.181.xx.yy]
2013-08-01 06:49:13.690368 UTC - 468297536[7fdb1953c150]: SMTP entering state: 0
2013-08-01 06:49:13.690411 UTC - 468297536[7fdb1953c150]: SMTP Response: 250-SIZE 69920427
2013-08-01 06:49:13.690431 UTC - 468297536[7fdb1953c150]: SMTP entering state: 0
2013-08-01 06:49:13.690443 UTC - 468297536[7fdb1953c150]: SMTP Response: 250-AUTH LOGIN PLAIN
2013-08-01 06:49:13.690457 UTC - 468297536[7fdb1953c150]: SMTP entering state: 0
2013-08-01 06:49:13.690472 UTC - 468297536[7fdb1953c150]: SMTP Response: 250 STARTTLS
2013-08-01 06:49:13.690478 UTC - 468297536[7fdb1953c150]: SMTP entering state: 4
2013-08-01 06:49:13.690500 UTC - 468297536[7fdb1953c150]: SMTP entering state: 21
2013-08-01 06:49:13.690508 UTC - 468297536[7fdb1953c150]: SMTP Send: STARTTLS
2013-08-01 06:49:13.744287 UTC - 468297536[7fdb1953c150]: SMTP entering state: 0
2013-08-01 06:49:13.744305 UTC - 468297536[7fdb1953c150]: SMTP Response: 220 OK
2013-08-01 06:49:13.744337 UTC - 468297536[7fdb1953c150]: SMTP entering state: 19
2013-08-01 06:49:13.744361 UTC - 468297536[7fdb1953c150]: SMTP entering state: 14
2013-08-01 06:49:13.744375 UTC - 468297536[7fdb1953c150]: SMTP Send: EHLO PCNAME.DOMAIN
Zum Vergrößern anklicken....

Windows via VMware ohne Proxy schrieb:
2013-08-01 07:23:04.412000 UTC - 0[200f140]: SMTP Connecting to: smtp.web.de
2013-08-01 07:23:04.568000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.568000 UTC - 0[200f140]: SMTP Response: 220 web.de (mrweb103) Nemesis ESMTP Service ready
2013-08-01 07:23:04.568000 UTC - 0[200f140]: SMTP entering state: 14
2013-08-01 07:23:04.568000 UTC - 0[200f140]: SMTP Send: EHLO [172.16.117.128]
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP Response: 250-web.de Hello [172.16.117.128] [87.181.xx.yy]
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP Response: 250-SIZE 69920427
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP Response: 250-AUTH LOGIN PLAIN
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP Response: 250 STARTTLS
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP entering state: 4
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP entering state: 21
2013-08-01 07:23:04.677000 UTC - 0[200f140]: SMTP Send: STARTTLS
2013-08-01 07:23:04.724000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.724000 UTC - 0[200f140]: SMTP Response: 220 OK
2013-08-01 07:23:04.724000 UTC - 0[200f140]: SMTP entering state: 19
2013-08-01 07:23:04.724000 UTC - 0[200f140]: SMTP entering state: 14
2013-08-01 07:23:04.724000 UTC - 0[200f140]: SMTP Send: EHLO [172.16.117.128]
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP Response: 250-web.de Hello [172.16.117.128] [87.181.xx.yy]
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP Response: 250-SIZE 69920427
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP Response: 250 AUTH LOGIN PLAIN
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP entering state: 4
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP entering state: 21
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP auth: server caps 0x10310, pref 0x300, failed 0x0, avail caps 0x300
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP entering state: 16
2013-08-01 07:23:04.974000 UTC - 0[200f140]: SMTP AuthLoginStep1() for foo@0�vo�vo
2013-08-01 07:23:05.083000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:05.083000 UTC - 0[200f140]: SMTP Response: 235 Authentication succeeded
2013-08-01 07:23:05.083000 UTC - 0[200f140]: SMTP entering state: 18
2013-08-01 07:23:05.083000 UTC - 0[200f140]: SMTP Login response, code 235
2013-08-01 07:23:05.083000 UTC - 0[200f140]: SMTP entering state: 3
2013-08-01 07:23:05.083000 UTC - 0[200f140]: SMTP Send: MAIL FROM:<foo@web.de> SIZE=557
2013-08-01 07:23:05.162000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:05.162000 UTC - 0[200f140]: SMTP Response: 250 Requested mail action okay, completed
2013-08-01 07:23:05.162000 UTC - 0[200f140]: SMTP entering state: 5
2013-08-01 07:23:05.162000 UTC - 0[200f140]: SMTP Send: RCPT TO:<bar@web.de>
2013-08-01 07:23:05.224000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:05.224000 UTC - 0[200f140]: SMTP Response: 250 OK
2013-08-01 07:23:05.224000 UTC - 0[200f140]: SMTP entering state: 6
2013-08-01 07:23:05.224000 UTC - 0[200f140]: SMTP Send: DATA
2013-08-01 07:23:05.271000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:05.271000 UTC - 0[200f140]: SMTP Response: 354 Start mail input; end with <CRLF>.<CRLF>
2013-08-01 07:23:05.271000 UTC - 0[200f140]: SMTP entering state: 7
2013-08-01 07:23:05.271000 UTC - 0[200f140]: SMTP entering state: 8
2013-08-01 07:23:05.287000 UTC - 0[200f140]: SMTP Send: .
2013-08-01 07:23:05.365000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:05.365000 UTC - 0[200f140]: SMTP Response: 250 Requested mail action okay, completed: id=0MGA7n-1UsT9i0m63-00FCci
2013-08-01 07:23:05.365000 UTC - 0[200f140]: SMTP entering state: 9
2013-08-01 07:23:05.365000 UTC - 0[200f140]: SMTP Send: QUIT
2013-08-01 07:23:05.365000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:05.427000 UTC - 0[200f140]: SMTP entering state: 0
2013-08-01 07:23:05.427000 UTC - 0[200f140]: SMTP Response: 221 web.de Service closing transmission channel
2013-08-01 07:23:05.427000 UTC - 0[200f140]: SMTP entering state: 10
2013-08-01 07:23:05.427000 UTC - 0[200f140]: SMTP entering state: 12
2013-08-01 07:23:05.427000 UTC - 0[200f140]: SMTP connection error quitting 804b0002, ignoring
Zum Vergrößern anklicken....

Man sieht also, beide Clients senden ein
SMTP Send: STARTTLS und gehen in den Status 0
Der Server sagt SMTP Response: 220 OK und der Client macht sich bereit mit Status 19 und 14
Der Client sendet eine neue Begrüssung SMTP Send: EHLO PCNAME.DOMAIN bzw. SMTP Send: EHLO [172.16.117.128]
und dann unterscheiden sie sich.
Der Linuxclient geht nicht mehr in den Status 0, der Windowsclient aber doch.
Der Server sendet dann (zumindest bei Windowsclient) ein SMTP Response: 250-web.de Hello [172.16.117.128] [87.181.xx.yy], welches bei Linuxclient entweder nicht kommt oder nicht beachtet wird.

Das Log schreibt noch einige weitere Einträge, welche nicht zum SMTP gehören.
Beide Clients holen sich bei Thwate das Zertifikat ab.
2013-08-01 07:23:04.818000 UTC - 0[200f140]: http request [
: POST / HTTP/1.1
Host: ocsp.thawte.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 115
Content-Type: application/ocsp-request
]
Zum Vergrößern anklicken....
und scheinen es auch zu bekommen.
Dann wird es reichlich kryptisch, und da muss ich mich noch durch graben.

Sonderbar ist, dass ich trotzdem den Entwurf der Mail speichern kann.
Also ist es kein Berechtigungs- oder Portproblem.

Ralf
 
OP
S

scrampop

Newbie
Heute gab es für opensuse 12.3 ein paar Sicherheitsupdates, darunter auch eines Package, welches Mozilla Thunderbird und Firefox betraf.
Folgender Text wurde dazu ausgegeben:
--------------------------------
This package contains the integrated CA root certificates from the Mozilla project.
--------------------------------

ich habe danach sogleich probiert, ob sich das Problem damit behoben hat.
Und ja, verschlüsselte Anmeldung via STARTTLS bei SMTP ist nun wieder ohne Probleme möglich.

so denn…
 
R

RalfonLinux2

Newbie
Deine Meldung gelöst war etwas voreilig ;-)
Es liegt scheinbar nicht an den CA's (mozilla-nss-certs)

Ein Update der Pakete
  • MozillaThunderbird 17.0.7-49.47.1|x86_64
  • MozillaThunderbird-translations-common 17.0.7-49.47.1|x86_64
  • mozilla-nss-certs 3.15.1-2.23.1|x86_64
  • mozilla-nss 3.15.1-2.23.1|x86_64
  • libgcrypt11 1.5.3-9.5.1|x86_64
  • mozilla-nspr|4.10-1.16.1|x86_64
brachte keinen Erfolg.

Erst als ich
  • libfreebl3 3.15.1-2.23.1|x86_64
  • libsoftokn3 3.15.1-2.23.1|x86_64
upgedated habe, klappte es wieder.

Ob es die Fehlermeldung
Failed to load native module at path '/usr/lib64/thunderbird/components/libenigmime.so': (80004005) /usr/lib64/thunderbird/components/libenigmime.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
Zum Vergrößern anklicken....
vorher schon gab weiß ich nicht, aber das ist eine andere Baustelle.

HtH
Ralf
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben