Sicherheitszertifikat - GMX-Sammeldienst
-
Dass GMX allerdings Nutzer so einfach abspeist und nicht versucht das technisch zu klären, ist nicht professionell.
Was will man von einer großen Firma erwarten? Premium-Kunden werden sicherlich anders behandelt, als Gratisnutzer von GMX.
Mal ne andere Frage, ihr könnt aber über GMX Webmail oder GMX SMTP-Server aus eurem Mailclient selbst Mails an euer vivaldi.net-Konto senden? Oder schlägt das dann auch fehl?
Eine Mail von GMX → @vivaldi.net funktioniert bei mir.
-
Auch ich kann bestätigen, dass der Mailversand über GMX an meine Vivaldi-Adresse unverändert funktioniert.
Weiterhin habe ich gerade nochmals mit GMX telefoniert. Da ich als technischer bzw. IT-Laie leider Euere interessante Diskussion mangels Kenntnis nicht verstehe, habe ich den dortigen Mitarbeiter mit dem Begriff "Let’s Encrypt (LE)-Zertifikat" konfrontiert. Er konnte mir allerdings dazu gar keine Antwort geben.
-
Also ich kann von meinem Server mit einem alten Linux per fetchmail, das ist ein Sammeldienstprogramm, sehr wohl von vivaldnet Mails holen ohne Probleme über SSL und Port 995.
Auf meinem Linux Debian 10 wird brav von fetchmail abgeholt, an meinen lokalen Postfix weiter geleitet und das Mail landet im Postdfach des Linux-Nutzers test.
Siehe hier (mist SSL und Zertifikatscheck):test@servana:~$ fetchmail --ssl --sslcertck -v fetchmail: 6.4.0.beta4 fragt pop3.vivaldi.net ab (Protokoll POP3) um Do 10 Feb 2022 12:28:14 CET: Abfrage gestartet Versuche, mit 31.209.137.15/995 zu verbinden...verbunden. fetchmail: Server-Zertifikat: fetchmail: Herausgeber-Organisation: Let's Encrypt fetchmail: Herausgeber-CommonName: R3 fetchmail: Subjekt-CommonName: imap.vivaldi.net fetchmail: Subject Alternative Name: imap.vivaldi.net fetchmail: Subject Alternative Name: mail.vivaldi.net fetchmail: Subject Alternative Name: pop3.vivaldi.net fetchmail: Subject Alternative Name: webmail.vivaldi.net fetchmail: pop3.vivaldi.net-Schlüssel-Fingerabdruck: CB:C7:53:C4:0E:6B:BD:18:44:02:BD:12:12:47:72:64 fetchmail: SSL/TLS: Protokoll TLSv1.3, Chiffre TLS_AES_256_GCM_SHA384, 256/256 geheime/verarbeitete bits fetchmail: POP3< +OK Dovecot ready. fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< CAPA fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< PIPELINING fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< USER fetchmail: POP3< SASL PLAIN LOGIN fetchmail: POP3< . fetchmail: POP3> USER doctorg fetchmail: POP3< +OK fetchmail: POP3> PASS * fetchmail: POP3< +OK Logged in. fetchmail: POP3> STAT fetchmail: POP3< +OK 1 4172 fetchmail: POP3> LAST fetchmail: POP3< -ERR Unknown command: LAST fetchmail: Unknown command: LAST fetchmail: POP3> UIDL fetchmail: POP3< +OK fetchmail: POP3< 1 000000026204e390 fetchmail: POP3< . 1 Nachricht für doctorg bei pop3.vivaldi.net (4172 Bytes). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 4172 fetchmail: POP3> TOP 1 99999999 fetchmail: POP3< +OK Nachricht [email protected]:1 von 1 wird gelesen (4172 Bytes) Versuche, mit ::1/25 zu verbinden...verbunden. fetchmail: SMTP< 220 servana ESMTP Postfix (Debian/GNU) fetchmail: SMTP> EHLO servana fetchmail: SMTP< 250-servana fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-SIZE 10240000 fetchmail: SMTP< 250-VRFY fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250-STARTTLS fetchmail: SMTP< 250-ENHANCEDSTATUSCODES fetchmail: SMTP< 250-8BITMIME fetchmail: SMTP< 250-DSN fetchmail: SMTP< 250-SMTPUTF8 fetchmail: SMTP< 250 CHUNKING fetchmail: SMTP> MAIL FROM:<[email protected]> BODY=8BITMIME SIZE=4172 fetchmail: SMTP< 250 2.1.0 Ok fetchmail: SMTP> RCPT TO:<test@localhost> fetchmail: SMTP< 250 2.1.5 Ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF> #******************************* fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 Ok: queued as 44DBC100D28 gelöscht fetchmail: POP3> DELE 1 fetchmail: POP3< +OK Marked to be deleted. fetchmail: POP3> QUIT fetchmail: POP3< +OK Logging out, messages deleted. fetchmail: SMTP> QUIT fetchmail: SMTP< 221 2.0.0 Bye fetchmail: 6.4.0.beta4 fragt ab pop3.vivaldi.net (Protokoll POP3) um Do 10 Feb 2022 12:28:15 CET: Abfrage beendet fetchmail: normale Beendigung, Status 0 Sie haben neue Post in /var/mail/test. test@servana:~$
Also was bitte bei GMX nicht laufen soll mit Abholungen von POP3, wenn es bei meinem alten Linux-Server geht, ich versteh’ es nicht.
Die werden wohl irgendwas selbstgestricktes haben udn das versagt dann ab und an. -
@stefanseifried man wird (nicht nur als als Laie) wahrscheinlich auch wenig Chancen haben jemanden ans Telefon zu bekommen, der auch nahe genug an der betroffenen Technik sitzt.
Beim Anlegen des Sammeldienstes scheint das erst mal richtig zu laufen: Falsches Passwort wird angemeckert, richtiges nicht.
Dieser Teil der Infrastruktur baut wohl also eine funktionierende POP3-Session auf.
Erst das tatsächliche Abholen schlägt dann fehl, würde daher sagen das passiert an anderer Stelle im GMX-Backend.Wo das Problem beim Abholen liegt kann von Besonderheiten bei System (altes RHEL) oder Runtime (schlecht gepflegtes Java) ausgelöst werden.
Das zu beurteilen ist aber nur möglich wenn man das als kompetente Person so wie @DoctorG direkt vom betroffenen System aus mit der eingesetzten Software prüfen kann.
Die als Endbenutzer angezeigte generische "hier ist was kaputt"-Meldung bringt da niemanden weiter. -
@doctorg So, ich werde jetzt noch mit Debian 8 und 9 testen, das ist schon älter, wenn da fetchmail läuft, liegt es nicht am Vivaldi-POP3-Mailserver.
/edit: fetchmail läuft auch auf auf dem Uralt-Linux Debian 8 und holt von Vivaldinet Mails ab ohne murren.
Selbst mit Uralt-TLS gehts:
Protocol : TLSv1
Cipher : AES128-SHA -
@doctorg abholen mit anderen Sammeldiensten geht auch bei mir überall ohne Probleme, nur eben via GMX nicht mehr.
-
@doctorg alle Systeme ab OpenSSL 1.1.x kann man sich vermutlich sparen, (unterstütztes) Debian ist somit Systemseitig raus.
Unrettbar: CentOS/RHEL 6 OpenSSL 1.0.1 (prüft soweit ich verstanden habe immer letztes Root aus Bundle)
Korrigiert: CentOS/RHEL 7 OpenSSL 1.0.2 (haben DST nach Ablauf rausgeworfen und prüft daher ISRG)Die Chain für
Let's Encrypt
ist aus (Android 6-)Gründen anspruchsvoll:
Wenn man nicht beim ISRG-Root abbricht und die Cert-Laufzeit (eines lokal verfügbarenDST X3
) prüft ist das Ergebnis ungültig.Selbst wenn das aus Sicht von OpenSSL auf dem entsprechenden System klar geht könnte ein (selbstgebauter) Java-Client (am besten noch mit angepasstem
TrustManager
) trotzdem locker drüber stolpern.
Oder man deinstalliert die Bundle-Updater und arbeitet bei .Net/Java mit Daten von 2017.
Oder… -
Ohne jetzt wieder mit einem unqualifizierten Beitrag zu stören.
Ich als Anwender frage mich nur...was hat sich bzw. bei GMX geändert, das nicht "lösbar" ist?
-
Der Sammeldienst aller von mir genutzten Mailkonten, auch der von Vivaldi funktionierte einwandfrei bis 01.02.22.
-
Die beiden weiteren Sammeldienste der @googlemail.com bzw. @ieasy.net (Vododafone/Unitymedia) sammeln ebenfalls unverändert und korrekt die Mails, auch am heutigen Tag.
-
-
@stefanseifried said in Sicherheitszertifikat - GMX-Sammeldienst:
Ich als Anwender frage mich nur...was hat sich bzw. bei GMX geändert, das nicht "lösbar" ist?
Das weiß nur GMX, diese Firma blockiert ja die Sammeldienste.
-
@stefanseifried am 01.02.2022 hat GMX (laut Deiner Aussage im Anfangspost, auf die Schnelle keine Quelle gefunden) angefangen die Zertifikatlaufzeit anderer Mailserver zu prüfen, an sich ja eine sinnvolle Maßnahme.
Meine Vermutung ist dass Teile der GMX-Infrastruktur mit dem seit 30.09.2021 abgelaufenen Zertifikat in der Kette für
Let's Encrypt
nicht richtig umgehen, was von GMX behoben werden kann und sollte.
Andere Mailserver verwenden andere Zertifikatsketten/-dienstleister und sind daher von diesem (verbreiteten) Sonderfall nicht betroffen.Beim anlegen/ändern der Sammeldienst-Einstellungen (näher am Frontend) war bei meinem Versuch die Verbindung erfolgreich (Passwortcheck konnte korrekt durchgeführt werden).
Es betrifft wohl also (nur) einen Teil der Infrastruktur (Server-to-Server-POP3-Verbindung zur Mail-Abholung im Backend) auf den man (hoffentlich) nur als GMX-Server-Admin Zugriff hat und beurteilen kann an welcher Stelle der Fehler behoben werden muss:- System Lib
- Root Certs
- Runtime
- eigener Client Code.
Seitens GMX kommt auf Anfrage über Kontaktformular mit konkreter Problembeschreibung lediglich zusammenhanglose Autoantwort mit einer Textversion der der Hilfeseite.
Da wird sich wohl nichts tun bis ein technisch versierter ProMail oder TopMail Kunde die spezielle Hotlinenummer anruft und so lange nervt bis er mit Personal verbunden wird welches das tatsächliche Problem überhaupt erfassen kann. -
@stefanseifried said in Sicherheitszertifikat - GMX-Sammeldienst:
Ohne jetzt wieder mit einem unqualifizierten Beitrag zu stören.
Es ist dein Thread und wirklich nicht unqualifiziert. Frage einfach nach bei uns, wenn du was nicht verstehst, das soll heir kein Fachthread werden – ich habe nur ein paar Abfragen zwecks der Zertifikate gemacht, um zu sehen was der Vivaldi-Mailserver so tut und ob er es richtig macht.
Ich als Anwender frage mich nur...was hat sich bzw. bei GMX geändert, das nicht "lösbar" ist?
Ich als IT-Person und Serveradmin auch.
- Der Sammeldienst aller von mir genutzten Mailkonten, auch der von Vivaldi funktionierte einwandfrei bis 01.02.22.
Das Vivaldi-Mailserverzertifikat wurde aber schon Jan 8 05:53:12 2022 GMT geändert. Wenn es da noch ging, hat GMX später was vermurkst.
- Die beiden weiteren Sammeldienste der @googlemail.com bzw. @ieasy.net (Vododafone/Unitymedia) sammeln ebenfalls unverändert und korrekt die Mails, auch am heutigen Tag.
Wenn der Sammeldienst von GMail und Vodafone von ...@vivaldinet holen kann, kanns ja nicht an Vivaldi Mail liegen, wenn die das technisch hinbekommen.
-
Also in der Tat hat GMX erst am Freitag, 04.02.22 um 11:55 einen "Sicherheitshinweis" über die Deaktivierung des Sammeldienstes von Vivaldi gesandt.
Am Donnerstag, 03.02.22 01:24 Uhr habe ich noch eine Mail über den Sammeldienst von Vivaldi-Mail erhalten!
-
Missverständnis:
Der Sammeldienst von GMX holt für mich unverändert die Mails von @googlemail.com bzw. @ieasynet! Also diese beiden Konten sind nicht von den "Einschränkungen" betroffen.
-
@stefanseifried Danke, ich frage bei Vivaldi nach ob die was änderten seit 2022-02-03 00:24 UTC.
-
@doctorg das GMX-Problem tritt (aktuell) laut anderer Posts ja auch bei anderen Servern mit
Let's Encrypt
auf.Würde eher vermuten die zum 1.2. angekündigte Umstellung bei GMX ist erst zum 3.2. erfolgt.
Oder so ein seltener Fall von:
"Wir haben die Config geändert"
"Oh, man sollte vielleicht mal auch den Dienst neu starten"
-
Ich habe Rücksprache mit einem Vivaldi-Serveradmin gehalten, die haben nichts geändert seit 8.1.2022.
Da vorher GMX-Sammelabruf noch lief und jetzt nicht mehr, liegt das Problem auf GMX-Seite (Occams Rasiermesser). -
@becm GMX, webde, ionos haben auch schon Mitte Januar 2022 was bei IMAP verbockt und Clients abgewürgt, die harmlos, und laut IMAP-Standard nicht verboten, nach Fähigkeiten gefragt haben.
-
@becm Sehe ich auch so, die wussten ganz genau das sie dann und dann was umstellen und genau zu dem Zeitpunkt lief es dann nicht mehr. Bei meinen Servern wurde sicher auch nichts geändert, das hätte mir der support dann sicher mitgeteilt, da dieser eher kompetent ist als GMX anscheinend.
Mal ne blöde Idee, aber vielleicht gehts GMX ums sparen von Datentransfer? Das sie einfach "unnötige" pop3 verbindungen rauswerfen aus ihrer Sicht?
-
Hatte heute einfach mal wieder versucht, den Sammeldienst zu aktivieren.
Nunmehr bin ich schon bei der eigentlichen Einrichtung mit Fehlermeldung zu Benutzername und Passwort gescheitert.
Zur Sicherheit, damit ich das richtige Vivaldi-Passwort nutze, wollte ich Euch gerne fragen, wo ich dies auslesen kann.
In meiner Einstellung sieht es wie folgt aus...
Oder muss ich ganz anders vorgehen?
Danke!
Schönen Tag
Stefan Seifried
-
@stefanseifried Das Passwort für Vivaldi Mailkonten dasselbe wie das für das Forenlogin.
Server:
smtp.vivaldi.net 465 SSL imap.vivaldi.net 993 SSL pop3.vivaldi.net 995 SSL