Beiträge von jobisoft

Für 2024 ist geplant, die Message Database neu zu machen, dann sollte auch die Suche besser werden.

Zitat von Zitronella

ähnlicher Thread: GMX.de Sicherheits Hinweis ??? / und dort verwies ich schon auf den Thread im Forum https://www.computerbase.de/forum/threads/…inweis.2168153/ in dem in letzter Zeit einige interessante Posts dazu kamen

Oh, der Thread da behandelt den genau gleichen Fall wie bei mir. Dann können wir den Faden hier als Dopplung zu machen.

Was ich mitnehme:
* das Auswahlkiterium scheint nicht der POP-Abruf zu sein, sondern reiner Zufall
* ich bin nicht allein, aber es ist nur eine kleine Nutzergruppe betroffen
* GMX kommuniziert das auf ihren offiziellen Kanälen überhaupt nicht
* GMX Support bestätigt das Vorgehen aber

Zitat von Bastler

Ich verstehe den Habau dieses Threads nicht. Als GMX'ler würde ich zuerst auf der Seite des Anbieters schauen.

Der Habau dieses Threads ist: GMX schaltet immer wieder (derzeit alle 4 Wochen) den IMAP/POP Zugang ab, obwohl das Konto täglich über Thunderbird abgerufen wird. Die Infos auf der von dir verlinkten Seite sind wenig hilfreich. Dass ich das da im GMX Web-Interface wieder anschalten kann, ist mir klar und bekannt.

Wie im Eingangsposting aufgeführt, wollte ich mal hören, ob es anderen auch so geht.

Inzwischen habe ich übrigends die Vermutung, dass ein Unterschied zu den anderen Nutzen ist, dass wir wirklich noch über POP abgerufen haben. Hab jetzt mal auf IMAP umgestellt und warte was passiert.

Zitat von A.Koch

Leute, ist das wirklich von gmx oder eine Phishingmail?

Das ist echt.

Weil ich auf den Seiten von GMX nichts Konkretes zu einer ständigen Abschaltung alle 4 Wochen finden konnte, habe ich mich ja an den Support gewendet und dort mit einem echten Mitarbeiter von GMX kommuniziert.

(Zuerst hat man bei dem Chat nur einen bot, wenn man aber schreibt "Das hat nicht geholfen", dann bekommt man echten Kontakt).

Zitat

Einen Euro (zur Not 2€) wärs mir das allemale wert ...

Das stimmt allerdings, wir zahlen derzeit ja nix dafür.

Durch die negative Erfahrung dieser idiotischen Zwangsdeaktivierung kann es aber u.U. passieren, dass wir eher zu einem anderen kostenpflichtigen Anbieter wechseln, als bei GMX zu bleiben und das Konto hochzustufen. *kopfschüttel*

Ich hatte heute einen eigenartigen Kontakt mit der Chat-Mitarbeiter-Hilfe von GMX. Hier die ursächliche E-mail, die mein Schwiegervater heute bekommen hat:

Zitat

Betreff: Abschaltung POP/IMAP zum 09.01.2024

Hallo Herr XXXX,
wir hatten Sie darüber informiert, dass Sie für die weitere Nutzung der
POP3/IMAP-Protokolle beim Zugriff auf Ihre GMX E-Mails aus
Sicherheitsgründen in der GMX Mail App angemeldet sein müssen.

Leider sind Sie in der GMX Mail App nicht angemeldet, weshalb Ihr POP3/
IMAP Zugriff in den nächsten Tagen erneut deaktiviert wird. Wir weisen
Sie darauf hin, dass künftige Abschaltungen auch ohne weiteren Hinweis
erfolgen können, sofern wir keine Anmeldung in der App feststellen können.

Alles anzeigen

Mein Schwiegervater hat kein Smartphone und kann daher die APP nicht installieren. Das habe ich versucht dem GMX Mitarbeiter zu erklären. Er meinte aber "Das sei jetzt eine neue Sicherheitsrichtlinie" und da kann man keine Ausnahmen machen.

Auf meine Frage, welchen Sicherheitsgewinn es hat, dass mein Schwiegervater sich alle paar Wochen im Portal anmelden muss, um den POP/IMAP Zugang wieder zu aktivieren, hatte er leider keine passende Antwort.

Gibt es hier noch andere betroffene Nutzer?
Machen das auch andere Anbieter?
Hat jemand eine plausible Erklärung?

Ich bin ehrlich gesagt ziemlich sprachlos, warum GMX als einer der großen Anbieter in Deutschland, sich zu so einer Aktion hat bewegen lassen, die potenziell viele Tausend Thunderbird Nutzer beeinträchtigen kann/wird (falls man die GMX App nicht installieren kann/will).

Edit: Das Postfach wird täglich abgerufen. Es handelt sich also nicht um eine Abschaltung wegen Nichtnutzung, sondern um einen Zwang zur Installation der APP.

Das hatte jemand in meiner Familie auch.

Lösung:
Im GMX Portal anmelden und IMAP/POP Zugang erneut aktivieren. Nicht wundern, ihr werden dabei neue AGBs akzeptieren müssen. Und das ist der eigentliche Grund, warum die das gemacht haben.

Hintergrund:
In den letzten Wochen hatte GMX immer wieder Emails geschrieben, dass zum 27.11 den Zugang über Programme wie Outlook und Thunderbird gesperrt wird, wenn nicht auch auf einem Smartphone die GMX APP installiert ist. Auch hier ging es einzig und allein darum, beim Installieren der App die Zustimmung zu den neuen AGBs einzuholen.

Wir haben das nicht gemacht und geschaut was passiert. Am 29.11 (oder so) ging dann Thunderbird nicht mehr. Nach dem Anmelden am Portal (und Akzeptieren der AGBs) haben wir weitere Emails gefunden, die behaupten, IMAP/POP wurde deaktiviert, weil wir es so selten benutzen. Totaler Käse. Die Person prüft mindestens 2x am Tag seine Mails über Thunderbird.

Nach dem erneuten Aktivieren der IMAP/POP Funktion in den GMX Einstellungen, geht wieder alles.

Das war eine sehr bekloppte Aktion von GMX. Aber da wir nix bezahlen, muss man das wohl hinnehmen.

Zitat von Elmwork

Das mit dem Hinterlegen auf dem Server hat den Vorteil, dass ich nun den gleichen html Code bei allen Mitarbeitern in TB einfügen kann, und wenn das Logo irgendwann schöner wird, dann ist das Ändern kein Ding.

Das Einbinden von Bildern via URL kann von den Empfängern als tracking interpretiert werden und wird daher auch von manchem MailServer als SPAM deklariert.

Ja, es gab ein Problem mit Zeilenumbruch. Derzeit gibt es eine Beta-Version von Quicktext. Guck mal hier:
https://github.com/jobisoft/quick…ment-1701232040

Beseitigt diese Version das Problem?

Fixed.

Ja, die gesamte mail3pane ist doch jetzt anders. Dein target ist nicht mehr in messenger.xhtml sondern in about:message. Ich denke du musst

let window = event.target.ownerGlobal.top;

nehmen, um an das tabmail zu kommen.

Das ist der code, den ich benutze:

https://webextension-api.thunderbird.net/en/stable/how-…abs-and-windows

Welchen benutzt du (der nicht geht)?

Kann natürlich auch sein, dass dein Input falsch ist und daher eine falsche id ausgespuckt wird.

Ich bin jetzt eine Woche in Kanada, sobald ich zurück bin, schaue ich mir das an! Evtl schonmal releasen mit Hinweis auf feature-incomplete?

Zitat von schlingo

Danke für Deine Mühe Dann kann/soll ich das jetzt auch so lassen, richtig?

Ja, ich werde TbSync v4.6 in den nächsten Tagen wieder für TB102 freischalten. Ich warte aber noch, evtl kommt von dir ja noch problematisches Feedback

Zitat von schlingo

Ich habe da noch eine Frage: bei der Recherche habe ich gesehen, dass die letzte Version des Providers für EAS auf ATN die 4.3 ist. Ich habe hier eine Version 4.4, die am 22.03.2023 installiert wurde. Woher kommt die? Ich habe da nichts manuell installiert.

Die hatte das gleiche Problem wie v4.6 und ich habe sie komplett gelöscht. v4.6 habe ich nur auf TB115 beschränkt. Jetzt sind aber auch die Provider durchs review durch und nun sollte TbSync v4.6 auch wieder mit TB102 und den neuen Providern funktionieren. Kannst das mal ausprobieren?

1. Provider auf die neue v4.7 aktualisieren und "normal" mit TbSync v4.3 laufen lassen, sollte gehen
2. Händisch TbSync v4.6 runterladen und installieren (hat im manifest noch 102 stehen), sollte auch gehen

https://addons.thunderbird.net/de/thunderbird…bsync/versions/

Das ist doof. Sorry.

Die neue Version von TbSync braucht auch die neuen Versionen der Provider, aber die hängen noch im Review (ich darf meine eigenen Add-ons nicht reviewen). Lade dir TbSync v4.3 runter und installiere es drüber. Ich habe inzwischen eingestellt, dass 102.* user die neue Version von TbSync nicht mehr angeboten wird.

Du kannst den Button ja enabled lassen, und trotzdem das flag benutzen, um unerwünschte Klicks zu unterbinden. Wenn die Situation nach dem reload wieder "sauber" ist, kannst du den Button für den Rückweg zum "Reintext" wieder aktivieren.

Lass uns zuerst das Button-mehrfach-Klicken Problem lösen. Du sagst, es trifft auch in diesem "guten aber nicht vollständigen" Entwicklungsstand auf? https://gitlab.com/ThunderbirdMai…step-2023-08-17

Ich kann das Problem zunächst nicht nachstellen, aber wahrscheinlich gibt es einen edge-case, den ich noch nicht erwischt habe. Ich würde vorschlagen erstmal mit dem "guten aber nicht vollständigen" Entwicklungsstand weiterzumachen:

* die Aufrufe zum disable des Buttons erfolgen sehr spät: Maßnahme #1 ist ein acceptButtonClicks flag, das gesetzt werden muss, bevor der Button was tut (egal ob er enabled oder disabled ist)
* ich würde das flag am Ende des onMessageDisplayed listeners auf true setzen (unabhängig vom Button disable/enable status).
* Ich würde das flag in einer globalen Map (tabId->status) speichern und es auch auf false setzen, bevor wir den reload triggern (eigentlich direkt am Anfanf des onClicked listeners), sodass wir ganz klar die Funktion des Buttons in den problematischen Zeiträumen deaktivieren.
* im onClicked listener prüfst du das flag und machst ein early exit, wenn es nicht existiert oder flase ist: if (!acceptButtonClicks.get(tab.id)) { return; } funktioniert in beiden Fällen.

Das hat zur Folge, dass der User bei diesen edge-cases zwar u.U. einen aktiven Button hat (der durch das timing issue noch nicht deaktiviert wurde), aber der Klick wird ignoriert. Wie klingt das?

ne, ich mache gerade was anderes.:-)

Die registerlistener funktion in update_ui hatte ich wieder auf den ursprünglichen Inhalt zurückgeführt, aber den Aufruf auskommentiert. Ich wollte das diff gegenüber der 8.1.5 so klein wie möglich halten.

Ich würde an deiner Stelle glaube ich nur das Prinzip meine geänderte Logik übernehmen, aber nicht ganze Dateien von 8.4 1-zu-1 kopieren. Das hilft auch den code zu verstehen:-)

Wenn du nicht weiterkommt, dann sag bescheid und ich probiere dann einen MergeRequest gegen dein Repo.

Thunder : Hast du eigentlich ein github repo für AHT? Da wäre das gemeinsame Arbeiten einfacher. Hier ist Version 8.4:
allow_html_temp-8.4.xpi

Ich habe gemerkt, dass es invalide Button enable/disable Zustände geben kann, wenn die Optionen oder die Thunderbird-Einstellung im Menü geändert wird. Außerdem habe ich gemerkt, dass die event listener in update_ui.js teilweise gegen die event listener im background agieren. In v8.4 habe ich daher das Anzeigen der Message als den primären Aktivitätsvektor von AHT definiert und lade alle Nachrichten neu, wenn eine der möglichen Einstellungen geändert wird. Die event listener in update_ui.js habe ich deaktiviert bzw. ins background überführt. Wo die sind, ist primär egal, es sollte aber nicht 2 Orte dafür geben (mein Fehler).

Außerdem:

• Wenn der Button gedrückt wurde, ist die AHT Funktion ja getriggered worden und nochmaliges drücken hätte keinen Effekt mehr -> Ist jetzt einfach disabled. Ich vermute, das war früher auch so, ist aber durch das neue Konzept abhanden gekommen.
• Wenn das Drücken des Buttons generell keinen Effekt hat, weil die aktuelle Einstellung (z.B. Plaintext) die gleiche ist wie die Button-Einstellung (ebenfalls Plaintext), dann ist der Button ebenfalls disabled.