Google-Adressen synchronisieren nicht vollständig

  • Hallo.

    Bei mir funktioniert die Synchronisation der Kontakte meines Google-Kontos mit einem TheBat-Adressbuch nur "teilweise": es werden nur 107 von 329 Kontakten synchronisiert, und zwar scheinbar willkürlich, weder alphabetisch noch gemäß in Google vorhandener Adressengruppen.
    Synchronisationsprotokoll: batboard.net/wcf/attachment/5647/

    Zudem springt meine CPU-Belastung auf etwa 25% und bleibt da, ohne das etwas erreicht wird. Das kann ich dann nur noch abstellen, indem ich TB schließe.
    Beim Neustart von TB kam dann diese Meldung, die ich aber als Laie nicht interpretieren kann:
    [Blockierte Grafik: https://s6.postimg.org/t35vwzlel/image.png]
    Die Meldung kommt nicht jedes Mal ... also ich krieg's nicht reproduziert.

    Meinen Virusscanner (Avast) habe ich übrigens mal testweise abgestellt, daran liegt's also nicht.
    Einstellungen im Adressbuch sind so:
    Dieses Adressbuch ist "Verbunden mit Google-Kontakten"
    Synchronisieren: manuell
    Serveradresse: google.com (nicht editierbar)
    Benutzer-ID: Vollständige Google-Email-Adresse

    Woran kann das liegen?
    Oder anders gefragt: Gibt es für The Bat eine zuverlässige Methode, Adressen mit Google zu synchronisieren?

    Danke für eure Hilfe!

    Spoiler anzeigen


    Ich bin ziemlich erstaunt, dass ein zeitgemäßes Emailprogramm nicht in der Lage ist, eine saubere Synchronisation mit einer Kontaktesammlung in der Cloud herzustellen X( ... Das kann doch schon jede popelige Fritz!box. Ich wäre enttäuscht, den Preis bezahlt zu haben für die Pro-Edition.

  • Wegen des Zertifikats solltes du mal auf die interne SSL-Einstellung gehen.
    Optionen → S/MIME und TLS…
    (•) Microsoft Crypto-API
    OK

    Hast du auch ein Windows mit aktualisierten Zertifikaten?
    - - -

    Und es gibt da bezüglich Google Contacts einige unerledigte Bugs im Ritlabs Bugtracker.
    Die fehlenden Gruppen sind schon nervig für andere, verstehe ich.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Synchronisationsprotokoll: google_sync.txt

    Ist nicht aufrufbar, da wohl falsch angehängt. Vielleicht besser den Inhalt in CODE platzieren.

    (•) Microsoft Crypto-API

    Oder bei der internen Implementierung bleiben und das fehlende Wurzelzertifikat in Trusted Root CA im Adressbuch importieren, so wie es auch in dem Hinweisfenster steht. So ein Screenshot wurde hier schon in einigen Threads gepostet (vgl. z.B. hier oder hier). Dafür ist aber zuerst ein Auszug aus dem Protokoll erforderlich ("Konto | Logdatei anzeigen..."), um festzustellen, welches Zertifikat fehlt.

    noch gemäß in Google vorhandener Adressengruppen.

    Google-Adressbuchgruppen werden wohl immer noch nicht importiert, s. z.B. #0000923: Import Groups when import Google contacts (BT-Verwendung).

  • Ich habe SSL-Einstellung umgeschaltet (war vorher "Interne Implementierung"). Ist das so richtig eingestellt?

    Hat aber keinerlei Veränderung gebracht bei den Adressen und Google-Sync.
    Sollte ich es dann lieber wieder zurückstellen? Werden jetzt meine Emails alle verschlüsselt?

    Und ob mein Windows aktualisierte Zertifikate hat, weiß ich nicht. Ich gehe davon aus, denn ich habe immer alle neuesten Windows-Updates (Win10) und bekomme keine negativen Meldungen vom System.

    Auf Gruppen in Google würde ich ja noch verzichten (notfalls), aber gar keine Synchronisierung?!? Wie kann man denn für ein Feature im Programm werben, die nicht funktioniert?

  • Ist nicht aufrufbar, da wohl falsch angehängt. Vielleicht besser den Inhalt in CODE platzieren.

    Code
    20.12.2017 23:55:55  HTTP request - GET https://www.googleapis.com/oauth2/v1/tokeninfo
    20.12.2017 23:55:55  HTTP request - GET https://www.googleapis.com/oauth2/v1/tokeninfo
    20.12.2017 23:55:55  Connecting to GMail CardDAV server...
    20.12.2017 23:55:55  HTTP request - PROPFIND https://www.googleapis.com/.well-known/carddav
    20.12.2017 23:55:55  HTTP request - PROPFIND https://www.googleapis.com/carddav/v1/principals/xyz@googlemail.com
    20.12.2017 23:55:55  Empfange Kontaktdetails vom Server...
    20.12.2017 23:55:55  HTTP request - PROPFIND https://www.googleapis.com/carddav/v1/principals/xyz@googlemail.com/lists/default
    20.12.2017 23:55:56  Lade 222 Kontakte vom Server
    20.12.2017 23:55:56  HTTP request - REPORT https://www.googleapis.com/carddav/v1/principals/xyz@googlemail.com/lists/default
  • Sollte ich es dann lieber wieder zurückstellen?

    Bei der internen Implementierung musst du das beachten, was ich oben geschrieben habe.


    Werden jetzt meine Emails alle verschlüsselt?

    Nachrichten selbst werden nur dann verschlüsselt, wenn man GnuPG oder PGP verwendet. Eine Verbindung zum Server wird hingegen verschlüsselt, wenn man in den Kontoeigenschaften beim Verbindungstyp TLS aktiviert hat. Das sind also verschiedene Sachen. Bei einer verschlüsselten Serververbindung werden bestimmte Zertifikate benötigt. Fehlt eines, kommt der o.g. Hinweis.

    Einmal editiert, zuletzt von sanyok (21. Dezember 2017 um 16:11)

  • Bei der internen Implementierung musst du das beachten, was ich oben geschrieben habe.

    "Microsoft Crypto-API" klingt für mich Laien attraktiver: so als ob sich Microsoft schon darum kümmert, dass das mit benötigten Zertifikaten schon funktioniert, und ich weiterhin nichts tun muss. Ist das eine richtige Annahme?

    Ich will doch eigentlich nur mailen und Google syncen ...
    Ich kenn das schon: da vergehen dann 3 Monate, dann kommt wieder irgendeine für mich unverständliche Meldung mit dem Wort "Zertifikat-Fehler", und dann fang ich wieder an zu recherchieren und verbringe Stunden damit, was zu verstehen, was gar nicht meine Profession sein soll.

  • Meinen Virusscanner (Avast) habe ich übrigens mal testweise abgestellt, daran liegt's also nicht

    Kann aber sein, wenn du mit Avast für Mail die verschlüsselte (SSL)-Verbuindung überprüfen lässt, ich glaube das ist der E-Mail-Schutz, schaltet Avast ein anderes Zertifikat dazwischen und The Bat! meckert das zu Recht an.

    • SSL-Suche: Aktivieren oder deaktivieren Sie das Prüfen von E-Mails, die über eine SSL/TLS-verschlüsselte Verbindung gesendet oder empfangen werden. Bei einigen E-Mail-Clients muss für diese Funktion ein Zertifikat vom Bildschirm „SSL-Scannen“ exportiert werden. Anschließend muss dieses Zertifikat in den Zertifikatspeicher des E-Mail-Clients importiert werden.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • "Microsoft Crypto-API" klingt für mich Laien attraktiver: so als ob sich Microsoft schon darum kümmert, dass das mit benötigten Zertifikaten schon funktioniert, und ich weiterhin nichts tun muss. Ist das eine richtige Annahme?

    Grundsätzlich ja, jedoch kann das benötigte Zertifikat auch in der Windows-Zertifikatsdatenbank fehlen und muss dann dort importiert werden.

    Zum Verständnis. Es geht hier um zwei Zertifikatsdatenbanken: entweder die interne (Interne Implementierung), die im TB!-Adressbuch "Trusted Root CA" verwaltet wird (TB!-Adressbuch aufrufen und dann im Menü "Ansicht" die Option "Zertifikatsdatenbanken" aktivieren), oder die externe Windows-Zertifikatsdatenbank (Microsoft Crypto-API), die in jeder Windows-Version enthalten ist und die man normalerweise über "Systemsteuerung | Internetoptionen | Inhalte | Zertifikate" erreicht.

    Um festzustellen, welches Zertifikat fehlt, muss man aber das Protokoll analysieren. Wenn du es hier in CODE postest, könnten wir vielleicht weiterhelfen. Am besten zuerst das Protokoll aufrufen und über das rote Kreuz oben alles löschen, was dort steht. Dann eine Verbindung zum Server aufbauen und, wenn der o.g. Hinweis wieder erscheint, das, was im Protokoll steht, hier in CODE posten.

    Im nächsten Schritt beschafft man sich das fehlende Zertifikat und importiert es, wie es in den anderen von mir verlinkten Threads beschrieben wird.

    Oft passiert das, weil man im AntiVirus-Programm bzw. Security Suite bzw. Anti-Junk-Programm oder Plugin wie ASS die Überprüfung von verschlüsselten Mailserver-Verbindungen aktiviert hat. Dann klinkt sich das jeweilige Drittprogramm dazwischen, wofür ein Zertifikat benötigt wird, welches man sich wiederum vom Hersteller dieses Drittprogramms beschaffen muss. Auch in einem solchen Fall muss man entweder das Zertifikat importieren oder die Überprüfung abschalten.


    Ich kenn das schon: da vergehen dann 3 Monate, dann kommt wieder irgendeine für mich unverständliche Meldung mit dem Wort "Zertifikat-Fehler",

    Zertifikate können ablaufen und müssen dann ersetzt/erneuert werden. Windows und eigentlich auch Ritlabs machen das in regelmäßigen Abständen. Allerdings werden dabei nur bekannteste Zertifikate ersetzt. Bei einigen muss man sich hingegen selbst darum kümmern.

  • Ich vermute, dass Zertifikate nicht das Problem sind, denn 107 von 329 Kontakte werden abgeholt (allerdings nur geholt, nicht gesynct: Änderungen in TB werden nicht nach Google übertragen). Also stellt TB offensichtlich irgendeine Verbindung her und wird dabei nicht aufgehalten von Zertifikatsprüfungen.

    Möglicherweise ist ein Google-Contacts-Datensatz defekt, der bei Nummer 107 den Prozess abschießt, danach geht dann gar nichts mehr? Ich könnte mal testweise ein neues Googlekonto anlegen und eine Haufen sauberer Kontakte-Datensätze eintragen (importieren), und dann versuchen.
    Meint Ihr, der Aufwand bringt mich weiter?

    Ich habe in TB das Konto für die Googlemailadresse gelöscht (inkl. der Kontodateien). Auch habe ich das Adressbuch komplett gelöscht, inklusive der Datei im Userordner. Ein erneuter Versuch zeigte denselben Effekt. Es ist jetzt aber KEINE Serveradresse "google.com" in den Einstellungen zum Adressbuch eingetragen (ausgegrautes Feld), trotzdem rief er ab (wieder nur 107 Einträge). Benötigt der kein Passwort? Wenn doch, wieso kennt er das noch, wenn ich doch das Konto gelöscht habe?

    Exkursfrage: Ich finde zwei Dateien mit ähnlichen Namen im Userordner: ADDRBOOK.ENI, ADDRBOOK.INI
    Was ist der Unterschied? Sie enthalten sehr ähnliche Inhalte, sind aber unterschiedlich alt.
    Darin gibt es noch Verweise auf ehemalige Adressbücher, darf ich diese Verweise dort löschen?

  • Ich vermute, dass Zertifikate nicht das Problem sind,


    Der o.g. Hinweis erscheint normalerweise, wenn man Nachrichten abholt oder versendet. Er kann aber natürlich auch dann erscheinen, wenn man verschlüsselte Verbindung zum Mailserver für andere Zwecke aufbaut, wie z.B. für CardDAV o.ä.

    Wie ist es in deinem Fall? Kannst du Nachrichten problemlos senden und empfangen? Geht's also nur um die Adressen?


    Meint Ihr, der Aufwand bringt mich weiter?

    Versuchen sollte man es. Solange die Adressen nicht in Gruppen aufgeteilt sind, müsste TB! sie alle synchronisieren. Es ist jedenfalls nicht bekannt, dass nur eine bestimmte Anzahl von Adressen erlaubt ist.


    Benötigt der kein Passwort? Wenn doch, wieso kennt er das noch, wenn ich doch das Konto gelöscht habe?

    Hast du das alles nach der offiziellen Anleitung gemacht (s. Online-Hilfe, Rubrik "Google-Kontakte synchronisieren")? Dann wurde in Google der Zugriff auf Google-Adressen aus TB! gespeichert. Wie es in der Anleitung steht, wird beim nächsten Mal automatisch synchronisiert, ohne dass man sich erneut anmelden muss.

    Genauso ist es, wenn man in den TB!-Kontoeigenschaften des GMail-Kontos als Authentifikation "OAuth" einstellt. Es wird dann nur einmal nach dem Passwort gefragt.


    Ich finde zwei Dateien mit ähnlichen Namen im Userordner: ADDRBOOK.ENI, ADDRBOOK.INI
    Was ist der Unterschied? Sie enthalten sehr ähnliche Inhalte, sind aber unterschiedlich alt.

    ENI ist die verschlüsselte Version von INI. Du musst also irgendwann OTFE (On-The-Fly-Encryption) in deiner TB!-Pro-Version eingeschaltet haben. Dann beginnen alle Dateierweiterungen mit einem E - MESSAGES.EBB statt MESSAGES.TBB usw. Wenn du jetzt OTFE nicht verwendest, kannst du solche Dateien löschen.


    Darin gibt es noch Verweise auf ehemalige Adressbücher, darf ich diese Verweise dort löschen?

    Im Abschnitt [Profile] kannst du die entsprechenden Zeilen entfernen.

  • Kannst du Nachrichten problemlos senden und empfangen? Geht's also nur um die Adressen?

    Ja, kann ich. Habe drei Mailkonten eingerichtet, und die funktionieren einwandfrei.
    Somit müsste die Meldung also mit dem inzwischen gelöschten Googlemail-Konto zusammengehangen haben?

    Versuchen sollte man es

    Werde es versuchen und Rückmeldung geben.

    Dann wurde in Google der Zugriff auf Google-Adressen aus TB! gespeichert

    Ja, so ist es, ich habe das explizit zugelassen und kann die Genehmigung auch in Google sehen.

    Danke soweit für die Hilfen!! Ich melde mich beizeiten zurück.

  • ENI ist die verschlüsselte Version von INI. Du musst also irgendwann OTFE (On-The-Fly-Encryption) in deiner TB!-Pro-Version eingeschaltet haben. Dann beginnen alle Dateierweiterungen mit einem E - MESSAGES.EBB statt MESSAGES.TBB usw. Wenn du jetzt OTFE nicht verwendest, kannst du solche Dateien löschen.

    Hmm, da stimmt irgendwas nicht: Ich habe keine OTFE eingeschaltet, ich benötige kein Passwort, um TB zu starten. Dennoch ignoriert er die ADDRBOOK.INI und schreibt seine Änderungen in die ADDRBOOK.ENI
    Gibt's dafür eine Erklärung?

  • Dennoch ignoriert er die ADDRBOOK.INI und schreibt seine Änderungen in die ADDRBOOK.ENI

    Ist denn ENI in deinem Fall eine lesbare Text-Datei wie die INI? Eine verschlüsselte Datei muss nämlich binär sein.

    Ansonsten musst du überprüfen, ob in der Registry unter "HKEY_CURRENT_USER\Software\RIT\The Bat!" der Wert "AddressBookProfilePath" auf INI oder ENI verweist.

  • Registry-Eintrag verweist auf ENI. Darf ich den einfach ändern? Und vorher aktuellen ENI-Inhalt in INI kopieren?

    TB! vollständig beenden, INI löschen, ENI in INI umbenennen, in der Registry drei Werte anpassen - AddressBookProfilePath, AddressBookProfilePath Unicode und AddressBookProfilePathRelative, da sie alle drei auf ADDRBOOK.* verweisen.

  • in der Registry drei Werte anpassen - AddressBookProfilePath, AddressBookProfilePath Unicode und AddressBookProfilePathRelative, da sie alle drei auf ADDRBOOK.* verweisen.

    Es gab nur den einen: AddressBookProfilePath Unicode

    Zum Versuch mit neuem Google-Konto:
    Das Synchrionisieren funktioniert hier, in beide Richtungen, mit 459 Datensätzen.
    Aber nach nur wenigen Versuchen bin ich erschüttert, wieviele Datenfelder falsch übertragen werden oder gar nicht, oder dupliziert oder überschrieben werden.

    Ich glaube, ich muss TB verlassen, so geht das nicht ... :(

  • Ich glaube, ich muss TB verlassen, so geht das nicht

    Entweder wechseln, falls dieses Feature für dich unabdingbar ist und du nicht warten kannst, oder du meldest deine Fehler an Ritlabs, damit sie behoben werden. Im letzteren Fall solltest du dich im BugTracker registrieren (s.o. Link). Einige der Probleme sind dort bereits gemeldet, so u.a. die duplizierten Einträge. Schreibe einfach CardDAV in das Suchfeld, schon wird dir angezeigt, was schon gemeldet wurde. Die Einträge solltest du bestätigen. Falls du ein Problem hast, das noch nicht gemeldet wurde, solltest du im BT dafür einen separaten Eintrag mit einer englischen Beschreibung und u.U. Screenshot(s) erstellen. Heute z.B. wurden einige Einträge einem Ritlabs-Mitarbeiter zugewiesen, was darauf hindeutet, dass sie demnächst behoben werden oder dass zumindest daran gearbeitet wird.

    Alternative Wege für die Kommunikation mit Ritlabs sind im Thread "Wie kann man Fehler oder Wünsche an Ritlabs weitergeben?" beschrieben.

  • Immer Bugs melden, je mehr desto besser, dann müssen sie schon was fixen, insbesondere weil Google Contacts nicht irgendein Wischiwaschi ist.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.