Inhalte auch Mails mit Filter matchen die Base64-Kodiert sind

    Hallo zusammen,

    seit heute verschickt auch PayPal die Email "verschlüsselt" mit Base64. Dies hat zur Folge das bestimmte Filter nicht greifen die nach Inhalten aus dem Contend suchen. Der Umweg nach einem Teil des bereits verschlüsselten Contends zu suchen hat bei mir leider nicht funktioniert. Dazu hatte ich den zu suchenden Bestandteil mit [1] ins Base64 konvertiert. I, Filter habe ich dann den Inhalt nach diesem String suchen lassen. Leider ohne Erfolg.

    Jemand eine Idee?

    Beste Grüße
    Janko

    [1] https://www.base64decode.org/
    * Thunderbird-Version: 45.3.0 (45.4.0 ist in den Ubuntu-Paketquellen noch nicht enthalten)
    * Betriebssystem + Version: Ubuntu 16.04.1 LTS (Xenial)
    * Kontenart (POP / IMAP): IMAP (Eigener Server)

    Hallo,

    das musst Du bitte genauer erklären. Base-64 ist keine Verschlüsselung sondern eine Kodierung von 8-Bit-Binärdateien in das 7-Bit-ASCII-Format von E-Mails zu ermöglichen. Anhänge in E-Mails werden stets Base-64 kodiert, weil man sie sonst nicht im 7-Bit-Format übertragen könnte.
    Vermutlich handelt es also um einen Anhang in der E-Mail.

    Gruß

    Susanne

    Hallo Susanne,

    zunächst danke für Deine Nachricht. Die Rede ist tatsächlich von einer Email ohne Anhang. Der HTML-Source wurde mit Base-64 kodiert. Das "Verschlüsselt" hatte ich deswegen oben auch in Anführungsstriche gesetzt, da es schließlich keine klassische erforderliche Kodierung ist wie man sie von Anhängen kennt :-)
    In meinem Fall geht es um die Zahlungs-Eingangs-Bestätigungen von PayPal. Bislang waren diese normale HTML-Mails und diese kommen seit gestern mit Base64 "verschlüsselt".

    Zwischenzeitlich scheint es sich aber erledigt zu haben. Ich hatte im Posteingang noch bewusst ein paar dieser Emails ungelesen liegen gelassen um mit dem Filter zu experimentieren zu können. Dabei hatte ich den neuen (Base-64-kodierten) Filter zum testen manuell auf den Posteingang angewendet. Ich kann es zwar nicht erklären, aber bei *neu* eingehenden Mails funktioniert der Filter jetzt wie erwartet. Auf bereits bestehende Mails nicht (aber das ist mir ehrlich gesagt auch egal).

    Das Problem scheint aber alles andere als neu zu sein. Bei meiner heutigen Suche bin ich auf einen Beitrag von 2010 gestoßen (base64, was ist das? [erl.]). An dieser Stelle mal ein Hoch auf das Forum. Schade, dass die Entwickler nichts von den tatsächlichen Problemen der User mitbekommen und diese dann abschalten.


    Beste Grüße
    Janko

    Hallo Janko,

    hast Du mal in den Quellcode geschaut, ob dort der Begriff "Attachment" auftaucht. Wenn das wirklich nicht der Fall ist, dann ist diese E-Mail meines Wissens nicht regelkonform.

    Zitat von Janko Hack

    Schade, dass die Entwickler nichts von den tatsächlichen Problemen der User mitbekommen und diese dann abschalten.

    Was meinst Du denn damit? Wie ich oben schon schrieb, müssen Anhänge in irgendeiner Form codiert werden, weil das ursprüngliche Format für E-Mails nunmal nur für ASCII-Zeichen, also 7 Bit, ausgelegt ist. Da beißt die Maus keinen Faden ab. Das können auch die Entwickler des TB nicht ändern. Siehe auch https://de.wikipedia.org/wiki/Base64

    Gruß

    Susanne

    Hallöchen Susanne!

    Zitat von SusiTux

    Das können auch die Entwickler des TB nicht ändern.

    Du kennst doch das alte Spiel:

    "Es sind immer diejenigen Schuld, welche sich an die Standards halten aber niemals jene, die sich den Standards verweigern!"


    Beispiel:

    • Eine Website geht nicht im Firefox? --> Mozilla ist garantiert schuld, auch wenn die Website ein paar hundert "Vääler" laut dem Validator hat!

    Traurig, aber leider immer noch wahr! :-(

    Hallo Susanne,

    wenn dem denn so wäre, würde ich Dir ja recht geben. Dem ist aber nicht so! Es ist tatsächlich nur der HTML-Source vom Contend der Base64.Kodiert wird (Content-Transfer-Encoding: base64). Wie ich bereits geschrieben habe, ist die Email ohne Anhang (Nein, auch der Begriff "Attachement" taucht dann natürlich auch nicht im Source der Email auf). Bitte versuche Dir vorzustellen, dass ich mir bewusst bin was ich schreibe und voll zurechnungsfähig bin :-)

    Meine Kritik an die Entwickler ist meiner Meinung nach berechtigt. Das Problem besteht ja offensichtlich seit Jahren. Es wäre doch bestenfalls ein Zweizeiler den Filterbegriff auf den tatsächlichen (encodierten) Inhalt zu beziehen. Offensichtlich scheint es ja hier mit der Erkennung ja kein Problem zu geben, sonst würde der Contend ja nicht richtig als HTML-Mail angezeigt werden.

    Beste Grüße
    Janko

    Zitat von TmoWizard

    Eine Website geht nicht im Firefox? --> Mozilla ist garantiert schuld


    Hallo TmoWizard,

    Das Beispiel hinkt etwas. Wenn es nicht Regelkonform ist den HTML-Contend mit Base64 zu dekodieren, dann sehe ich keinen Sinn darin den Contend zu encoden und dann richtig als HTML-Contend zu präsentieren (So wie TB es ja auch macht). Wenn man dann schon ohnehin den Condend encoded, ist eine NICHT-Anweldung des Filter aus den Encodeten Teil nur noch ein Bug!
    BTW: FF ist sicherlich kein Waisenknabe und gewiss nicht immer unschuldig. Grundsätzlich hast Du aber nicht ganz unrecht - das weiß ich schon.

    Beste Grüße
    Janko

    Hallo Janko,

    vielleicht stößt unser mrb ja auf diesen Thread. Er kennt sich mit dem ganzen Encoding besser aus als ich. Mal schauen, was er sagt.

    Meiner Meinung nach ist die E-Mail schlicht und ergreifend nicht standardkonform. Ich habe eine solche E-Mail wissentlich in all den Jahren noch nie erhalten. Ich habe allerdings auch kein Konto bei Paypal. Der andere Thread, den Du gefunden hast, hat auch schon ein paar Jahre auf dem Buckel. Wie es scheint, gibt es nicht sehr viele solch schwarzer Schafe.

    Ich würde es nicht für richtig halten, wenn die TB-Entwickler etwas programmieren würden, das nicht den Regel entspricht. Wir ändern schließlich auch nicht die Verkehrsregeln, nur weil immer wieder mal jemand bei Rot über die Kreuzung fährt.
    Du solltest (zunächst rein gedanklich) besser von Paypal eine Nachbesserung verlangen und nicht von denjenigen, die sich an die Regeln halten und bei Rot anhalten.

    Gruß

    Susanne

    Hm, mit ist keine Beschränkung des Transfer-Encodings von einzelnen Blöcken bekannt, RFC2045, 6.4 legt nur für die Multipart-Blöcke selbst ein Verzicht auf besondere Encodings fest:


    Ich wüsste also nicht, was daran nicht standardkonform sein sollte. Gerade wenn man z.B. fast ausschließlich nicht-ASCII-Zeichen nutzt (Russisch, Chinesisch, Japanisch, ...) kann da base64 Sinn machen, da quoted-printable dann unnötig viel Platz verschwenden würde.

    Scheint ja auch in TB zu funktionieren, nur aus unbekannten Gründen nicht mit den Testmails. Vielleicht gab es aber auch Seitens PayPal im Zuge der Umstellung Probleme mit der Nur-Text-Fassung (iirc beziehen sich Filter immer darauf, oder?), die inzwischen behoben wurden.

    Hallo Dirk,

    dem Zitat zufolge könntest Du Recht haben. Ich verstehe das auch so, dass der Body der gesamte Mail kodiert sein darf. Ich habe allerdings nicht den kompletten RFC gelesen, ob er weitere Empfehlungen enthält. Die Einleitung des RFC beschreibt die oben bereits erwähnten Gründe dafür, aus denen man das Encoding überhaupt eingeführt hat, nämlich weil E-Mail zunächst auf reine ASCII-Nachrichten ausgelegt war:

    Zitat


    RFC 822 was intended to specify a format for text messages. As such, non-text messages, such as multimedia messages that might include audio or images, are simply not mentioned. [...] This forces users to convert any non-textual data that they may wish to send into seven-bit bytes representable as printable US-ASCII characters before invoking a local mail UA ...


    Daraus ließe sich zumindest die klare Intention oder best practise ablesen, dass man nicht Base-64 kodieren sollte, wenn es nicht nötig ist. Schließlich erzeugt es einen Overhead von 33%.

    Sei's drum. Ich denke Du hast auf jeden Fall insofern Recht, als dass es erlaubt ist. Mir sind solche E-Mails bisher wissentlich nicht untergekommen. Aber ich schau mir natürlich auch nicht jede Mail im Quelltext an.
    Ich korrigiere also das "bei Rot über die Kreuzung fahren" zu "bei Dunkelgelb ... " ;-)

    Zitat von generalsync

    Scheint ja auch in TB zu funktionieren, nur aus unbekannten Gründen nicht mit den Testmails

    Natürlich, wenn man auf eine Base64-String filtert sollte der auch gefunden werden. Und das funktioniert ja wohl auch. Ich habe Janko allerdings so verstanden, dass er sich von den Entwicklern wünschen würde, dass solcherart kodierte E-Mails für die Suche bzw. für die Filterfunktion encoded werden, damit man den Suchstring nicht extra nach Base64 kodieren muss.

    Gruß

    Susanne

    Zitat von Janko Hack

    Eine nur-Text-Fassung gibt es (und gab es) nicht.

    Damit ist aus meiner Sicht dann doch wieder PayPal schuld: jede Mail sollte (meiner Meinung nach) eine Plain-Text-Version beinhalten, nicht nur für ältere Clients und sicherheitsbewusste Nutzer, sondern auch zur einfacheren maschinellen Verarbeitung. Ich habe es gerade spaßeshalber getestet: eine base64-kodierte Nur-Text-Mail kann – wie ich auch erwartet hätte – ohne Workarounds mit Filtern benutzt werden.

    Zitat von SusiTux

    dass man nicht Base-64 kodieren sollte, wenn es nicht nötig ist. Schließlich erzeugt es einen Overhead von 33%.

    Würde ich auch so sehen, nur sind die "33%" ziemlich amerikanisch: nicht-ASCII-Zeichen sind in Base64 eher schlanker als in quoted-printable, daher kann es für manche Sprachen auch im Plaintext Sinn machen, base64 zu nutzen (wenn 8bit nicht verfügbar sein sollte).

  • Community-Bot 3. September 2024 um 20:30

    Hat das Thema geschlossen.