Bash Snippets - 3

Spamfilter können auf Wunsch die aussortierten Mails am Server speichern. An sich sieht man es den Mails schon am Betreff an, ob sie tatsächlich spam oder doch ham (und in diesem Fall eventuell ein false positive) sind.
Allerdings müssen non-ascii Teile des Mailheaders passend encodiert sein, was das Lesen teilweise unmöglich macht.

Ein paar Beispiele:
=?iso-8859-1?Q?Hall=F6chen?=
=?UTF-8?Q?Hall=C3=B6chen?=
=?UTF-8?B?SGFsbMO2Y2hlbg==?=
=?iso-2022-jp?B?GyRCOiNHLyRiSSwkOiRkJGo/ayQyJGsbKEIhIRskQkcvS3ZBMCRO?=
=?GB2312?B?0rvSubzkyMM1MDDN8sjLudjXosT6svrGt7XEzfjC59Oq?=

Da sind diverse encodings, mal in quoted printable, mal in base64. Allen gemeinsam ist die schwere Lesbarkeit.

Mailheader oder Teile davon kann man am einfachsten mit perl decodieren: Obiges Beispiel decodiert nicht einfach nur den Header, sondern encodiert auch gleich in UTF-8 (default wäre iso).

Aber auch ganze Unterordner voller Spammails können durchsucht werden: Dieses Beispiel durchsucht die neuesten 20 Mails im Ordner nach encodierten Subjects und gibt diese decodiert als UTF-8 aus.
Nicht encodierte Teile sind übrigens gar kein Problem.

Vertrauen ist gut, Kontrolle ist besser. Hier folgt eine Sammlung von Kommandozeilentests für diverse Maildienste (smtp, pop, imap...)

Wir gehen davon aus, dass der Mailserver erfolgreich installiert ist, in diesem Fall sei das Postfix mit Postgrey und Amavis, das Zertifikat wurde erstellt, die erforderlichen Dienste laufen und die gewünschten Ports sind in der Firewall geöffnet. Die Dienste imap, imaps, pop3 und pop3s werden von Dovecot zur Verfügung gestellt.
Als Beispieldomain verwende ich dein.mailserver.net, als Beispiel-IP 1.2.3.4, der Beispieluser (brauchen wir zum Testen der Dienste mit Login) heißt userlein und er hat das Passwort "geheim".

Um es übersichtlicher zu machen, sind die einzugebenden Befehle grün, die Antworten des Servers, auf die es besonders ankommt sind blau.

Nun aber zu den Praxisbeipielen:

Gelegentlich flutscht auch mal ein Spammail durch den Amavis-Filter und landet damit ungewollt in der Autowhitelist, bzw. wird von Bayes fälschlicherweise als sauber erkannt.
Mit zwei Kommandos kann das richtig gestellt werden.
Amavis läuft als unprivilegierter User (in diesem Fall als vscan), damit sa-learn und spamassassin für den richtigen Filter funktionieren, rufen wir die Kommandos mit sudo auf (als root):
...entfernt die Email Adresse aus der Whitelist. ...trainiert Bayes auf das vormals durchgeflutschte Mail (hier spammail.eml).

Das kann natürlich auch gleich getestet werden: Siehe da, Bayes vergibt jetzt 3.5 Punkte, AWL ist völlig verschwunden.

Die Bash (test) kann an sich nur Ganzzahlen vergleichen, übergibt man eine Fließkommazahl, führt das zu einem Fehler. Möchte man doch schnell mal zwei floats vergleichen, geht das ganz einfach mit bc. Zuerst interaktiv:

xela@linux:~> bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
if (10.123 > 10.1119) 1 else 0
1
quit

Um diese Art Test in einem Skript verwenden zu können, nehmen wir "echo" zum Übergeben an bc: Wichtig dabei ist das "else 0", damit auf alle Fälle ein Integer (Ganzzahl) zurückgegeben wird, den test (also [ ) dann vergleichen kann.
So richtig Sinn macht das klarerweise erst mit Variablen:

FFMPEG bietet ein paar dürftig dokumentierte Effekte, sogenannte vhooks. Einer davon ist imlib2.so. Zwar sind die vhooks zu nicht viel nütze, werden auch gar nicht mehr weiter entwickelt und sind in der Anwendung gräßlich kompliziert. Einen lustigen Effekt möchte ich euch aber nicht vorenthalten: eine Schrift, die etwas zeitverzögert übers Bild huscht und dabei langsam transparent wird.
Ja, das ist eine mords Codewurst.

Zuvor muss in der Shell noch die Variable FONTPATH gesetzt und exportiert werden, falls sie nicht gesetzt ist: Sonst findet ffmpeg die Schriften nicht. Obiger Ordner ist nur ein Beispiel, dort liegt bei mir zufällig die Schrift, die ffmpeg per default verwendet. Zwar kann das noch mit -f gesetzt werden, aber der Befehl ist auch so schon lang genug.

Jetzt aber im Detail:

Zenity ist ein Programm, das GTK+ Dialoge anzeigt. Damit kann man Shellskripten ein GUI (Graphical User Interface) verpassen, was einigen Komfort für den User bringt.

Ein einfaches Beispiel:

Zenity kann aber auch Fragen, Auswahllisten, Kalender, etc.

Wenig bekannt ist, dass die Texte in den Dialogfenstern auch formatiert werden können. In der manpage von zenity steht auch gar nichts davon.

Deshalb ein paar Beispiele:
<b></b> erzeugt fetten Text
<i></i> erzeugt kursiven Text
Verwendet wird offensichtlich eine HTML-ähniche Syntax mit Tags.

large, larger, x-large und xx-large erzeugen größeren Text
\n erzeugt einen Zeilenumbruch
Natürlich kann man Text auch verkleinern mit small, smaller, x-small und xx-small.

Auch farbiger Text ist möglich:
Außerdem gehen die HTML-Tags <u>, <tt>, <sup>, <sub>, <s>, <big>.

Mehr lässt sich eventuell noch durch herumprobieren herausfinden.
Die Dokumentation zu den mit zenity verwendbaren Tags steckt wohl irgendwo tief im GTK+ Quelltext.

Textdateien haben ein Encoding, das ist in unseren Breiten meist entweder utf-8 oder iso-8859-1 (es gibt natürlich noch bedeutend mehr). Ein großes Problem entsteht, wenn Windows- und Linuxuser gemeinsam (deutschsprachige) Dateien bearbeiten. Dann kann es vorkommen, dass eine Textdatei sowohl utf-8, als auch iso-8859-1 Teile enthält.
Die Datei ist kaputt, Umlaute werden teilweise nicht mehr richtig angezeigt.

Was tun? Normalerweise müsste sich jetzt jemand hinsetzen und den gesamten Text durcharbeiten.
Nein, wir Tricksen!

Wir verwenden das Programm recode, allerdings nicht direkt. Mit gemischtem Encoding kann recode nicht umgehen, sondern wir gehen den Umweg über HTML-Entities.

Wichtig: Folgendes findet auf einer Linuxkonsole mit $LANG=de_DE.UTF-8 statt: