Extras -> Adressbuch, dann Datei -> Neu -> CardDav Adressbuch
Beiträge von Susi to visit
-
-
Thunderbird ist in meinem Notebook-Handlingssystem die einzige Software, deren Daten zur aktiven Verwendung komplett in C: abliegen, eben wegen der Probleme und Risiken mit Profilordnern und deren Verschieben.
Was sind denn das für Probleme und Risiken, von denen du schreibst?
-
Ich vermute mittlerweile, dass das Problem beim Addon "Lookout (Zeig'smir)"liegt, denn in der FAQ habe ich gefunden:
Das Known Issue in der Liste spricht jedenfalls dafür. Wenn es denn daran liegt und das Add-On nicht gefixt wird, dann bleibt nur noch:
Er kann sein Outlook so einstellen, dass es nicht in diesem proprietären Format sendet.
Oder der Wechsel zu Outlook.
-
Irgendwie scheint eigentlich nicht Google das Problem zu sein, sondern die Ignoranz dem gegenüber
Wessen Ignoranz meinst du? Die der Benutzer oder die der Hersteller? Dem Großteil der Benutzer ist die Installation eines CR meiner Meinung nach nicht zuzumuten. Zumal u.U. auch noch die Garantie erlischt. Du hast ja selbst geschrieben, dass es durchaus aufwendig ist.
Erfahrenen Benutzer hingegen ist es durchaus zuzutrauen. Wenn sie sich denn trauen.
Oder meinst du die Ignoranz der Hersteller und Vertreiber, die stur ihr angepasstes Google-Android ausliefern? Die könnten Millionen auf einen Schlag erreichen. Machen sie aber nicht.
Immerhin, ein paar kleine Hersteller gibt es, die ein CR vorinstallieren, auch mit MicroG. Deren Produkte sind dann aber oftmals etwas teurer, nicht high-end und nicht beim Discounter zu bekommen.
helfen die überaus interessanten Seiten von Mike Kuketz,
Die kann ich ebenfalls sehr empfehlen (außer für Fanboys ;-)) Der Mann kennt sich zu Sicherheitsthemen wirklich aus. Zu beachten ist aber auch hier: Genau wie das CR haben viele der Maßnahmen, der er aufzeigt, Nebenwirkungen.
Am Ende bin ich überaus glücklich, mir den Umbau angetan zu haben. Alleine dieses Glücksgefühl ist schon unbezahlbar
Genau! Das kommt nämlich noch hinzu. Ein Erfolgserlebnis tut einem jedem gut.
-
Was mir auffällt (aber ich bin Mac-User) sind die eckigen Klammern, die die Namen der [pop.xxx.xx] Ordner einrahmen.
Das ist ein "Feature" vom Total Commander.
-
Ich würde zum Ausprobieren sehr ein CR empfehlen, welches MicroG mitbringt. Bei /e/ (basiert auf LineageOS) ist das z.B. der Fall. Das erspart erste Enttäuschungen. MicroG nachzuinstallieren kann u.U. etwas zäh werden. Außerdem muss man erstmal wissen, dass es das als Ersatz für die Google Play Dienste überhaupt gibt.
Es geht auch ohne MicroG, aber dann hat man den o.g. Nachteil, dass manche Apps nicht funktionieren, z.B. das erwähnte Navi über Maps oder auch die Corona Warn App. Nicht zu vergessen: der Playstore.
Nebenbei, so ein CR entfernt zwar die Google-Tracker aus dem Android und macht damit schonmal einen großen Schritt. Es kann aber nicht davor schützen, dass Apps an deren Hersteller senden. Auch vor dem Online-Tracking gewisser Webseiten schützt es nicht per se. Blind jede App zu installieren und denen alle Rechte einräumen, ist auch mit einem CR keine gute Idee.
-
/*
Um mein Smartphone zu "ent-googeln", fehlt mir leider das nötige Wissen;
Vielleicht hast du, wie inzwischen viele, noch ein altes Smartphone im Schrank liegen. Dann würde ich sagen, einfach mal machen. Das ist gar nicht schwierig.
Wenn du richtig ent-googelst, also bei dem neuen OS auch keine Google-Dienste nachinstallierst, musst du dir für einige Apps Ersatz beschaffen. Google Maps z.B. funktioniert nicht als Navi, wenn man den Google-Ortungsdienst nicht hat. Deswegen macht man das ja. Es gibt aber Ersatz. In meinem Fall z.B. direkt vom Hersteller meines Motorrades.
Wenn du noch ein altes Gerät hast, lässt sich alles gefahrlos ausprobieren. Es lohnt sich.
*/
-
Mir stellt sich zunächst die Frage, welchen Zweck diese Meldung überhaupt hat.
Guter Punkt! Mich hat dieser Fehler (+ wiederkehrende Erinnerungen) auch schon zur Verzweiflung getrieben. So weit, dass ich inzwischen andere Kalendertools verwende. Ich habe einige Stunden damit verbracht, den Auslöser dieses Fehlers zu suchen. Hin und her getestet. Diese Frage hatte ich mir bisher gar nicht gestellt. Tomaten. Du bist der erste hier, der das überhaupt hinterfragt.
Ich stimme dir zu. Sinn und Zweck dieser Meldung sind auch mir schleierhaft.
-
CardBook ist aber sicherlich nicht für eine SOgo-Anbindung erforderlich und ggf. sogar kontraproduktiv.
Ich habe den Connector früher ebenfalls benutzt. Soweit ich weiß, macht der nichts anderes, als die CardDAV-Funktionalität für das alte TB-Adressbuch zur Verfügung zu stellen. Cardbook kann von Haus aus CardDAV. Inzwischen kann auch der Thunderbird selbst CardDAV. Der Connector wird somit nicht mehr benötigt. Selbst Cardbook benötigt man nicht mehr, wenn man mit dem Umfang des TB-Adressbuchs auskommt.
-
Sollte das Problem damit zu tun haben
Zu Anfang waren bei den Emails als Anhang nur die Datei "winmail.dat" vorhanden.
bzw. der Erweiterung, die mit diesem Format umgehen kann, müssest du den Absender kontaktieren. Er kann sein Outlook so einstellen, dass es nicht in diesem proprietären Format sendet.
Sollte es hier scheitern:
Im Forum habe ich dann gelesen, dass der Kalender mit der E-Mail-Adresse verbunden sein muss.
dann stelle einfach auf mehrere Kalender um, denen du jeweils die zugehörige E-Mail-Adresse zuweist. Sowohl der Thunderbird als auch das iPhone können dir beide Kalender gleichzeitig anzeigen. Du kannst auch in beiden arbeiten. Lediglich auswählen musst du den Kalender.
Um dienstliches und privates organisieren zu können, darf es bei mir nur einen Kalender geben.
Mir fällt kein Grund ein, weshalb du unbedingt beide Konten in einen Kalender drücken müsstest. Weshalb darf es denn nur einen Kalender geben?
-
Vermutungen habe ich dazu aufgestellt, wie Google konkret verfährt. Das habe ich auch ganz klar so geäußert, dass das Vermutungen sind. Im Gegensatz zu dir, stelle ich nicht etwas als Tatsache in den Raum, wenn mir die Kenntnis fehlt.
Zu den Themen OAuth und 2FA habe ich die Hintergründe erläutert, weil ganz deutlich wurde, dass das hier völlig durcheinander ging. Da drohte schlicht die Gefahr, dass ihr die Julia und spätere Leser aufs Glatteis führt. Das waren keine Vermutungen, sondern einfach die Gegebenheiten.
Sollte darin ein Fehler meinerseits stecken, dann zeige ihn auf. Da wäre ich dir nicht böse. Bisher gehst du auf die technischen Argumente und deine Fehlaussagen nicht weiter ein. Mehr als ein dummer Spruch war wieder mal nicht drin. Warum wohl?
Egal wie Google es am Ende handhabt, technisch ist es so, dass wenn die Julia etwas zusätzlich benötigt, sei es ein Telefon, eine App oder eben schlicht das Cookie zulassen muss, dann liegt das an der 2FA und nicht am OAuth.
Ferner entsteht eben durch die 2FA ein deutlicher Sicherheitsgewinn, ob du Google nun magst oder nicht, ob dir OAuth gefällt oder nicht. Die 2FA ist etwas Gutes. Hier haben sie anderen Providern etwas voraus.
Da kannst du noch so gegen Google trollen, dumme Sprüche machen und dir Smileys von einem User abholen, der sich zumindest in diesem Forum normalerweise wegduckt. (Warum wohl?). Google macht das besser als viele andere.
-
Ein App-Passwort ist eine Alternative und keine Voraussetzung für OAuth2,
Ich streite mich nicht mit Leuten herum, die immer noch nicht verstanden haben, was OAuth2 überhaupt ist.
Du solltest mal lesen und versuchen zu verstehen, was ich oben geschrieben habe: Dass das App-Passwort der 2FA dient, nicht OAuth. Streng genommen benötigt OAuth2 überhaupt kein Passwort.
In dem von dir selbst verlinkten Artikel steht ausdrücklich:
ZitatApp-Passwörter können nur für Konten verwendet werden, bei denen die Bestätigung in zwei Schritten aktiviert ist.
Kurz: Keine 2FA - kein App-Passwort.
Ganz egal ob o0Julia0o nun eine Telefonnummer benötigt, was ich nicht glaube, oder ein Cookie, was ich eher glaube, dann deshalb, weil Google 2FA macht, nicht wegen OAuth2. Du hast den Unterschied ganz offensichtlich immer noch nicht verstanden. Ebenso wenig wie die Funktionsweise mit den Tokens.
Tut mir Leute, man kann euren Verwechselungen und Formulierungen ganz deutlich entnehmen, dass ihr echt nicht umrissen habt, was OAuth2 überhaupt ist.
-
/*
Da es ganz offensichtlich vielen Schwierigkeiten bereitet, OAuth2 und 2FA zu unterscheiden, mir ist noch ein Beispiel eingefallen.
Wenn ich einen Kunden besuche, zeige ich zunächst am Empfang meinen Ausweis vor bzw. geben ihn ab. Dann kommt jemand vom Kunden, der mich kennt, und holt mich ab. Das ist der zweite Faktor, wenn man so will. Er bestätigt, dass ich auch wirklich ins Gebäude gelassen werden soll. Der Ausweis allein genügt nicht. Das wäre also die 2FA. Damit habe ich mich authentifiziert.
Nun darf ich natürlich nicht alle Räume betreten. Deshalb bekommen ich am Empfang einen Besucherausweis. Auf dem steht nur eine Nummer, sagen wir 0815. Mein Name ist darauf nicht zu sehen, auch kein Foto. Im System des Kunden ist hinterlegt, wie lange der Ausweis gilt und welche Räume damit betreten werden dürfen. Komme ich an einen Eingang, halte ich meinen Ausweis an das Lesegerät. Das fragt nun bei einem Server ab, ob der Ausweis überhaupt vom Kunden ausgestellt wurde, ob er zeitlich gültig ist und ob er für diesen Raum gilt. Wird vom Server alles bestätigt, werde ich also autorisiert, den Raum zu betreten. Die Tür öffnet sich. Das wäre OAuth2.
*/
-
Hier geht es ja munter weiter. OAuth und 2FA werden komplett durcheinander geworfen. So kann man auch Chaos erzeugen.
Es handelt sich in der jetzigen Form um einen Autorisierungsstandard ohne zusätzliche Authentifizierung.
Das ist technisch nicht richtig dargestellt und hat überhaupt nichts mit dem jetzigen Standard zu tun. Das A in OAuth steht für Autorisierung, nicht für Authentifizierung. Die Authentifizierung ist im Grunde überhaupt nicht Bestandteil von OAuth2. Ich habe oben schon versucht, das zu erklären.
Jeder im Besitz des Tokens kann somit auf deine Ressourcen zugreifen.
Auch das ist so nicht ganz richtig. Die Tokens werden im Hintergrund zwischen den beteiligten Apps/Servern ausgetauscht. Der Anwender bekommt sie gar nicht zu sehen! Außerdem haben die Tokens eine Ablaufzeit, weshalb nach der Authentifizierung für die Autorisierung auch ein Renewal-Token geliefert werden kann.
Du meinst vermutlich etwas ganz anderes, nämlich den zweiten Faktor der 2FA, der hier vermutlich über ein Cookie realisiert ist. In der Tat kann jemand bei dem Cookie-Verfahren auf das Konto zugreifen, wenn er das Passwort kennt und an den Browser/Thunderbird kommt, auf dem das Cookie gespeichert ist. Das ist aber nichts Besonderes. Bei einer 2FA über SMS oder eine Smartcard ist es nicht anders. Wer an das Smartphone kommt und auch das Passwort kennt, bekommt Zugriff.
Außerdem muss es auch bei der 2FA immer eine Möglichkeit geben, an sein Konto zu gelangen, auch wenn man z.B. sein Smartphone verloren hat. Das geschieht meist über ein weiteres Geheimnis.
OAuth2 ist eben nicht nur ein Username mit Passwort.
OAuth2 ist etwas ganz anderes.
Zum Beispiel müssen Cookies aktiviert sein...
Das ist nur dann der Fall, wenn das über Cookies realisiert ist. Amazon z.B. bietet eine 2FA mit SMS als zweiten Faktor an. Da braucht es keine Cookies, dafür aber ein Telefon. Mein Arbeitgeber verfährt für die Einwahl per VPN ebenso, wahlweise per SMS oder App. Kein Cookie.
Im konkreten Fall hier gehe ich aber davon aus, dass Google nach der einmaligen Authentifizierung ein Cookie setzt. Das stellt dann den zweiten Faktor dar und ist der Ersatz für das Smartphone. Das ist natürlich bequemer, weil man nichts mehr eingeben muss. Es ist deshalb aber nicht automatisch weniger sicher. Man kann sich nur einloggen, wenn man dieses Cookie hat.
Was heißt das jetzt konkret für o0Julia0o? Wenn meine Vermutung stimmt, dass Google OAuth2 unterstützt und die 2FA über ein Cookie realisiert, dann musst du dich einmalig bei Google identifizieren. Das geschieht über dieses 16-stellige App-Passwort. Dann setzt Google in dem verwendeten Thunderbird ein Cookie. Zukünftig erscheint dieses Anmeldefenster dann nicht mehr, weil der Thunderbird eben über das Cookie bestätigt, dass du nicht nur dein Passwort kennst, sondern auch im "Besitz" dieses Thunderbird-Profils bist.
Jemand der deine E-Mails lesen will, muss also an deinen Thunderbird kommen. Selbst wenn er das 16-stellige Passwort kennt, damit allein kommt er nicht an deine E-Mails. Kennt er hingegen das Passwort zu deinem Google-Account, kann er sich dort anmelden und sein eigenes App-Passwort für seinen Thunderbird genieren. Hier lauert eine Schwachstelle. Mit OAuth hat die aber nichts zu tun. Sie ließe sich umgehen, wenn Google für das Erstellen des App-Passwortes zusätzlich zum normalen Login eben auch einen zweiten Faktor verlangt, z.B. per Smartphone, Cookie im Browser oder auch nur eine weitere Sicherheitsabfrage. Ob und wie Google das macht, weiß ich mangels Konto nicht. Ich hatte gehofft, dass das hier jemand erklärt.
Man kann zu Google stehen wie man will, in diesem Fall erhöhen sie durch die 2FA die Sicherheit deutlich gegenüber nur Benutzername + Passwort. Das sollte man zugestehen. Getrolle ist hier wirklich nicht angebracht.
-
Ich muss sagen, Drachen, jetzt überraschst du mich sehr. All die Dinge, die du zu Schutz deiner Daten anführst, haben mit dem Thema nicht viel zu tun. Keine dieser Maßnahmen schützt dich davor, dass die dort genannten Firmen dich eindeutig identifizieren, alle deine Gewohnheiten und Vorlieben analysieren und diese Daten, meinetwegen anonymisiert, weiterverkaufen.
Wie wir wissen, gehören dazu auch sehr persönliche Informationen, wie z.B. Erkenntnisse über deinen Gesundheitszustand, dein finanzieller Status oder wo du dich wann aufgehalten hast.
-
Also funktioniert ein E-Mail-Abruf ohne hinterlegt Telefonnummer(der Authenticator etc. benötigen ja alle auch alle eine Telefonnummer) nicht mehr nach dem 30. Mai 2022?
Das heißt es nicht zwangsläufig. Ich hatte ja erwähnt, dass sich die 2FA auch über ein (Einmalpasswort + ) Cookie verwirklichen lässt, also auch ohne Telefon. Für mich liest sich das, was die anderen oben geschrieben haben, so, als würde Google das anbieten. Ich weiß es aber nicht. Daher:
Vielleicht sollte mal jemand, der einen Account bei Google benutzt und der auch versteht, was hinter 2FA und OAUTH2 steckt, hier für etwas mehr Klarheit sorgen.
-
Die hier oben angeführten Artikel wirken auf mich so, als hätten deren Autoren selbst nicht verstanden, was genau Google da vorhat. Ansonsten hätten sie das doch verständlicher formulieren können.
Vielleicht sollte mal jemand, der einen Account bei Google benutzt und der auch versteht, was hinter 2FA und OAUTH2 steckt, hier für etwas mehr Klarheit sorgen.
Ich selbst habe keinen Account bei Google. Ich weiß daher nicht genau, wie Google hier vorgeht. Bei der Erklärung der Begrifflichkeiten kann ich aber hoffentlich behilflich sein. Die werden leider auch hier im Forum munter durcheinander geworfen und teilweise vermischt.
2FA, Zwei-Faktor-Authentifizierung
Was ist Authentifizieren? Hier geht es darum, die Identität eines Benutzers zu bestätigen. Es soll also geklärt werden, ob derjenige, der sich gerade anmeldet, wirklich der ist, der er vorgibt zu sein.
Ein Passwort allein (Faktor Wissen) ist relativ unsicher. Deshalb wird ein zweiter Faktor abgefragt, z.B. der Faktor Besitz. Das kann ein Smartphone sein, eine Smartcard, eine App oder auch ein Cookie auf einem PC usw. .
Letzteres ist wichtig, wenn man den zweiten Faktor nicht jedes Mal eingeben möchte. Im Cookie ist ein mehr oder weniger langer "Schlüssel" mehr oder weniger sicher gespeichert und kann automatisch abgefragt werden.
Wichtig: Das alles dient allein der Identifikation. Mehr ist bis hier nicht passiert.
OAuth2 steht für Open Authorization in Version 2
Was ist Autorisieren? Beim Autorisieren geht es darum, welche konkreten Rechte ein (bereits authentifizierter) Benutzer bekommt. Das hat per se zunächst nichts mit der Authentifizierung zu tun.
Das Besondere bei OAuth2 ist nun, dass diese Rechte im Hintergrund von einem zentralen Dienst (Authorization Server) anderen Diensten (Clients) automatisch gewährt werden können, ohne dass diese die Anmeldedaten erfahren.
In der Praxis kombiniert man beides. Denn es ergibt wenig Sinn, jemandem Rechte einzuräumen, den man nicht zuvor sicher identifiziert hat. Siehe dazu OpenID Connect.
Die Kombination ermöglicht es z.B., dass jemand, der sich bei Dienst A identifiziert hat, einem anderen Dienst B über OAuth2 erlaubt, auf die E-Mails zuzugreifen. Das alles, ohne dass Dienst B irgendein Passwort erfährt.
Ein idealisiertes Beispiel, wie es sich die großen Player vorstellen:
Nehmen wir an, es gibt eine Firma "TrustMe". Diese Firma kennt meine Identität und stellt den Authorization Server. Als einzige Seite kennt sie daher meine Anmeldedaten.
Nun möchte ich bei der Firma "KaufWas" einkaufen. Bei der Anmeldung dort leitet mich die Seite auf "TrustMe" um. Dort melde ich mich an und bestätige über 2FA, dass ich wirklich die Susi bin.
Über OAuth2 bekommt die Seite "KaufWas" nun mitgeteilt, dass ich mich korrekt identifiziert und einen Einkauf erlaubt (autorisiert) habe. Außerdem erteile ich die Erlaubnis, den Service "Zahlemann" zu benutzen.
Beim Bezahlen wird dann die Seite "KaufWas" per OAuth die Seite "Zahlemann" kontaktieren. Die wiederum lässt sich über "TrustMe" ebenfalls per OAuth bestätigen, dass der Einkauf von mir genehmigt war.
Dank OAuth hat außer "TrustMe" keine der beteiligten Firmen meine Anmeldedaten erhalten. Das verringert die Gefahr, dass diese Daten geklaut werden. Andererseits genügt ein Hack, um gleich Zugriff auf viele Dienste zu bekommen. Deshalb ist 2FA hier so wichtig!
Google ermöglicht einen Single-Sign-On für viele Dienste über OAuth2. Da ist es nur verständlich, dass sie auch 2FA verlangen. Alles andere wäre sträflich. Das ist nicht böse, sondern konsequent.
Man kann vereinfacht sagen, 2FA macht den Login sicherer, OAuth macht ihn bequemer. Für den Nutzer ergibt sich der Vorteil, sich nur ein Mal anmelden zu müssen. Die Bequemlichkeit hat aber ihren Preis. Sie wird u.a. damit erkauft, dass derjenige, der den Authorization Server betreibt, so etwas wie die Spinne im Netz ist.
-
Versuche es zunächst einmal im Fehlerbehebungsmodus in einem ganz frischen Profil, ohne jede Erweiterung. Binde nur diesen Kalender nativ ein. Wenn du es auch damit reproduzieren kannst, würde ich an deiner Stelle einen Bug aufmachen. Schau zunächst, ob es schon einen in der Richtung gibt.
-
Ich muss gestehen, aus Beitrag #12 werde ich nicht schlau. Ebenso, wer was wann an wen weiterleitet, ist mir nicht ersichtlich. Trotzdem noch ein paar Anmerkungen.
Sollte das Weiterleiten kein Weiterleiten, sondern tatsächlich ein Umleiten sein, kann allein schon das zu einem Problem mit SPF führen. Der Server des Empfängers sieht dann die originale Absender-Domain, aber die IP-Adresse des umleitenden Servers. Die steht nicht auf der Liste und damit schlägt SPF dann an.
So wie das Verfahren des Antwortens beschrieben ist, mit den Identitäten - auch hier ist mir die Beschreibung unklar - könnte das aber schon auf ein Relaying hinauslaufen.
Last but not least, inzwischen ist ja auch von Kollegen die Rede. Betrifft die das Problem auch? Das Eingangsposting und der Titel klingen eher so, als wärst nur du, mxr, betroffen.
Neben der Spamfilterung auf dem Transportweg gibt es ja u.U. auch noch die lokale beim Empfänger. Und damit sind wir wieder am Anfang. Solange unklar ist, wo (Server auf dem Transportweg oder beim Empfänger) und aus welchem Grund (Blacklist, SPF oder gar der Inhalt, ...) die Deklaration als Spam erfolgt, bleibt alles Spekulation.
-
Du sollst ja gerade keinen fremden Server verwenden, sondern den des Providers, der eure Domain hosted. Ihr habt doch einen Provider? Der stellt euch normalerweise alles zur Verfügung.
