Störungen bei gmail und anderen Diensten?
Servus Kollegen.
Mir scheint, seit gestern Nachmittag ist eine größere Störung im Gange.
Kann jemand bestätigen, dass Mails, welche von GMail gesendet werden, bei Euch nicht ankommen?
Gestern Nachmittag kam beim firmeneigenen Mailserver und auch bei GMX nichts an, was von gmail oder GMX versendet wurde.
Die Mails wurden bis heute nicht zugestellt und der Versender hat auch keine non-delivery reports bekommen.
Gestern Abend zum Test von GMX erneut an die Firma gesendet - das kam an. GMail kommt weiterhin nicht in der Firma an, während GMail-> GMX geht.
Diverse andere Mailserver können weiterhin mit unserer Firma kommunizieren.
Was mich nervös macht, ist das Ausbleiben von ND reports. Ohne diese fällt das Problem ja kaum auf.
Gibt es Leidensgenossen?
Mir scheint, seit gestern Nachmittag ist eine größere Störung im Gange.
Kann jemand bestätigen, dass Mails, welche von GMail gesendet werden, bei Euch nicht ankommen?
Gestern Nachmittag kam beim firmeneigenen Mailserver und auch bei GMX nichts an, was von gmail oder GMX versendet wurde.
Die Mails wurden bis heute nicht zugestellt und der Versender hat auch keine non-delivery reports bekommen.
Gestern Abend zum Test von GMX erneut an die Firma gesendet - das kam an. GMail kommt weiterhin nicht in der Firma an, während GMail-> GMX geht.
Diverse andere Mailserver können weiterhin mit unserer Firma kommunizieren.
Was mich nervös macht, ist das Ausbleiben von ND reports. Ohne diese fällt das Problem ja kaum auf.
Gibt es Leidensgenossen?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1235451994
Url: https://administrator.de/contentid/1235451994
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
16 Kommentare
Neuester Kommentar
Zitat von @Looser27:
Moin,
gerade getestet. GMail auf unsere Domain und auf GMX geht problemlos. Sowohl als Initialmail, als auch als Antwort auf eine Mail.
Vielleicht auf ner Blacklist gelandet?
Gruß
Looser
Moin,
gerade getestet. GMail auf unsere Domain und auf GMX geht problemlos. Sowohl als Initialmail, als auch als Antwort auf eine Mail.
Vielleicht auf ner Blacklist gelandet?
Gruß
Looser
Moin,
Läuft hier auch.
Getestet am DTAG-Anschluss mit einer 217.x.y.z IP
Welchen ISP habt ihr? Vielleicht hat der gerade ein Routing-Problem!?
Und an der Firewall kommt auch nichts vorbei/ bleibt hängen?
Gruß
em-pie
Moin,
Wäre ja nicht das erste mal, dass die großen Player eine Stufe des Sicherheitsniveaus anheben und es an anderen Stellen knallt.
Ich Tippe mal, dass bei euch ein Postfix rennt!?
Und ich tippe, dass die NDR nicht vom Mail-Server sondern von einer vorgeschalteten Mail-Security stammt. Eine UTM? Ein Postfix?
Bei der UTM (oder ähnlichen Systemen): Hat die vielleicht ein AutoUpdate bekommen (wer auch immer soetwas aktiviert -.-)
Eine scheinbar exakte Fehlermeldung findet sich hier:
https://github.com/postmanlabs/postman-app-support/issues/8612
Hier liest es sich nach fehlenden Zertifikaten oder zumindest mit Problemen mit diesen:
https://community.letsencrypt.org/t/cant-handshake-when-doing-post-reque ...
Ist euer Zertifikat noch gültig?
Edit zur Zertifikatstheorie: was dem Widerspricht, ist die Tatsache, dass scheinbar(?) nur Google da herumzicken täte
ohne dass an unseren Systemen etwas geändert wurde?
Vielleicht hat Google ja etwas an den Cypher-Typen/ Arten/ Was-Auch-Immer geändert!?Wäre ja nicht das erste mal, dass die großen Player eine Stufe des Sicherheitsniveaus anheben und es an anderen Stellen knallt.
Hat jemand eine Idee, wie es dazu kommen kann
s.o.Ich Tippe mal, dass bei euch ein Postfix rennt!?
Und ich tippe, dass die NDR nicht vom Mail-Server sondern von einer vorgeschalteten Mail-Security stammt. Eine UTM? Ein Postfix?
Bei der UTM (oder ähnlichen Systemen): Hat die vielleicht ein AutoUpdate bekommen (wer auch immer soetwas aktiviert -.-)
Eine scheinbar exakte Fehlermeldung findet sich hier:
https://github.com/postmanlabs/postman-app-support/issues/8612
Hier liest es sich nach fehlenden Zertifikaten oder zumindest mit Problemen mit diesen:
https://community.letsencrypt.org/t/cant-handshake-when-doing-post-reque ...
Ist euer Zertifikat noch gültig?
Edit zur Zertifikatstheorie: was dem Widerspricht, ist die Tatsache, dass scheinbar(?) nur Google da herumzicken täte
Zitat von @DerWoWusste:
Nach 27 Stunden bekommt mein GMail-Konto endlich einen NDR:
Nach 27 Stunden bekommt mein GMail-Konto endlich einen NDR:
TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71): 4537485761992:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:third_party/openssl/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40 ;4537485761992:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:third_party/openssl/boringssl/src/ssl/handshake.cc:642:
Das ist nun gar nicht mein Gebiet - Mailserveradmin ist zudem krank. Hat jemand eine Idee, wie es dazu kommen kann, ohne dass an unseren Systemen etwas geändert wurde?Zertifikate abgelaufen?
Soweit mir bekannt, hat Google in der letzten Zeit nichts an den Voraussetzungen im Bereich Cipher/TLS geändert.
Mal mit openssl den E-Mail Server getestet?
Zitat von @DerWoWusste:
Hier schreibst du ja:ich tippe, dass die NDR nicht vom Mail-Server sondern von einer vorgeschalteten Mail-Security stammt.
Die Meldung kommt nicht von unserer Seite, sondern von Google.Nach 27 Stunden bekommt mein GMail-Konto endlich einen NDR:
Meine Antworte war unglücklich formuliert. Ich meinte "eure Seite scheint der Versursacher zu sein"Denn Google hat den Zustellversuch mit dem obigen Fehler abgebrochen, weil ihr nicht wolltet/ konntet/ lt. google durftet.
Da hat wohl einer das unsichere SSLv3 nicht abgeschaltet.
Zitat von @149062:
Da hat wohl einer das unsichere SSLv3 nicht abgeschaltet.
Da hat wohl einer das unsichere SSLv3 nicht abgeschaltet.
Nein, das ist die Fehlermeldung, die du bekommst, wenn die komplette Zertifikatsauslieferung nicht funktioniert, eine verschlüsselte Verbindung aber erwartet wird. Wenn also der Client explizit STARTTLS anbietet, dann aber kein Zertifikat ausliefern kann oder will.
Die OpenSSL-Bibliotheken sind ein bisschen krude benannt: TLSv1.0 ist auch bekannt unter dem Namen SSLv3.1. Das liegt daran, dass man bei der Einführung abwärtskompatibel sein musste zu Systemen, die z.B. nur SSLv3 oder kleiner unterstützten.
Da steht dann im Versionsfeld des Handshakes bei TLSv1.0 deshalb der Wert "301", für TLSv1.2 ist es "303" u.s.w.
Deshalb heißen die Bibliotheken bei OpenSSL auch alle SSLV3 - sie enthalten aber auch den Code für SSLv3.3
Nur so ist es für Client und Server weiterhin leicht möglich zu erkennen, ob die Version der Gegenstelle höher oder niedriger ist als das, was man erwartet.
Und selbst wenn man es am eigenen Server nicht ausgeschaltet hätte, so wäre es der Absender, der versucht, auf dieses Protokoll auszuhandeln
Zitat von @LordGurke:
Die OpenSSL-Bibliotheken sind ein bisschen krude benannt: TLSv1.0 ist auch bekannt unter dem Namen SSLv3.1. Das liegt daran, dass man bei der Einführung abwärtskompatibel sein musste zu Systemen, die z.B. nur SSLv3 oder kleiner unterstützten.
Die OpenSSL-Bibliotheken sind ein bisschen krude benannt: TLSv1.0 ist auch bekannt unter dem Namen SSLv3.1. Das liegt daran, dass man bei der Einführung abwärtskompatibel sein musste zu Systemen, die z.B. nur SSLv3 oder kleiner unterstützten.
Apropos OpenSSL
lks
War der Kommentar Hardware-Voraussetzungen für performante WindowsSever 2019 VM ein versehen oder hat da ein Forenbug zugeschlagen, das den Kommentar falsch einsortiert hat?
lks
Zitat von @DerWoWusste:
Wenn Du mich fragst, hat da ein Bug zugeschlagen, da ich den anderen thread mit Sicherheit nie offen hatte.
Wenn Du mich fragst, hat da ein Bug zugeschlagen, da ich den anderen thread mit Sicherheit nie offen hatte.
Das Gefühl habe ich auch. Das ist nämlich mir und jemand anderem hier im Forum auch schon passiert, allerdings war ich beidesmal in beiden Threads aktiv, in denen die Kommentare falsch gelaufen sind.
lks