Beiträge von Papierflieger

Zitat von Bastler

Aufgaben und Termine werden oft in einen Topf geworfen. Hier eine kurze Info, es gibt im Netz noch mehr davon.

Meine Rede anno 1875...

Ich habe noch etwas getestet und folgendes herausgefunden:

So speichert eine Android Kalender-Anwendung eine "ganztägige" Aufgabe:

DUE;VALUE=DATE:20230513

Und so TB:

DUE;TZID=Europe/Berlin:20230513T000000

Ersetze ich in der exportierten ICS die zweite Schreibweise durch die erste, wird auch dieses Aufgabe nach dem Re-Import sowohl in TB als auch nach der Synchronisation auf Android als "ganztägig" angezeigt und so behandelt.

Danke für die Arbeit! Allerdings ist es wohl nur ein Placebo, wie Bastler schon sagte: im Anhang ist der Unterschied zu sehen zwischen einer "ganztägigen" Aufgabe, wie sie in anderen Kalenderanwendungen¹ angelegt werden kann, und wie TB sie erlaubt. Der Unterschied ist der, daß "ganztägige" Aufgaben keine Zeitangabe besitzen, weil sie eben nicht an eine bestimmte Uhrzeit, sondern nur an einen bestimmten Tag, an eine bestimmte Woche oder Monat gebunden sind. Beispiele:

- Irgendwann im Laufe des Tages muss ich Brot kaufen. Wann, ist egal.

- Irgendwann im Laufe diese Woche muss ich die Steuererklärung machen.

Bei solchen Aufgaben eine Uhrzeit anzuzeigen, ist nicht korrekt, und kann u.U. sogar dazu führen, daß per CalDAV synchronisierte Aufgaben um Mitternacht auf Android einen Alarm bimmeln lassen, weil der Kalender eine fällige Aufgabe um 0:00 Uhr sieht.

____

¹ Z.b. in Evolution, Korganizor, Android, Web-Kalender, u.v.a.m.

Wenn Du in Lightning eine "neue Aufgabe" erstellst (NICHT Termin!), fehlt das Kästchen zum Ankreuzen "ganztägig", wie es auch bei Terminen möglich ist. Diese Einstellung "ganztägig" für Aufgaben ist nötig, wenn Aufgaben eben nicht zu einem festen Zeitpunkt, sondern irgendwann im Laufe des Tages erledigt werden müssen.

Im Ersten Anhang siehst Du das Fenster zur Eingabe einer neuen Aufgabe, im zweiten Anhang das Fenster für einen neuen Termin. Beachte das fehlende "ganztägig" bei der Aufgabe. Der obige Code hatte in älteren TB-Version die erwünschte Wirkung, aber jetzt ist er leider wirkungslos geworden.

Zitat von jorgk3

Am besten ist es, das UI mit dem sog. Inspector anzusehen, dann siehst Du, welches CSS geändert werden muss...

Das Werkzeug habe ich noch nie benutzt, und ich kenne mich mit dem CSS auch nicht wirklich aus. Aber wenn Du schreibst, ich solle die GUI mit dem Werkzeug ansehen: wie kann das Werkzeug etwas inspizieren, das nicht angezeigt wird? Das Problem ist, daß TB bzw Lightning die Option "ganztägig" bei Aufgaben nicht anzeigt. Dadurch gibt es da auch nichts zu inspizieren.

Moin!

Ich hatte vor einiger Zeit diesen Eintrag der userChrome.css hinzugefügt, um auch bei Aufgaben(!) die Option "gänztägig" ankreuzen zu können:

#event-all-day[class="event-only"] {

display: block ! important;

}

Jetzt muss ich feststellen, daß dieser Code in den aktuellen Versionen von Betterbird (und TB) wirkungslos ist, obwohl die nötige pref¹ auf "true" gesetzt ist. Ich vermute, die Syntax hat sich geändert. Kann mir jemand sagen, wie es jetzt richtig ist?

Danke im Voraus!

(¹ toolkit.legacyUserProfileCustomizations.stylesheets)

Freut mich, daß es jetzt bei dir auch funktioniert!

Ja, ich vergaß zu erwähnen, daß du das alte PW im TB noch löschen musst. Mea culpa!

Aber wie du schon gemerkt haben dürftest, hat der TB eindeutig noch weitere Macken. Aber wenn es nach den Entwicklern geht, ist er natürlich perfekt...

Übrigens: die aktuelle Version von Nextcloud ist 20.0.5. Solltest du aktualisieren bzw aktuell halten, falls noch nicht geschehen.

Hallo Leidensgenosse!

Das mit den App-PW geht wie folgt:

Melde dich in der GUI deiner NC an, klicke danach auf den Buchstaben oben rechts, den dem ersten Buchstaben deines Anmeldenamens entspricht. Dort wählst du "Einstellungen", und dann im linken Teilfenster "Sicherheit".

Danach findest du rechts am Ende der Seite eine Option "Neues App-PW erstellen". Dieses dort erzeugte Paar von PW + Benutzernamen gibst du anschließend bei Lightning an, wenn er dich nach der Berechtigung für NC fragt. Genauso verfährst du mit anderen Apps, die sich mit deiner NC synchronisieren sollen, z.B. dein Taschen-Androide, aber auch Apps, die z.B. per WebDAV auf Dateien zugreifen wollen, wie ein Dateimanager. Wichtig ist dabei, dass du wie oben beschrieben, zuerst in der Ziel-App, z.B. Lightning, den Kalender einmal kündigst, und dann mit dem neuen PW+Name wieder abonnierst.

Wenn du nicht klar kommst, frag gerne noch weiter nach.

Zitat von Sehvornix

Ok, verstehe. Dann solltest Du aber spätestens jetzt überlegen, Dich von freenet (und gmx) zu trennen. Konfiguration nach Privacy Handbuch und Wahl eines Mail-Providers wie freenet und gmx vertragen sich meiner Meinung nach vom Ansatz her nicht.

Keine Sorge: die wichtigen Mails sind natürlich stets mit PGP verschlüsselt.

Ok, zum Schluss noch der Schenkelklopfer des Tages:

Gerade bekam ich eine Antwort vom "Kundenservice" von Freenet, denen ich das Problem schilderte. Hier meine Anfrage:

Zitat

Sehr geehrte Damen und Herren,

Seit einigen Tagen kann ich mit Thunderbird keine Nachrichten mehr versenden. Beim Klick auf Versenden

erscheint die Meldung:

"Fehler beim Senden der Nachricht: SMTP-Server-Fehler. Der Mail-Server antwortete: IP Literal in greeting."

Dieser Fehler erscheint nur, wenn ich die Konten mit TB verwende, andere Mailclients sind nicht betroffen. Die Kontoeinstellungen und Passwörter wurden seit dem letzten funktionierenden Versenden von Mails von mir nicht geändert.

Was soll mir diese Meldung sagen, wieso tritt sie nur in TB auf und was kann ich dagegen tun?

Danke im Voraus!

Mit freundlichen Grüßen,

Alles anzeigen

Eigentlich eine recht deutliche und eindeutige Beschreibung des Problems.

Und hier die Antwort von Freenet:

Zitat

Sehr geehrter Herr...

vielen Dank für Ihre Anfrage.

Ihr E-Mail-Postfach ist jetzt wieder für SMTP freigeschaltet. Sie können jetzt Ihre E-Mails wieder mit einem E-Mail-Programm versenden. Die Sperre erfolgte aus Sicherheitsgründen, da festgestellt wurde, dass über Ihren Account eine Vielzahl von E-Mails gleichen Inhalts versendet wurde.

Sollte der Versand dieser Spam-E-Mails ohne Ihr Wissen erfolgt sein, so kann ein Fremdzugriff vorliegen.

...

Mit freundlichen Grüßen

Ihr freenet Team

Alles anzeigen

Das würde aber bedeuten, daß dieser unerlaubte Versand bei zwei Anbietern gleichzeitig stattgefunden hat, und es müsste vor allem bedeuteten, dass ich auch mit anderen Mailclients keine Nachrichten verschicken könnte. Aber, wie oben betont, war nur der TB betroffen.

Fazit:

Freenet: setzen, 6 minus!

Zitat von Sehvornix

Hallo Papierflieger,

Diesen Parameter gibt es bei zwei Installationen, 1 x unter Windows, 1 x unter Ubuntu, hier bei mir nicht. Hattest Du mal Spamihilator oder eine ähnliche Lösung eingesetzt?

Nein, nichts dergleichen. Spamfilterung überlasse ich TB und den Filtern meines Anbieters.

Was den fehlenden Parameter angeht: der ist auf nicht auf allen automatisch System gesetzt, siehe z.B. hier, kann und sollte aber nachträglich gesetzt werden.

Zitat von Thunder

Wenn ich das Thema nach ein Wenig Suche im Netz richtig verstehe, dient die Zeile/Einstellung der Verschleierung der eigenen IP-Adresse beim Senden von Mails?

Ja, richtig. Informationen über den Aufbau eines internen Netzes sollte möglichst auch intern bleiben. Die Bekanntgabe der IP im Intranet kann u.U. schon eine Sicherheitslücke darstellen.

Gelöst!

"mail.smtpserver.default.hello_argument" war auf "127.0.0.1" gesetzt. Nach der Änderung in "localhost" klappt der Versand wieder.

Jetzt wüsste ich nur zu gerne, ob und wann der Wert bei mir geändert wurde, oder ob beide Mail-Anbieter ziemlich gleichzeitig dieselbe Änderung an ihren System vollzogen haben. Wenn sie beide denselben MTA benutzen, und dieser aktualisiert wurde, wäre das eine Erklärung.

Alles korrekt eingestellt. Wie gesagt: vor ein paar Tagen lief es noch normal, und seit dem gab es keine Änderung an meinem System und auch nicht an meinem TB.

Nachtrag:

Ich habe jetzt den ältesten Stand des Verzeichnisses ~/.thunderbird aus einem Backup wieder eingespielt, der vor dem Zeitpunkt erstellt wurde, als ich noch Nachrichten versenden konnte. Die Fehlermeldung bleibt aber.

Nachtrag 2:

In VirtualBox ein Live-System gestartet, TB mit exakt denselben Konto-Daten eingerichtet - läuft! Keine Fehlermeldung beim Versenden.

Der Unterschied zwischen dem virtuellen und meinem normalen TB: in der VBox war es TB 60.9, im richtigen System TB 68.8

Mein Tablet z.B. ist im selben Netz unterwegs wie mein PC, benutzt also denselben Router, denselben DNS, eine IP aus demselben Netz. Trotzdem kann der ohne Probleme Nachrichten versenden.

Ich stelle übrigens fest, dass außer freenet auch gmx betroffen ist. Die gehören doch beide zusammen, oder? Haben die wieder undokumentierte Änderungen vorgenommen? Im Netz finde ich leider nichts dazu.

Hallo!

Als ich eben mit TB (68.8.0/64 Linux) über Freenet.de eine Mail versenden wollte, erhielt ich diese Fehlermeldung:

Zitat

Fehler beim Senden der Nachricht: SMTP-Server-Fehler. Der Mail-Server antwortete: IP Literal in greeting.

Diese Meldung habe ich noch nie gesehen.

Das Konto ist aktiv, ich benutze es auch von meinem Taschen-Androiden, und dort gibt es nach wie vor keine Fehlermeldung, Nachrichten werden immer noch ohne Murren verschickt. Die SMTP-Einstellungen zum Versenden habe ich bis auf jeden i-Punkt zwischen Android und TB verglichen, es gibt keine Unterschiede. Außerdem habe ich an keinem der Systeme seit Monaten etwas verändert.

Was also soll mir diese Fehlermeldung sagen? Und wie behebe ich diesen Fehler?

Zitat von sw2412

Hallo,

ich kann diese Verzögerungen eindeutig bestätigen.
Habe bereits zig Konfigurationen getestet,

Hast du auch schon die oben beschriebene "Lösung" mit dem App-Passwort versucht?

Zitat von Kalle73kw

Die AppPasswörter hab ich gefunden, hat aber nichts geholfen.

Wenn du für den TB/Lightning ein App-PW vergibst, musst du zuvor in Lightning den oder die Kalender einmal abbestellen. Dann vergibst du das App-PW, anschließend abonnierst du den/die Kalender erneut, dieses mal aber mit dem eben vergebenen PW statt des PW für die GUI.

Ich bin auf diese Lösung (sofern es denn eine sein soll) nur durch Zufall gekommen, weil ich gesehen hatte, daß ich zwar für jeden meiner Androiden bereits ein App-PW vergeben hatte, nicht aber für TB. Das wollte ich einfach nur nachholen. Danach habe ich versehentlich den "falschen" TB gestartet, nämlich die Version 68. Eigentlich wollte ich den 60er starten, aber weil die Verzögerungen nicht auftraten, habe ich erst später am Aussehen bemerkt, daß ich den 68er gestartet hatte.

Hoppla!

Ich glaube, ich bin soeben zufällig auf die Lösung des Problems gestoßen:

ich habe in der Web-GUI der NC für den TB 68 ein eigenes App-Passwort generiert. Bisher habe ich beim Abonnieren der Kalender stets mein Web-PW angegeben, so, wie ich es seit Jahren gewohnt bin. Seit TB68 das eigene App-PW benutzt, sind die Verzögerungen weg: neue Termine sind fast sofort sichtbar, gelöschte Termine verschwinden fast sofort.

Kann das bitte jemand von den anderen Betroffenen gegenprüfen?

SSL-Mailer: interessant... Was macht Windows und dein externer Anbieter denn wohl anders?

Hast du Shell-Zugriff zu deinem Server? Wenn ja: könntest du dich mal anmelden und das Log von mysql mitlesen, während du einen Termin in TB eingibst und schauen, ob "PUT" und "REPORT" sofort ausgeführt werden?

Nur, um auszuschließen, daß es irgend ein Caching in Windows gibt, daß die sofortige Abarbeitung des Befehls vorgaukelt.

Hallo SimBeam!

Habe mir gerade mal den TB 75b geladen, aber die oben beschriebene Verzögerung ist immer noch drin.

Aaaaber ich habe noch etwas herausgefunden: zur Kontrolle habe ich auf meinem Arbeitsrechner eine lokale Nextcloud als Snap-Paket installiert und den TB 68 darauf einen Kalender nutzen lassen. Und hier gibt es keine Verzögerung. Sofort nach dem Klick "Speichern" ist der Termin sichtbar.

Daraufhin habe ich nach Unterschieden in den Konfigurationsdateien des ganz oben beschriebenen Servers und den entsprechenden Dateien im Snap-Paket. Die Konfiguration von NC und von MySQL ist identisch, aber das Snap-Paket nutzt Apache statt Nginx.

Am nächsten verregneten Wochenende werde ich ausprobieren, was passiert, wenn ich das Snap-Paket "Nextcloud" auf demselben Server wie oben beschrieben laufen lasse. Mit einem anderen Port sollte der gleichzeitige Betrieb von Nginx und Apache möglich sein, und da das Snap-Paket auch eine eigene MySQL-DB mitbringt, gibt es da auch keine Beeinflussung. Irgendwie bin ich schon auf das Ergebnis gespannt.