Beiträge von sanyok

Zitat von GwenDragon

Wie es The Bat! beim Versenden bei Dateinamen macht, ist ja weniger relevant weil nicht viele Leute The Bat! als Client nutzen.

Wie gesagt, ich habe es mit verschiedenen Methoden getestet und mit keiner gab es Schwierigkeiten.

Ich bekomme auch oft Nachrichten mit Anhängen mit Nicht-ASCII Zeichen, erstellt mit Outlook, WLM, Thunderbird, Webmailern und verschiedenen Handy Apps. Mir wäre es längst aufgefallen, wenn damit etwas nicht stimmen würde. Offensichtlich besteht aber dieses Problem nur mit Vivaldi Mail. Wenn du das Programm hast, dann kannst du nachschauen, ob es dort irgendwo eine Einstellung in Bezug auf die Kodierung von Anhängen gibt.

Zitat von GwenDragon

Aber Thunderbird macht mit derselben Methode wie Vivaldi Mail mit dem Splitten der Namen und Nicht-ASCII-Zeichen!

Nicht immer. Es hängt wohl von der Länge des Dateinamens ab. Benenne den Anhang in ÄÖÜ.rar um. Dann wirst du wahrscheinlich auch nur eine Zeile sehen.

Entscheidend ist aber wohl nicht der Umbruch, da Thunderbird-Nachrichten mit Umbruch in TB! korrekt dargestellt werden, was wahrscheinlich auch du festgestellt hast, sondern zusätzlich die richtige Kodierung.

Dass andere MUAs solche Nachrichten richtig anzeigen, liegt eventuell daran, dass sie nicht darauf achten, welche Kodierung im Quelltext angegeben ist, sondern sie selbst überprüfen und richtig erkennen. Und TB! tut das halt nicht. Daher hat Stefan in TBBETA geschrieben, dass sie den Parser anpassen müssen, was dauern wird.

Das erinnert mich an einige Browser, die zumindest früher immer strikt darauf achteten, welche Kodierung im Header der Webseite bzw. der Haupt-HTML-Datei angegeben wurde, und immer nur diese einschalteten. Also z.B. wenn dort das stand

<meta http-equiv="content-type" content="text/html; charset=utf-8">

dann wurde sofort UTF-8 aktiviert. War aber der Webseitentext in Wirklichkeit nicht als UTF-8 kodiert, gab es ein Kauderwelsch und man musste immer manuell umschalten. Manche Browser haben aber hingegen den Text selbst analysiert und wählten dann auch die passende Kodierung. So etwas Ähnliches haben wir wohl auch hier.

Jedenfalls kann es nicht dem Empfänger angelastet werden, wenn der Versender nicht richtig verschlüsselt.

So, ein weiterer Test bestätigt es. Vivaldi Mail kodiert nicht mit UTF-8, sondern verwendet das sog. URL-Encoding. Damit werden in einigen Browsern Links mit Nicht-ASCII Zeichen kodiert.

Wenn man z.B. auf https://www.urldecoder.io/ den Text

%C3%84%C3%96%C3%9C%20HTML-Dokument%20(2).html.rar

eingibt, erscheint nach der Entschlüsselung der richtige Dateiname

ÄÖÜ HTML-Dokument (2).html.rar

Wer Notepad++ nutzt, kann es auch dort unter Plugins mit MIME Tools testen.

Wenn ein Programm etwas falsch verschlüsselt, kann man von einem anderen Programm nicht erwarten, dass es richtig entschlüsselt.

Ich kann das zwar mit der o.g. Test-Nachricht bestätigen, aber mit meinen eigenen Tests nicht. Ich hab's von TB! zu TB!, von anderen Mail-Programmen zu TB! und auch von verschiedenen Webmailern zu TB! geschickt und alle Unicode- und Umlaut-Anhänge sind korrekt angekommen. Könnt ihr auch selbst testen.

Es liegt demnach definitiv am Vivaldi Mail. Man sieht auch anhand des Quelltextes, dass der Dateiname des Anhangs aus unverständlichen Gründen in mehrere Zeilen zerlegt wurde. Also anstelle von

Content-Disposition: attachment;
filename="utf-8''%C3%84%C3%96%C3%9C%20HTML-Dokument%20(2).html.rar"

steht dort

Content-Disposition: attachment;
 filename*0*=utf-8''%C3%84%C3%96%C3%9C%20HTML-Dokument%20(2).ht;
 filename*1*=ml.rar

Ob das jetzt so RFC-konform ist, müssen die Entwickler prüfen. Jedenfalls haben sie im Changelog zu v10.3.3.6 darauf hingewiesen, dass dieser Parameter zu lang ist, was wohl ungewöhnlich ist.

Edit::

Habe jetzt bemerkt, dass Thunderbird bei sehr langen Namen ebenfalls im Quelltext umbricht. Es sieht dann z.B. so aus:

Content-Disposition: attachment;
 filename*0*=UTF-8''...;
 filename*1*=...;
 filename*2*=...

Allerdings hat TB! mit solchen Anhängen keine Probleme. Es kann demnach nicht am zu lang kodierten Parameter liegen, sondern an etwas Anderem.

Es fällt z.B. auf, dass der Dateiname von Vivaldi Mail gar nicht kodiert wird, weil er im Klartext sichtbar ist, was ja eigentlich nicht sein darf. Es müsste nämlich so aussehen:

Content-Disposition: attachment; 
filename="=?UTF-8?B?QcOWw5wgKDIpLnJhcg==?="

Der gesamte Dateiname des Anhangs muss also für einen Menschen unleserlich sein.

Thunderbird verteilt zwar ebenfalls auf mehrere Zeilen, kodiert dann aber richtig. Vivaldi Mail scheint es aber nicht richtig zu machen. Vielleicht liegt es daran.

Beiträge löschen im BT können nur die BT-Mods.

Wenn man im Editor etwas fett formatiert, wird der HTML-Tag <b> ... </b> verwendet. Im aus einem anderen Programm eingefügten Text steht hingegen <strong> ... </strong>. Kann sein, dass der Befehl Formatierung löschen damit nicht zurechtkommt, weil er programmiert ist, nur <b> zu entfernen.

Vielleicht wäre das etwas für einen Wish-Eintrag im BT.

Dieser Abschnitt ist wohl nicht im Editor von The Bat! erstellt und formatiert, sondern aus einem anderen Programm eingefügt worden.

Das ist also ein mit Formatierungen übernommener Text. Das merkt man auch daran, dass wenn man den nächsten Absatz nach der fetten Überschrift durch die Rücktaste nach oben schiebt, der ganze Absatz sofort fett wird, was bei internen Formatierungen nie passiert, weil sie immer wort- bzw. satzbezogen sind.

Jedenfalls sind das nicht die Formatierungen von The Bat! Daher können sie auch nicht rückgängig gemacht werden.

Wenn man z.B. diesen kopierten Text in The Bat! formatiert, kann man diese internen Formatierungen wiederum durch den obigen Befehl entfernen.

Edit:

Als Workaround bei solchen kopierten Texten kann man den Editor-Modus von HTML in Nur-Text wechseln. Dann gehen alle Formatierungen automatisch verloren. Wechselt man wieder zu HTML, bleibt der Text ohne Formatierungen.

Das hängt von der in den Kontoeigenschaften unter Erweitert gewählten Option ab. Wenn z.B. die erste eingestellt ist, dann wird auch nur beim Programmstart verbunden.

Kannst du die Nachricht hier als .eml anhängen? Vorher persönliche Daten entfernen.

Dann bitte das Thema als erledigt markieren, indem man oben auf Unerledigt doppelklickt.

Welche Optionen hast du bei der Ordnerwartung aktiviert? Vielleicht zuerst nur mit der Reparatur versuchen und auch nur das Konto oder den Ordner wählen, bei dem es hängenbleibt.

Und wenn es um IMAP-Ordner geht, dann sollte man zuerst die Verbindung zum Server trennen.

Dazu muss man zuerst den formatierten oder den gesamten Text markieren.

Ich verfasse auch keine HTML-Nachrichten, aber die Farben werden viel öfter im Editor geändert als in den Benutzereinstellungen.

Punkt ist aber (erneut), dass es in The Bat! keine Einheitlichkeit insoweit gibt - hier hat man eine umfangreiche Farbpalette, dort eine verkürzte und wiederum an dritter Stelle muss man die Farbe aus einer Dropdown-Liste mit Namen wählen. Und das war auch in den Vorgängerversionen so. Und solange es so bleibt, kann man mit verschiedenen Veränderungen rechnen.

Zitat von de-bugger

das stimmt so nicht!

Ich meinte, wenn man eine HTML-Nachricht schreibt und dort auf Schriftfarbe oder Zeichenhintergrundfarbe klickt, hat man auch nur die Standardfarbpalette.

In den Benutzereinstellungen hat man doch die Farben einmal angepasst und sie bleiben ewig von Version zu Version. Beim Verfassen von neuen HTML-Nachrichten hingegen muss man u.U. jedes Mal auf die Farben zurückgreifen. Dort spielt es schon eine Rolle.

Zitat von de-bugger

Jetzt muss mann wieder rumtricksen und die Farbwerte manuell eingeben.

Man klickt auf Mehr Farben... und hat die dann doch im nächsten Fenster, wo man übrigens u.a. auch manuell die RGB-Werte eingeben kann, wodurch man einen viel präzisieren Ton erhalten kann, wenn es keine Standardfarbe sein soll. Ich habe daher immer dieses Fenster benutzt.

Außerdem hängt's davon ab, um welche Farben es geht. Bei den Schrift- sowie Zeichenhintergrundfarben z.B. hat sich insoweit nichts geändert. Die zusätzliche Palette fehlte dort auch schon in v9. In Bezug auf die Farben gab es also noch nie eine Einheitlichkeit im Programm.

Jemand hat sich in der TBBETA-Mailingliste darüber beschwert, dass in The Bat! v10 die Abholung von neuen Nachrichten viel langsamer geschieht als in v9. Da er u.a. ASS einsetzt, hat er sich wohl auch an die Plugin-Entwickler gewandt und bekam von ihnen einen Ratschlag, der geholfen hat.

Wer also ähnliche Probleme hat, sollte in den Plugin-Einstellungen im Reiter Konten die Option oben Spam nach Nachrichtenheader automatisch beim Empfang blockieren deaktivieren, die aber sowieso standardmäßig deaktiviert sein müsste.

Nicht ganz klar ist nur, wieso diese Option in der Vorgängerversion nicht für die Langsamkeit gesorgt hat. Vielleicht hat er sie aber erst jetzt zufällig aktiviert.

Zitat von Frank

In den Unterorder "Usenet" werden serverseitig (mittels Filterregel) bestimmte Mails aus dem Posteingang dorthin verschoben.

Es besteht natürlich noch die Möglichkeit, lokal über The Bat! zu filtern. Lass die Nachrichten im EINGANG landen, wo neue Nachrichten natürlich immer abgefragt werden, und verschiebe sie erst danach in einen Unterordner. Das wird dann anschließend mit dem Server synchronisiert.

Ansonsten wartet bei eingeschaltetem IDLE das Programm auf eine Benachrichtigung vom Mailserver und tut also solange selbst nichts. Bei ausgeschaltetem IDLE hingegen sendet das Programm seinerseits in regelmäßigen Abständen Abfragen an den Mailserver. Schaltet man IDLE ein, sollte man auch die Option mit 30sek. einschalten, da viele Mailserver die Verbindung bei langer Inaktivität trennen.

Ob IDLE von deinem IMAP-Server überhaupt unterstützt wird und ob es besser ist, es ein- oder auszuschalten, musst du selbst prüfen.

Übrigens, da die Option in The Bat! nicht anwenden heißt, muss sie aktiviert werden, wenn man IDLE nicht verwenden möchte, und entsprechend deaktiviert, wenn IDLE verwendet werden soll. Ist also etwas ungewöhnlich, da man normalerweise eine Option aktiviert, um eine Funktion verwenden zu können. Hier ist es aber umgekehrt.

Zitat von sun-man

Wo wird denn eigentlich der "Junk-Wert" hinterlegt?

Im ersten Reiter Statistik kann man auf die Schaltfläche Log anzeigen klicken und sich anschauen, wie jede empfangene Nachricht klassifiziert wurde. Durch einen Doppelklick gelangt man zu Details jedes Eintrags. Dort steht eventuell mehr.

Zitat von sun-man

Bei mir wird quasi gar nichts gefiltert.

Die eigentlichen Einstellungen werden im zweiten Reiter Filter vorgenommen. Grundsätzlich kann man die Standardeinstellungen nehmen. Du solltest aber schauen, ob du nicht etwas anders haben willst. Dort kann man u.a. auch die White-/Black-Listen erstellen sowie die DNSBL und URIBL Server bestimmen.

Ansonsten muss man das Plug-in lehren, also Ham-/Spam-Datenbanken erstellen. Dafür markierst du eine oder mehrere Nachrichten und klickst in Menü Extras von The Bat! auf Als Junk klassifizieren bzw. Als Nicht-Junk klassifizieren. Mit der Zeit wird es dann selbst die Nachrichten richtig einstufen.

Zitat von sun-man

Oder muss ich alle Konten hier auch noch mit eintragen?

In diesem dritten Reiter trägt man nur dann Konten ein, wenn man möchte, dass bereits auf dem Mailserver gefiltert wird. Dann muss man natürlich alle eintragen, auf denen gefiltert werden soll. Will man das hingegen lokal erledigen, also nachdem die Nachricht empfangen wurde, braucht man dort gar keine Konten einzutragen.

Zum Plug-in gibt es übrigens eine gute Hilfe als .chm Datei oder auch in Online-Form, in der fast alles steht.

Das kann ich bestätigen. Allerdings steht darunter:

Zitat

Die Sprache der Suchanfrage wurde für die "Zeit" gewechselt.

Klickt man darauf, wird richtig nach dem Wort Zeit gesucht. Offensichtlich ist das Suche-Skript auf der Webseite im Standardzustand auf Russisch eingestellt. Das merkt man auch, wenn man nach manchen Wörtern mit Umlauten sucht. Daraus werden nämlich kyrillische Buchstaben und man sieht auch den gleichen Hinweis.

Zitat von heinzbeinz

War bei mir auch so...

Dann bestätige bitte den o.g. BT-Eintrag #0002232 (Anleitung unter "BugTracker-Verwendung").

Ich konnte jetzt keine Informationen darüber finden, dass OO ebenfalls CEF verwendet. Selbst aber wenn es so wäre, hätte es diesen Konflikt doch mit allen oder zumindest auch anderen CEF-Programmen geben müssen, was aber bisher nicht beobachtet wurde. Könnte es also vielleicht doch an 32-Bit liegen?