Also, meine Shell-Bastelei reicht natürlich auch nicht ansatzweise an Eure Kenntnisse heran. Zu meinem Entsetzen habe ich festgestellt, daß es auch Mails gibt, die:
Code:
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: base64
U2VociBnZWVocnRlciBIZXJyIEJyw7Z0amUsDQoNCnZpZWxlbiBEYW5rIGbDvHIgSWhyZSBOYWNo
cmljaHQuIERlciBWb3JnYW5nIGlzdCBmw7xyIGRhcyBHZW5lcmFsa29uc3VsYXQgYWJnZXNjaGxv
c3Nlbi4gRGllIGVudHNjaGVpZHVuZ3NyZWxldmFudGVuI
Da bin ich mit meinem Latein am Ende!
@abgdf:
Vielen Dank für das angepasste Script!
Ich möchte gerne kurz erklären, worum es mir genau geht:
Claws-Mail erlaubt es, Mails von der GUI aus per Button an ein oder mehrere Scripte zu leiten, wählt man als Option
path/to/script %f wird die ganze Mail weitergegeben.
Mit dieser Option können auch alle in der Mailliste markierten Emails exportiert werden.
Daraus erwächst die Möglichkeit, aus einem längeren Mailwechsel
ein Dokument zu machen:
Alle betroffenen Einzelmails mit "%f" exportieren, mittels "mail2text" den einen reinen Textauszug erstellen, diesen chronologisch richtig in
eine Datei leiten.
Dazu muss ich die Mails
nicht mittels Pop3 vom Server holen, das macht ja bereits Claws-Mail! Ich muss nur die von Claws bereits exportierten Dateien vom Typ message/rfc822 an mein (bislang schreckliches) "mail2text" schicken und bekomme den Text ausgespuckt.
Wird nun "mail2text" das Absendedatum auch mitschicken, ist es kein Problem, daraus einen Timestamp zu machen und chronologisch zu sortieren.
Leider kann ich kein Python, darum wird es mir nicht möglich sein, das Script entsprechend zu modifizieren. Ich denke an `cat message | mail2text > message.txt`.
@uhelp:
alpine -F file Open named text file and view with Alpine's browser.
Habe ich versucht, mit besagter Mail, die (Tatsache) den Plain-Mailtext base64 codiert übermittelt:
Alpine öffnet den Text genau wie die Beschreibung sagt als Textdatei und parst garnichts.
Natürlich, wenn ich eine Mail
in Mutt oder Alpine (vom Server) öffne, kann ich diese als Textdatei exportieren. Aber ich suche eine analoge Funktion zu "lynx -dump file.html".
Ps zu base64:
Hab probiert den Text mit "cat file | base64 --decode" zu entschlüsseln, was aber auch nicht so einfach zu sein scheint. Vermutlich sind es die Zeilenumbrüche im Code, die entfernt werden müssten.
Meine rudimentären Kenntnisse:
"cat file | tr '\n' ' ' | sed 's/ //g' | base64 --decode".
Geht auch nicht...
Wie gesagt, meine Kenntnisse sind rudimentär, und es ist schwierig - schwierig - schwierig.
Selbst wenn man den Nachrichtenteil zuverlässig herauslöst. Der Header ist dabei kein Problem.
Als Trenner kann ein einfaches '--' am Zeilenanfang hergenommen werden, das reicht für meine Zwecke.
Aber es gibt auch Abschnutte, die
zwischen Header und Nachrichtenteil liegen.
Also müsste die Mail erst auf die vorhandenen Abschnitte (Text, Html usw) geprüft werden, bevor konvertiert werden kann.
Ich habe nach längerem Suchen eine passable deutschsprachige Erklärung hier gefunden:
https://www.drweb.de/aufbau-von-mime-mails-2/
Für Html reicht es, <br> durch \n zu ersetzen und ansonsten alle Tags zu entfernen und Entities zu ersetzen.
Für plain Text könnte es reichen, ggF mit iconv nach utf8 zu konvertieren,
und Ersetzungen wie
"sed 's|=c3=84|Ä|gi'" durchzuführen.
Aber dann noch base64 kodierten Text? Das wird mir langsam zu heftig...
'doomed to fail' trifft es wohl ganz gut...
Bisher habe ich "formail" und "metamail" probiert, beide können es anscheinend
nicht:
"formail" scheint dafür nicht konzipiert zu sein.
"metamail" kann nicht mit "multipart/alternative message" umgehen und behauptet Beispielsweise bei einer Mail immerhin von der deutschen Botschaft, sie wäre fehlerbehaftet und daher nicht lesbar.
so what...
alles Zeitverschwendung und sonst nichts?
Es gibt doch etliche Systeme, die automatisiert Mails weiterverarbeiten?
:schockiert:
Nachtrag base64:
openssl enc -d -base64 -in file-in-base64
...klappt! Aber Achtung, unmittelbar am Block kann ein '=...' hängen, welches zuvor entfernt werden muss..
:zensur:
