Willkommen im mailbox User Forum
FairEMail: 1 fehlerhafter A Record - Seit heute morgen keine Verbindung mehr möglich
in Arbeit
Hallo,
seit heute morgen um 09:39 Uhr ist leider mit FairEMail keine Verbindung zu mailbox.org mehr möglich:
"Validation of request to imap.mailbox.org IN A failed:
1 A record(s) are signed using an unkown key. This might be caused by the VPN that is being used."
Mein Gerät ist ein Google Pixel 9a mit dem neuesten GrapheneOS (Android 17) und FairEMail direkt vom Entwickler auf Github.
Folgendes habe ich vergeblich versucht:
- Das Gerät neugestartet
- Der App die zusätzliche "Nearby devices" Berechtigung unter Android 17 gegeben
- In der App "strict certificate checking" sowie "Harden SSL connections" + "Require TLS 1.3" testweise deaktiviert.
- Den Wireguard VPN-Tunnel zu meiner Fritz!Box deaktiviert
Alle anderen Apps funktionieren weiterhin einwandfrei und ich kann auf mailbox.org auch weiterhin im Browser sowie am Laptop mit Thunderbird zugreifen.
Ich habe das gleiche Problem 
Keine Verbindung
Echtzeitbenachrichtigungen funktionieren möglicherweise nicht
Hallo,
ich hatte das gleiche Problem, auch seit gestern Morgen. Bei mir hat die Neuinstallation von FairEmail geholfen. (Bei Pro-Version: vorher Einstellungen sichern, nachher wiederherstellen.) Ich hatte zuerst ein Downgrade der Version probiert, weil ich auch gerade ein Update installiert hatte. Es funktioniert aber nach Neuinstallation sowohl die 1.2324 als auch die 1.2325. Letztere habe ich sowohl aus dem F-Droid als auch dem Izzy-on-Droid Repo getestet; zu Versionen aus dem Google Play Store oder von Github kann ich nichts sagen.
Hoffe das hilft.
Hallo,
ich hatte das gleiche Problem, auch seit gestern Morgen. Bei mir hat die Neuinstallation von FairEmail geholfen. (Bei Pro-Version: vorher Einstellungen sichern, nachher wiederherstellen.) Ich hatte zuerst ein Downgrade der Version probiert, weil ich auch gerade ein Update installiert hatte. Es funktioniert aber nach Neuinstallation sowohl die 1.2324 als auch die 1.2325. Letztere habe ich sowohl aus dem F-Droid als auch dem Izzy-on-Droid Repo getestet; zu Versionen aus dem Google Play Store oder von Github kann ich nichts sagen.
Hoffe das hilft.
Hallo,
ich habe das selbe Problem. Ich habe meine E-Mail auf meiner eigenen Domain und hatte erst vermutet, dass sich dort etwas geändert hatte. Oder es ein DNS Problem ist. Ich habe aber verschiedene DNS Server ausprobiert und daran lag es dann nicht.
Das Problem besteht durchgehend bei "DANE" Überprüfung, die muss ich deaktivieren.
Wenn ich zusätzlich "DNSSEC" deaktivieren, geht es permanent. Es funktioniert aber auch, wenn ich DNSSEC temporär deaktiviere, synchronisiere und dann wieder aktiviere für eine Weile
Ich verwende normalerweise:
- Eigene Domain
- Fairemail
- Private DNS
Ich denke nicht, dass es an fairemail direkt liegt, da der Fehler bei mir nicht nach einem Update auftrat. Es fällt nur damit auf, da Fairemail DNSSEC und ggfs DANE checkt.
Hallo,
ich habe das selbe Problem. Ich habe meine E-Mail auf meiner eigenen Domain und hatte erst vermutet, dass sich dort etwas geändert hatte. Oder es ein DNS Problem ist. Ich habe aber verschiedene DNS Server ausprobiert und daran lag es dann nicht.
Das Problem besteht durchgehend bei "DANE" Überprüfung, die muss ich deaktivieren.
Wenn ich zusätzlich "DNSSEC" deaktivieren, geht es permanent. Es funktioniert aber auch, wenn ich DNSSEC temporär deaktiviere, synchronisiere und dann wieder aktiviere für eine Weile
Ich verwende normalerweise:
- Eigene Domain
- Fairemail
- Private DNS
Ich denke nicht, dass es an fairemail direkt liegt, da der Fehler bei mir nicht nach einem Update auftrat. Es fällt nur damit auf, da Fairemail DNSSEC und ggfs DANE checkt.
Untrusted DANE error DANE error DANE error is:
Validation of request to _993._tcp.imap.mailbox.org. IN TLSA failed:
3 TLSA record(s) are signed using an unknown key.
Validation of request to _993._tcp.imap.mailbox.org. IN TLSA failed:
3 TLSA record(s) are signed using an unknown key.
Zertifikat Fingerprint: 8284599483cb73137e68c9061256a9d5424c98c2/67757539e587ffbbfa1396e908a1b555c861aa08
Untrusted DANE error DANE error DANE error is:
Validation of request to _993._tcp.imap.mailbox.org. IN TLSA failed:
3 TLSA record(s) are signed using an unknown key.
Validation of request to _993._tcp.imap.mailbox.org. IN TLSA failed:
3 TLSA record(s) are signed using an unknown key.
Zertifikat Fingerprint: 8284599483cb73137e68c9061256a9d5424c98c2/67757539e587ffbbfa1396e908a1b555c861aa08
Hallo,
danke für Ihre Meldungen!
Wir haben das Thema zur Prüfung an unsere Administratoren weitergegeben und werden Sie informieren, sobald wir Genaueres wissen. Bis dahin bitten wir Sie noch um etwas Geduld.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Hallo,
danke für Ihre Meldungen!
Wir haben das Thema zur Prüfung an unsere Administratoren weitergegeben und werden Sie informieren, sobald wir Genaueres wissen. Bis dahin bitten wir Sie noch um etwas Geduld.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Hallo zusammen,
wir haben kürzlich Änderungen an unserer DNS-Zone vorgenommen, bei denen einige ältere RRSIG-Keys für die TLSA-Records (DANE) entfernt und durch einen neuen ersetzt wurden. Der alte Schlüssel wurde zunächst weiterhin angeboten, da die meisten Clients damit problemlos umgehen können.
Der FairMail-Client hat in einigen Fällen den alten, nicht mehr gültigen TLSA-Key verwendet, was zu einem Fehler führte. In unseren internen Tests war dieser Fehler nicht reproduzierbar, da der Client aus uns bisher unbekannten Gründen den aktuellen, gültigen Key gefunden hat.
Um weitere Probleme zu vermeiden, haben wir den herausalternden Key nun vollständig entfernt. Normalerweise durchsucht der Client die TLSA-Records, bis er einen gültigen Eintrag findet – das sollte jetzt wieder funktionieren.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Hallo zusammen,
wir haben kürzlich Änderungen an unserer DNS-Zone vorgenommen, bei denen einige ältere RRSIG-Keys für die TLSA-Records (DANE) entfernt und durch einen neuen ersetzt wurden. Der alte Schlüssel wurde zunächst weiterhin angeboten, da die meisten Clients damit problemlos umgehen können.
Der FairMail-Client hat in einigen Fällen den alten, nicht mehr gültigen TLSA-Key verwendet, was zu einem Fehler führte. In unseren internen Tests war dieser Fehler nicht reproduzierbar, da der Client aus uns bisher unbekannten Gründen den aktuellen, gültigen Key gefunden hat.
Um weitere Probleme zu vermeiden, haben wir den herausalternden Key nun vollständig entfernt. Normalerweise durchsucht der Client die TLSA-Records, bis er einen gültigen Eintrag findet – das sollte jetzt wieder funktionieren.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Ich habe es getestet und DNSSEC und DANE funktionieren wiesee bei IMAP. Spannenderweise habe ich sen Fehler aber weiterhin bei SMTP.
Ich habe es getestet und DNSSEC und DANE funktionieren wiesee bei IMAP. Spannenderweise habe ich sen Fehler aber weiterhin bei SMTP.
Hallo,
vielen Dank für den Hinweis – Sie haben vollkommen recht. smtp.mailbox.org war tatsächlich noch nicht angepasst. Das haben wir nun nachgeholt, sodass auch hier die aktuellen TLSA-Records verfügbar sind.
Die Änderungen sollten sich in Kürze propagieren. Falls Sie weiterhin Probleme feststellen, lassen Sie es uns bitte wissen.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Hallo,
vielen Dank für den Hinweis – Sie haben vollkommen recht. smtp.mailbox.org war tatsächlich noch nicht angepasst. Das haben wir nun nachgeholt, sodass auch hier die aktuellen TLSA-Records verfügbar sind.
Die Änderungen sollten sich in Kürze propagieren. Falls Sie weiterhin Probleme feststellen, lassen Sie es uns bitte wissen.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Vielen Dank für die schnelle Lösung des Problems und die Antwort. Ich werde im Laufe des Tages immer mal wieder den SMTP testen.
Vielen Dank für die schnelle Lösung des Problems und die Antwort. Ich werde im Laufe des Tages immer mal wieder den SMTP testen.
ich bekomme den fehler weiterhin bei imap wenn ich dnssec aktiviere und speichern drücke
ohne dnssec läuft es, aber mit dnssec aktiviert nicht, dann kommt der fehler
muss ich den alten key irgendwie löschen ?
ich bekomme den fehler weiterhin bei imap wenn ich dnssec aktiviere und speichern drücke
ohne dnssec läuft es, aber mit dnssec aktiviert nicht, dann kommt der fehler
muss ich den alten key irgendwie löschen ?
Habe den Fehler auch weiterhin seit gestern (IMAP). Habe noch nichts neu eingerichtet oä warte noch ein wenig ob es sich von alleine "löst"
Habe den Fehler auch weiterhin seit gestern (IMAP). Habe noch nichts neu eingerichtet oä warte noch ein wenig ob es sich von alleine "löst"
Vor einiger Zeit habe ich dem Support schon mal geschrieben, dass DNSSEC ... vermutlich weil es schon ziemlich lange existiert, und es zu ändern ziemlich aufwändig und kompliziert (und damit riskant) ist .... nicht auf dem aktuellsten Stand ist. Es funktioniert grundsätzlich, könnte aber optimiert werden. Daher könnte auch fairEmail bei DNS/DNSSEC-Änderungen aus dem Tritt kommen. Die NSEC3-Modernisierung ist gelungen, aber der Algorithmus-Rollover steckt in einem inkonsistenten Zwischenzustand fest, und das SHA-1-Problem besteht fort. Änderungen an DNS/DNSSEC sind immer ziemlich kritisch ... daher verstehe ich grundsätzlich, dass Änderungen nur sehr vorsichtig und konservativ vorgenommen werden.
Vor einiger Zeit habe ich dem Support schon mal geschrieben, dass DNSSEC ... vermutlich weil es schon ziemlich lange existiert, und es zu ändern ziemlich aufwändig und kompliziert (und damit riskant) ist .... nicht auf dem aktuellsten Stand ist. Es funktioniert grundsätzlich, könnte aber optimiert werden. Daher könnte auch fairEmail bei DNS/DNSSEC-Änderungen aus dem Tritt kommen. Die NSEC3-Modernisierung ist gelungen, aber der Algorithmus-Rollover steckt in einem inkonsistenten Zwischenzustand fest, und das SHA-1-Problem besteht fort. Änderungen an DNS/DNSSEC sind immer ziemlich kritisch ... daher verstehe ich grundsätzlich, dass Änderungen nur sehr vorsichtig und konservativ vorgenommen werden.
Ich bekomme den DNSSEC Fehler doch immer wieder, vielleicht braucht wa noch etwas Zeit, bis es überall hin durchgedrungen ist.
Ich bekomme den DNSSEC Fehler doch immer wieder, vielleicht braucht wa noch etwas Zeit, bis es überall hin durchgedrungen ist.
Wenn ich DNSSEC in den Einstellungen deaktiviere, speichere und es wieder aktiviere funktioniert es für ca. 24 Stunden, aber dann ist der Fehler wieder zurück. Hat jemand dieses Problem dauerhaft gelöst?
Wenn ich DNSSEC in den Einstellungen deaktiviere, speichere und es wieder aktiviere funktioniert es für ca. 24 Stunden, aber dann ist der Fehler wieder zurück. Hat jemand dieses Problem dauerhaft gelöst?
Leider besteht das Problem noch immer. Die letzten Tage waren vereinzelt mal Verbindungen möglich, sowohl zum Abrufen als auch zum Versenden. Seit gestern aber geht bei mir Beides nicht mehr.
Deaktivieren möchte ich DNSSEC nicht, das führt das ganze Konzept ja ad absurdum...
Bitte schafft hier endlich eine Lösung. Ihr habt einen Ruf zu verlieren als Experten auf genau diesem Gebiet
Leider besteht das Problem noch immer. Die letzten Tage waren vereinzelt mal Verbindungen möglich, sowohl zum Abrufen als auch zum Versenden. Seit gestern aber geht bei mir Beides nicht mehr.
Deaktivieren möchte ich DNSSEC nicht, das führt das ganze Konzept ja ad absurdum...
Bitte schafft hier endlich eine Lösung. Ihr habt einen Ruf zu verlieren als Experten auf genau diesem Gebiet
Und nochmal zum Kernproblem:
Ich gehe davon aus, dass es zwei Probleme geben könnte:
Zum einen kann es bei Nutzung eines VPN, von besonders strengen (oder kaputten) DNS-Resolvern oder sonst auf der Strecke von Anwender zum Server Probleme geben, die außerhalb des Einflusses von mailbox.org liegen.
Das andere Problem ist tatsächlich ein DNSSEC-Problem bei mailbox.org. Grundsätzlich ist DNSSEC funktionsfähig und korrekt. Allerdings wird ein älterer (veralteter?) Algroithmus 7 verwendet, den aber bisher wohl die meisten gängigen Resolver noch als korrekt akzeptieren. Gleichzeitig gibt es einen Algorithmus 10 der verwaist ist, und nicht verifizierbar ist. Offensichtlich ein unvollständiger Rollover zu einem neuen (aktuelleren) Algorithmus. Diese beiden Algorithmen sind auf der Testseite https://dnsviz.net/d/mailbox.org/dnssec/ ersichtlich. Grundsätzlich wohl kein Problem, aber FAirEmail ist da wohl bei der Prüfung von DNSSEC sehr genau/heikel/überkorrekt?
Mailbox.org sollte also entweder ausschließlich den veralteten Algorithmus verwenden und alles andere löschen, oder den neueren Algorithmus vollständig und korrekt hinzufügen und den alten löschen. Alternativ könnte mailbox.org, wenn eh etwas gändert werden muss, auch gleich auf den aktuellsten Algorithmus 13 wechseln.
Ich befürchte allerdings, dass die Systeme, Strukturen und Setups von mailbox.org mittlerweile sehr groß und komplex geworden sind, und ziemlich sicher von den Leuten dort alles incl. DNS komplett selber gemacht wird. Mailbox.org war einer der ersten die DNSSEC und DANE eingeführt haben. Da was zu ändern braucht Zeit und vor allem ausreichend Personal mit freien Kapazitäten. Das ist was anderes, wie wenn ich mit meiner eigenen privaten Domain beim Domainbetreiber einfach den Schalter "Dnssec" aktiviere, und dann fehlerfrei automatisiert sofort das aktuellste Setup habe. Fehler bei DNSSEC haben Konsequenzen, geht da was schief, dann ist mailbox.org komplett weg vom Fenster. Kein imap, kein Web, kein gar nix. Selbst die DENIC hatte vor kurzem ja ein größeres Problem, was auch einige Stunden anhielt, und zu massiven Problemen bei de-Domains geführt hat. Und bei der Denic arbeiten sicher keine Amateure, relevante Änderungen werden dort sicherlich im Mehr-Augen-Prinzip nach festen Ablaufschemata gemacht, und trotzdem hat es einen Fehler gegeben.
Nachtrag (Edit): Die Prüfung vom DNSSEC/DANE beim Mailclient ist eine absolute Seltenheit. Daher ist es jetzt sicherlich kein Drama, das auf Anwenderseite zu deaktivieren. Damit ist man dann immer noch so sicher, wie vermutlich 99 % der sonstigen Mail-Nutzer. Die Transportveschlüsselung ist weiterhin vollständig vorhanden. Trotzdem ist DNSSEC/DANE ein zusätzliches Sicherheitsfeature mit dem mailbox.org wirbt, und daher sollte das grundsätzlich schon aktuell gehalten werden.
Und nochmal zum Kernproblem:
Ich gehe davon aus, dass es zwei Probleme geben könnte:
Zum einen kann es bei Nutzung eines VPN, von besonders strengen (oder kaputten) DNS-Resolvern oder sonst auf der Strecke von Anwender zum Server Probleme geben, die außerhalb des Einflusses von mailbox.org liegen.
Das andere Problem ist tatsächlich ein DNSSEC-Problem bei mailbox.org. Grundsätzlich ist DNSSEC funktionsfähig und korrekt. Allerdings wird ein älterer (veralteter?) Algroithmus 7 verwendet, den aber bisher wohl die meisten gängigen Resolver noch als korrekt akzeptieren. Gleichzeitig gibt es einen Algorithmus 10 der verwaist ist, und nicht verifizierbar ist. Offensichtlich ein unvollständiger Rollover zu einem neuen (aktuelleren) Algorithmus. Diese beiden Algorithmen sind auf der Testseite https://dnsviz.net/d/mailbox.org/dnssec/ ersichtlich. Grundsätzlich wohl kein Problem, aber FAirEmail ist da wohl bei der Prüfung von DNSSEC sehr genau/heikel/überkorrekt?
Mailbox.org sollte also entweder ausschließlich den veralteten Algorithmus verwenden und alles andere löschen, oder den neueren Algorithmus vollständig und korrekt hinzufügen und den alten löschen. Alternativ könnte mailbox.org, wenn eh etwas gändert werden muss, auch gleich auf den aktuellsten Algorithmus 13 wechseln.
Ich befürchte allerdings, dass die Systeme, Strukturen und Setups von mailbox.org mittlerweile sehr groß und komplex geworden sind, und ziemlich sicher von den Leuten dort alles incl. DNS komplett selber gemacht wird. Mailbox.org war einer der ersten die DNSSEC und DANE eingeführt haben. Da was zu ändern braucht Zeit und vor allem ausreichend Personal mit freien Kapazitäten. Das ist was anderes, wie wenn ich mit meiner eigenen privaten Domain beim Domainbetreiber einfach den Schalter "Dnssec" aktiviere, und dann fehlerfrei automatisiert sofort das aktuellste Setup habe. Fehler bei DNSSEC haben Konsequenzen, geht da was schief, dann ist mailbox.org komplett weg vom Fenster. Kein imap, kein Web, kein gar nix. Selbst die DENIC hatte vor kurzem ja ein größeres Problem, was auch einige Stunden anhielt, und zu massiven Problemen bei de-Domains geführt hat. Und bei der Denic arbeiten sicher keine Amateure, relevante Änderungen werden dort sicherlich im Mehr-Augen-Prinzip nach festen Ablaufschemata gemacht, und trotzdem hat es einen Fehler gegeben.
Nachtrag (Edit): Die Prüfung vom DNSSEC/DANE beim Mailclient ist eine absolute Seltenheit. Daher ist es jetzt sicherlich kein Drama, das auf Anwenderseite zu deaktivieren. Damit ist man dann immer noch so sicher, wie vermutlich 99 % der sonstigen Mail-Nutzer. Die Transportveschlüsselung ist weiterhin vollständig vorhanden. Trotzdem ist DNSSEC/DANE ein zusätzliches Sicherheitsfeature mit dem mailbox.org wirbt, und daher sollte das grundsätzlich schon aktuell gehalten werden.
Hallo,
danke für Ihre Beiträge.
Wir werden das erneut an unsere Administratoren weitergeben und Sie auf dem Laufenden halten, sobald es neue Erkenntnisse gibt. Bis dahin bitten wir Sie noch um ein wenig Geduld.
Vielen Dank!
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Hallo,
danke für Ihre Beiträge.
Wir werden das erneut an unsere Administratoren weitergeben und Sie auf dem Laufenden halten, sobald es neue Erkenntnisse gibt. Bis dahin bitten wir Sie noch um ein wenig Geduld.
Vielen Dank!
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Liebe Community,
nach erfolgter Prüfung durch unsere Administratoren können wir bestätigen, dass mailbox.org über eine gültige DNSSEC-Kette verfügt.
Aktuell werden alle Einträge der Zone mit dem ALGO-7-Key signiert. Dies ist der aktuell gültige und aktive Signing-Key. Ein Teil der Einträge trägt zusätzlich noch eine ältere Signatur des zuvor entfernten ALGO-10-Keys (Doppelsignierung). Der ALGO-10-Key wurde bereits als Signing-Key entfernt und erzeugt keine neuen Signaturen mehr. Bei den betroffenen Einträgen handelt es sich also um Alt-Signaturen, die noch nicht überschrieben wurden.
Sobald ein Eintrag im Rahmen der regulären Zonenverarbeitung neu signiert wird, entsteht automatisch nur noch die aktuelle ALGO-7-Signatur; die alte ALGO-10-Signatur entfällt dabei. Dieser Prozess ist bereits angelaufen und setzt sich sukzessive über alle betroffenen Einträge fort. Aufgrund der Zoneneinstellungen (u. a. TTL- und Resigning-Intervalle) wird dieser Vorgang jedoch einige Zeit in Anspruch nehmen.
Für einen Teil der wichtigen Einträge haben wir das Re-Signing bereits manuell ausgelöst, um nicht auf den regulären Zyklus warten zu müssen. Aufgrund der Komplexität der Zone möchten wir für die verbleibenden Einträge jedoch auf den automatischen Abschluss dieses Prozesses warten, anstatt flächendeckend manuelle Re-Signings vorzunehmen.
Nach Abschluss dieses Prozesses planen wir die Umstellung auf einen aktuellen Signing-Algorithmus.
Imap.mailbox.org und dessen A- und AAAA-Einträge haben wir manuell neu signieren lassen. Nach Ablauf des DNS-Cachings sollte hier nur noch eine Signatur zurückgemeldet werden, wodurch der Fehler behoben wäre.
Wir bitten um etwas Geduld während dieser Übergangsphase und stehen für Rückfragen gerne zur Verfügung.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Liebe Community,
nach erfolgter Prüfung durch unsere Administratoren können wir bestätigen, dass mailbox.org über eine gültige DNSSEC-Kette verfügt.
Aktuell werden alle Einträge der Zone mit dem ALGO-7-Key signiert. Dies ist der aktuell gültige und aktive Signing-Key. Ein Teil der Einträge trägt zusätzlich noch eine ältere Signatur des zuvor entfernten ALGO-10-Keys (Doppelsignierung). Der ALGO-10-Key wurde bereits als Signing-Key entfernt und erzeugt keine neuen Signaturen mehr. Bei den betroffenen Einträgen handelt es sich also um Alt-Signaturen, die noch nicht überschrieben wurden.
Sobald ein Eintrag im Rahmen der regulären Zonenverarbeitung neu signiert wird, entsteht automatisch nur noch die aktuelle ALGO-7-Signatur; die alte ALGO-10-Signatur entfällt dabei. Dieser Prozess ist bereits angelaufen und setzt sich sukzessive über alle betroffenen Einträge fort. Aufgrund der Zoneneinstellungen (u. a. TTL- und Resigning-Intervalle) wird dieser Vorgang jedoch einige Zeit in Anspruch nehmen.
Für einen Teil der wichtigen Einträge haben wir das Re-Signing bereits manuell ausgelöst, um nicht auf den regulären Zyklus warten zu müssen. Aufgrund der Komplexität der Zone möchten wir für die verbleibenden Einträge jedoch auf den automatischen Abschluss dieses Prozesses warten, anstatt flächendeckend manuelle Re-Signings vorzunehmen.
Nach Abschluss dieses Prozesses planen wir die Umstellung auf einen aktuellen Signing-Algorithmus.
Imap.mailbox.org und dessen A- und AAAA-Einträge haben wir manuell neu signieren lassen. Nach Ablauf des DNS-Cachings sollte hier nur noch eine Signatur zurückgemeldet werden, wodurch der Fehler behoben wäre.
Wir bitten um etwas Geduld während dieser Übergangsphase und stehen für Rückfragen gerne zur Verfügung.
Viele Grüße
Ihr mailbox Team
---
Nützliche Links:
Gute Nachrichten: Mailbox.org hat sein Versprechen eingelöst. Die Profis von Heinlein haben sich offenbar der DNS-Problematik sehr zügig und abschließend angenommen. Es ist .... soweit man das als Endnutzer beurteilen kann .... alles perfekt. Keine Altlasten, keine Doppelsignaturen, kein veralteter Algorithmus mehr. Damit sollte jeder DNSSEC/DANE streng prüfen können und FairEmail sollte keine Probleme mehr haben. Respekt, dass eine geplante Umstellung auf einen aktuellen Signing-Algorithmus (Algo 13) innerhalb von weniger als 2 Monaten passiert ist. Danke dafür, und bitte keine Rolle rückwärts mehr ;-)
Gute Nachrichten: Mailbox.org hat sein Versprechen eingelöst. Die Profis von Heinlein haben sich offenbar der DNS-Problematik sehr zügig und abschließend angenommen. Es ist .... soweit man das als Endnutzer beurteilen kann .... alles perfekt. Keine Altlasten, keine Doppelsignaturen, kein veralteter Algorithmus mehr. Damit sollte jeder DNSSEC/DANE streng prüfen können und FairEmail sollte keine Probleme mehr haben. Respekt, dass eine geplante Umstellung auf einen aktuellen Signing-Algorithmus (Algo 13) innerhalb von weniger als 2 Monaten passiert ist. Danke dafür, und bitte keine Rolle rückwärts mehr ;-)
Kommentare wurden auf dieser Seite deaktiviert! Bitte benutzen Sie für einzelne Themen auch separate Einträge, da wir diese dann einzeln mit einem Status versehen können. Ein Sammelthema ist unnötig unübersichtlich.