Vor ein paar Tagen erreichte mich ein Kommentar zu meinem Let's-Encrypt-Setup: die Datei hook.sh muss um die Kommandos unchanged_cert und exit_hook ergänzt werden.

Ja, ich weiß - es ist schon mehr als nur ein paar Tage her, dass letsencrypt.sh zu dehydrated umbenannt wurde. Und ich habe die dafür notwendigen Änderungen bei mir lokal auch vorgenommen. Aber ich habe sie hier nicht dokumentiert. Schande über mich.

Jedenfalls hat mich Freddy Leitner^[1] netterweise auf diesen Lapsus aufmerksam gemacht. Er hat außerdem angemerkt, dass man die gesamte Infrastruktur noch ein wenig verschlanken kann:

hook.sh

Die hook.sh muss bei unserem Setup nur auf genau einen Hook reagieren, nämlich deploy_cert. Alle anderen können wir getrost ignorieren. Um genau zu sein, müssen wir das sogar - für den Fall, dass wie oben beschrieben weitere Hooks hinzukommen. Damit schnurrt die Datei auf folgende sechs Zeilen zusammen:

#!/usr/bin/env bash
if [ "${1}" == "deploy_cert" ] ; then
  uberspace-add-certificate -k ${3} -c ${4}
else
  exit 0
fi

Bei der Gelegenheit habe ich gleich noch das veraltete uberspace-prepare-certificate in den aktuellen Befehl uberspace-add-certificate geändert. Außerdem konnte ich auch die Parameter-Überprüfung entfernen. Der Rückgabewert eines Shell-Skripts ist ja gleich dem Rückgabewert des letzten ausgeführten Befehls. Und im Zweifel macht sich uberspace-add-certificate schon passend bemerkbar.

config.sh

Bei der config.sh ist das Verhältnis von Kommentaren zu Nutzlast noch größer. Hier kommen wir mit insgesamt nur drei Zeilen aus:

WELLKNOWN="/var/www/virtual/${USER}/html/.well-known/acme-challenge"
HOOK="${BASEDIR}/hook.sh"
CONTACT_EMAIL="${USER}@${HOSTNAME}"

Diese Version der Konfigurationsdatei hat jetzt darüber hinaus den Vorteil, dass sie unverändert mit jedem beliebigen Account funktionieren sollte. Die verwendeten Variablen werden jedenfalls beim Aufruf über runwhen korrekt gesetzt. Ob das auch als Cronjob funktioniert, kann ich mangels passendem Setup im Moment nicht überprüfen. Your mileage may vary.

An dieser Stelle nochmal vielen Dank an Freddy! Und natürlich an alle anderen Leser - die, die mir Kommentare schreiben, und die, die einfach nur so vorbeischauen und meine Notizen nützlich finden.

Update: Ich habe die hook.sh und die config.sh verschlankt und an die neue version von letsencrypt.sh namens dehydrated angepasst. Die Details findet ihr in einem eigenen Blogpost.

Nachdem Let's Encrypt auch von Uberspace unterstützt zu werden beginnt, und ich ja immer nach Wegen suche, mir das Teilzeitadmin-Leben zu vereinfachen, wollte ich mir die automatische Domain-Verifikation von Let's Encrypt zunutze machen. Klingt ja fantastisch: Einfach per Konfiguration einstellen, für welche Domains man Zertifikate haben möchte, und der Let's-Encrypt-Client kümmert sich um alles. Nie wieder per E-Mail nachweisen, dass mir die Domain macfrog.de immer noch gehört - juhu!

Welchen Client hätten's denn gern?

Allerdings habe ich mit dem Standard-Client so meine Probleme. Das fängt damit an, dass das Teil root-Rechte haben möchte. Ich stimme Jonas da voll zu: Es gibt exakt überhaupt keinen Grund, warum das so sein müsste. Muss es ja auch nicht, wie man an Uberspace sieht. Da funktioniert der Standard-Client auch so.

Trotzdem ist mir das Programm nicht ganz geheuer. Erstens ist mein Python ein wenig... ähm... eingerostet, so dass ich nicht wirklich nachvollziehen kann, was es tut. Und das wüsste ich schon gerne - immerhin geht es hier unter anderem um die privaten Schlüssel zu meinen Website-Zertifikaten. Und außerdem ist mir das Programm für einen Code Review auch ein wenig zu lang.

Ich habe mich also auf die Suche nach einer Alternative gemacht, und bin bei letsencrypt.sh fündig geworden. Das ist ein Shell-Skript, das die wesentlichen Funktionen des Original-Clients, nämlich

• Let's-Encrypt-Account anlegen
• Challenge für Domain-Nachweis abwickeln
• Zertifikat generieren und unterschreiben lassen

genau so gut abwickelt, dabei keine root-Rechte braucht und noch dazu so übersichtlich ist, dass ich mir einigermaßen sicher darüber bin, was es tut.

Allerdings möchte ich nicht verschweigen, dass letsencrypt.sh noch ziemlich in der Entwicklung steckt. Aber wie's aussieht, ist zumindest die Version vom 08.01.2016 ganz schön stabil. Mir ist zumindest noch kein Fehler aufgefallen. Und Let's Encrypt selber ist ja auch noch in der Beta-Phase.

Installation

Also nichts wie los, eine Kopie der Sourcen geholt und die wichtigsten Dateien nach ~/opt/letsencrypt/ kopiert. Das Zielverzeichnis könnt Ihr selbstverständlich frei wählen - ich fand den Platz ganz passend:

cd ~/src
git clone https://github.com/lukas2511/letsencrypt.sh.git
mkdir ~/opt/letsencrypt
cd ~/opt/letsencrypt
cp ~/src/letsencrypt/letsencrypt.sh .
cp ~/src/letsencrypt/config.sh.example config.sh
cp ~/src/letsencrypt/domains.txt.example domains.txt

Jetzt müssen natürlich noch die Konfigurationsdateien angepasst werden:

domains.txt

Hier kommen alle Domainnamen rein, für die Zertifikate generiert werden sollen. Falls eine Domain mit mehreren Unterdomains vertreten ist, bietet es sich an, diese als SAN (Subject Alternate Name) anzugeben. Diese Alternativnamen kommen in eine Zeile hinter den ursprünglichen Domainnamen. Für mich sieht das dann so aus:

macfrog.de blog.macfrog.de www.macfrog.de
mcfrog.de blog.mcfrog.de www.mcfrog.de

Bei Euch sollten selbstverständlich Eure eigenen Domainnamen stehen.

config.sh

Hier müsst Ihr auf jeden Fall die Variable WELLKNOWN anpassen und könnt eine CONTACT_EMAIL-Adresse setzen, wenn Ihr das möchtet:

WELLKNOWN="/var/www/virtual/<username>/html/.well-known/acme-challenge"
CONTACT_EMAIL="<username>@<hostname>.uberspace.de"

Vergesst nicht, die #-Kommentarzeichen zu entfernen, wenn Ihr Werte setzt, sonst werden die Standardwerte verwendet, und das ist ja gerade nicht das, was Ihr wollt.

<username> und <hostname> ersetzt ihr natürlich durch Euren Uberspace-Benutzernamen und den zugehörigen Host. Zumindest was die E-Mail-Adresse angeht, könnt Ihr Euch aber offensichtlich eine beliebige Adresse aussuchen. Das oben ist nur der Wert, den der Standard-Client setzt.

Auch wenn es sich hier so einfach liest, muss ich zugeben, dass mir WELLKNOWN ein bisschen Kopfzerbrechen bereitet hat: Eigentlich wollte ich analog der Anleitung von auf GitHub den Apache von Uberspace per .htaccess dazu bringen, den Pfad http://macfrog.de/.well-known/acme-challenge/ auf ein passendes Verzeichnis umzubiegen. Aber egal, was ich mit .htaccess anstellte - ich konnte keine Inhalte ausspielen. Bis mir klar wurde, dass Uberspace anscheinend tatsächlich wie von Jonas - zunächst nur als Konzept - beschrieben die Zugriffe für jede eingetragene Domain eines Benutzers vor dem Apache abfängt und grundsätzlich aus /var/www/virtual/<username>/html/.well-known/acme-challenge bedient.

Das ist einfach und elegant, weil der Client nur ein konstantes Verzeichnis für die ACME-Challenge bedienen muss, egal welche Domain oder Subdomain überprüft werden soll. Kein Hantieren mit unterschiedlichen Konfigurationen für Subdomains. Hab' ich schon geschrieben, dass es einfach Spaß macht, bei Uberspace zu sein? :-)

Automatische Zertifikatsinstallation

Bis hierhin funktioniert alles ähnlich wie der Standard-Client. letsencrypt.sh weist aber noch zwei Besonderheiten auf, die es für einen Einsatz auf Uberspace geradezu prädestinieren: Es überprüft, ob Zertifikate in den nächsten 30 Tagen ablaufen und fordert nur diese neu an. Soweit ich sehe, kann das der Standard-Client (noch) nicht. Selbstverständlich ist die Zeit bis zum Verfallsdatum einstellbar. Und es kann ein Skript aufrufen, sobald ein Zertifikat erfolgreich generiert und unterschrieben wurde.

Das schreit doch geradezu danach, an dieser Stelle einen Umweg über uberspace-prepare-certificate zu machen. Zumal die Zertifikatsinstallation bei Uberspace seit neuestem vollautomatisch funktioniert und keine E-Mail an den Support mehr benötigt. Und genau diesen kleinen Umweg nehmen wir jetzt auch.

Wie Ihr vielleicht schon in der config.sh gesehen habt, gibt es den Parameter HOOK:

# Program or function called in certain situations
#
# After generating the challenge-response, or after failed challenge (in this case altname is empty)
# Given arguments: clean_challenge|deploy_challenge altname token-filename token-content
#
# After successfully signing certificate
# Given arguments: deploy_cert domain path/to/privkey.pem path/to/cert.pem path/to/fullchain.pem
#
# BASEDIR and WELLKNOWN variables are exported and can be used in an external program
# default: <unset>
HOOK="${BASEDIR}/hook.sh"

Die ersten zwei Fälle sind uns relativ egal, aber der dritte Fall ist spannend. Wie Ihr seht, bekommt das HOOK-Script ein Argument übergeben, in welcher Situation es aufgerufen wurde. Uns interessiert hier der Fall deploy_cert, bei dem dann unter anderem die Pfade zum privaten Schlüssel und zum Zertifikat als weitere Parameter angegeben werden. Also genau das, was uberspace-prepare-certificate braucht.

hook.sh

Wir legen daher noch folgendes Skript unter ~/opt/letsencrypt/ (bzw. Eurem Installationsverzeichnis) ab:

#!/bin/env bash
#============================================================================
#
# DESCRIPTION
#    This script hooks into letsencrypt.sh and deploys generated
#    certificates to Uberspace.
#
# COMMANDS
#    deploy_challenge  Deploys challenge to system for ACME CA to query
#                      Currently not implemented. Might be used in future
#                      for dns-01 challenge type.
#
#    clean_challenge   Removes previously deployed challenge
#                      Currently not implemented.
#
#    deploy_cert       Deploys generated certificate to Uberspace
#
# EXAMPLES
#    hook.sh deploy_cert example.com privkey.pem cert.pem fullchain.pem
#
# IMPLEMENTATION
#    version         0.0.1
#    author          Thorsten Köster
#    copyright       Copyright (C) Thorsten Köster
#    license         GNU General Public License v3.0
#
#============================================================================
#
#  HISTORY
#     2016/01/09 : tkoester : Script creation
#
#============================================================================

if [[ ! $# -ge 1 ]] ; then
  echo "No arguments given." >&2
  exit 2
fi

case "${1}" in
  deploy_challenge)
    exit 0
    ;;
  clean_challenge)
    exit 0
    ;;
  deploy_cert)
    shift 1
    if [[ ! $# -ge 3 ]] ; then
      echo "Insufficient number of arguments." >&2
      exit 2
    fi
    uberspace-prepare-certificate -k ${2} -c ${3}
    if [[ $? = "0" ]] ; then
      exit 0
    else
      exit 1
    fi
    ;;
  *)
    printf "Unknown command: ${1}" >&2
    exit 2
    ;;
esac

Das Skript unterscheidet zunächst mal anhand des ersten Arguments, in welcher Phase es gerade aufgerufen wurde. deploy_challenge und clean_challenge ignorieren wir vorerst und tun so, als wäre die Ausführung erfolgreich gewesen. Bei deploy_cert prüfen wir, ob wir mindestens drei weitere Parameter übergeben bekommen haben und rufen dann entsprechend uberspace-prepare-certificate auf. Der Rest ist dann nur noch Fehlerbehandlung.

Natürlich müsst Ihr das Skript noch ausführbar machen:

chmod u+x hook.sh

Und vergesst nicht, die config.sh azupassen, falls Ihr das nicht schon oben getan habt:

HOOK="${BASEDIR}/hook.sh"

Voller Service

Jetzt können wir natürlich auch noch das Zertifikats-Renewal voll automatisieren, entweder per Cronjob oder per runwhen. Da ich schon bisher alle sich wiederholenden Tätigkeiten auf Uberspace per runwhen erledige, habe ich mir einen entsprechenden Service angelegt:

runwhen-conf ~/etc/run-letsencrypt ~/opt/letsencrypt/letsencrypt.sh

Die Datei ~/etc/run-letsencrypt/run müssen wir noch ein wenig anpassen. Zum einen müssen wir natürlich noch festlegen, wann der Job laufen soll. Ich habe mich für einmal wöchentlich am Freitag, pünktlich zum Feierabend entschieden. Dann kann ich übers Wochenende versuchen, die Fehler zu beheben, falls was schief ging:

RUNWHEN=",w=5,H=16"

Zum anderen benötigt letsencrypt.sh noch den Parameter -c für Cron, um alle Zertifikate auf den neuesten Stand zu bringen. Änderungen an der domains.txt sollten damit ebenso abgearbeitet werden wie neue Zertifikate 30 Tage vor Ablauf der alten angefordert werden. Diese Zeitspanne lässt sich übrigens auch in der config.sh mit dem Parameter RENEW_DAYS einstellen.

Vollständig sieht meine ~/etc/run-letsencrypt/run nun so aus:

#!/bin/sh -e

RUNWHEN=",w=5,H=16"

# many tools and programming languages need these e.g. to find user-installed modules
export USER=macfrog
export HOME=/home/macfrog

exec 2>&1 \
rw-add n d1S now1s \
rw-match \$now1s $RUNWHEN wake \
sh -c '
  echo "@$wake" | tai64nlocal | sed "s/^/next run time: /"
  exec "$@"' arg0 \
rw-sleep \$wake \
/home/macfrog/opt/letsencrypt/letsencrypt.sh -c

Dann noch der übliche Symlink nach ~/service und den Job einmal starten:

ln -s ~/etc/run-letsencrypt ~/service/letsencrypt
svc -a ~/service/letsencrypt

Et voilà - die Zertifikate mitsamt Schlüssel für Eure Domains aus domains.txt sollten sich jetzt in ~/opt/letsencrypt/certs/<domainname>/ befinden und außerdem bereits bei Uberspace eingetragen sein. Und wenn die Automatik funktioniert, müsst Ihr Euch nie wieder um eine Erneuerung kümmern.

tl;dr

Wenn Ihr das hier auch in drei Monaten noch lesen könnt, dann hat das, was ich oben beschrieben habe, höchstwahrscheinlich funktioniert.

Als Programmierer ist man ja grundsätzlich faul. Sich wiederholende Aufgaben überlässt man lieber dem Computer. Zumal es ja grundsätzlich interessanter ist, sie dem Computer beizubringen, anstatt sie selber abzuarbeiten. Auch wenn Letzteres viel schneller gehen würde...

In diesem Sinne stand mal wieder die Erneuerung meiner SSL-Zertifikate an. Nun ist dieses Blog nicht nur unter https://blog.macfrog.de/ sondern auch unter https://blog.mcfrog.de/ erreichbar (für die Leute, denen ich nicht zum hundertsten Mal erklären möchte, dass da ein "a" fehlt). Außerdem habe ich noch ein paar andere Domains mit jeweils nahezu gleichen Subdomains. Insgesamt ziemlich stupide Arbeit, für jede Kombination mit

openssl req -new -nodes -newkey rsa:4096 -sha512 -days <Gültigkeit> -out <CSR-Filename> -keyout <Key-Filename>

einen neuen Zertifikatsantrag zu erstellen und dabei jedes Feld

Country Name (2 letter code) [XX]:DE
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:.
...

von Hand auszufüllen. Ein Skript musste her.

Voraussetzung war natürlich zunächst einmal, sich die interaktive Tipparbeit zu sparen. Zum Glück gibt es da in openssl req den Schalter -subj, der den Betreff des Zertifikats angibt. Im Prinzip werden die interaktiv abgefragten Angaben nämlich nur in einen String verpackt, den man auch genauso gut per Kommandozeile übergeben kann:

openssl req -subj "/C=DE/CN=www.example.com/emailAddress=hostmaster@example.com" ...

Mehr als die paar Felder Country, Common Name und emailAddress unterstützen die kostenlosen Zertifizierungsstellen meist sowieso nicht, da sich die anderen Angaben nicht automatisch überprüfen lassen.

Das war's aber auch schon fast. Jetzt kommen nur noch ein paar Schleifen drum, und schon generiert ein kleines Skript ohne Zutun sämtliche CSRs für alle Subdomains meiner Domains:

#!/bin/bash
	
declare -a domains=("macfrog.de" "mcfrog.de")
declare -a subdomains=("blog" "www")
	
for d in "${domains[@]}" ; do
  for s in "${subdomains[@]}" ; do
    echo '***'
    echo '***' $s.$d
    echo '***'
    openssl req -subj "/C=DE/CN=$s.$d/emailAddress=hostmaster@$d" -nodes -new -newkey rsa:4096 -sha512 -days 395 -out $s.$d.csr.pem -keyout $s.$d.key.pem
  done
done

So kann man sich auch sein Ghost-Setup zerschießen...

Ich bin für das Update auf Version 0.5.8 meiner eigenen Anleitung gefolgt, und habe mich anschließend über einen 503 Service Temporarily Unavailable Error gewundert.

Und ein bisschen nervös wurde ich auch.

Bis mir einfiel, dass ich vor ein paar Tagen eine neue Version von gcc installiert hatte. Damit passten offensichtlich nach dem Kommando npm install --production die dabei kompilierten Dateien nicht mehr richtig zueinander.

Die Lösung war dann folgerichtig, das entsprechende Verzeichnis zu löschen, und die Abhängigkeiten erneut vollständig bauen zu lassen:

cd ghost
rm -rf node_modules
npm install --production

Auch mir reicht der standardmäßig auf Uberspace vorhandene gcc nicht mehr aus. Aber statt mich wie dieser Autor darauf zu beschränken, das Kompilat nur einfach in das toast-Verzeichnis zu installieren, wollte ich toast die ganze Arbeit machen lassen.

Der Übersichtlichkeit halber habe ich meine Kommandos in mehrere Schritte aufgeteilt, die man aber genau so gut zu einem Aufruf von toast arm mit den passenden Optionen zusammenfassen kann.

Ich hole zunächst mal die Datei. toast findet die höheren gcc-Versionen aus irgendeinem Grund nicht, daher ist die Angabe der kompletten URL notwendig. Immerhin kann toast daraus alleine schlussfolgern, dass wir hier gerne gcc in der Version 4.8.4 hätten:

toast get ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-4.8.4/gcc-4.8.4.tar.bz2

Zum Bauen müssen wir den von toast verwendeten Compileraufruf entsprechend umbiegen. Standardmäßig steht der auf ./configure --prefix=<toast-Verzeichnis>/armed && make, was für die meisten per autoconf / automake verwalteten Pakete passt. gcc ist aber noch von einigen separat verwalteten Paketen abhängig. Netterweise liefern uns die Compilerbauer das download_prerequisites Skript mit, das diese automatisch in der richtigen Version herunterlädt. Allerdings muss das vor dem configure-Schritt geschehen, und dann müssen configure auch noch die richtigen Optionen mitgegeben werden:

toast build gcc --compilecmd="./contrib/download_prerequisites && ./configure --prefix=/home/${USER}/.toast/armed --enable-languages=c,c++ --disable-multilib && make"

Das Gute ist: Toast räumt selbständig auf, nur das Quellpaket bleibt liegen. Wer will, kann das auch noch per toast purge gcc entfernen.

Anschließend muss das eben gebaute Paket noch aktiviert werden:

toast arm gcc

Das war's auch schon. gcc --version meldet jetzt wie gewünscht

gcc --version
gcc (GCC) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Das ging ja schneller als befürchtet. Im Prinzip bin ich teils dem Uberspace-Wiki und teils der Anleitung der Ghost-Macher gefolgt:

• Temporärverzeichnis umbiegen: export TMPDIR=~/tmp (Das Verzeichnis hatte ich noch von früheren Aktionen rumliegen.)
• Letzte Version von Ghost holen: wget https://ghost.org/zip/ghost-0.5.1.zip
• Uberspace-Dienst anhalten: svc -d ~/service/ghost
• Altes core Verzeichns löschen
• ZIP-Datei per unzip -uo ghost-0.5.1.zip -d path-to-ghost über die Installation entpacken
• Abhängigkeiten mittels npm install --production holen

An dieser Stelle wird es kurz mal ein wenig holprig, da ein Binary erst lokal kompiliert werden muss. Nicht nervös werden, die Automatik hat alles im Griff.

• Änderungen an content/themes/casper/default.hbs für die Links zum Impressum und zur Datenschutzerklärung wieder herstellen
• Uberspace-Dienst wieder starten: svc -u ~/service/ghost

Das war's auch schon...

Oder wie sollte man es sonst nennen, wenn man über seine Blogging-Platform bloggt? Jedenfalls möchte ich heute meine Ghost-Installation updaten.

Kurze Checkliste:

• Backup der Daten per JSON-Export: check
• Backup der Bilder und des Themes: check
• Dienst angehalten: äh... sofort...

Stay tuned!

Ungefähr ein Monat ist vergangen, seit ich DSPAM installiert habe. Und allmählich fängt der Bayes-Filter an, Spam-Mails auszufiltern. Ich bin beeindruckt - ich hätte mit einer längeren Lernphase gerechnet. Zumal ich auf jegliches Vorab-Training verzichtet und nur die False-Negatives "umgelernt" habe. False-Positives traten wie zu erwarten nicht auf.

Die Anleitung auf http://docs.ghost.org/de/mail/ ist ja ganz nett, aber auf Uberspace geht das auch einfacher. Folgender Eintrag in der config.js teilt Ghost mit, dass es tatsächlich sendmail nutzen darf:

production: {
    url: 'http://blog.example.com',
    mail: {
        transport: 'sendmail'
    },
    [...]

Der Absender ist dann ghost@blog.example.com. Für mich ist das ausreichend. Wer andere Anforderungen hat oder mehr wissen will, schaut einfach bei Nodemailer nach.

Es ist gerade mal eine Woche her, dass ich über mein maildrop-Setup auf Uberspace geschrieben habe. In der Zwischenzeit habe ich allerdings meine Skripte ein wenig aufgeräumt und erweitert.

Insbesondere habe ich auch DSPAM so mit eingebunden, dass Spam und Ham nach dem Neulernen nochmal richtig zugestellt werden. Anders als im Uberspace-Wiki muss man also nicht daran denken, Ham in den Trainings-Ordner zu kopieren anstatt ihn zu verschieben.

Aber der Reihe nach.

Filterfile 2.0

Nach der man-page zur maildrop-Filtersprache ist das Verzeichnis ~/.mailfilters/ eigentlich für den sogenannten embedded mode vorgesehen, in dem maildrop die Mails nicht selber zustellt sondern nur für andere Programme das Filtern übernimmt.

Niemand hindert einen jedoch daran, hier Skripte unterzubringen, die dann per include in den zentralen .mailfilter eingebunden werden können. Auf diese Weise habe ich mein Setup modularisiert:

checkmaildir

Dieses Skript ermittelt wie gewohnt das Mailverzeichnis des Empfängers.

# set default Maildir
MAILDIR="$HOME/Maildir"

# check if we're called from a .qmail-EXT instead of .qmail
import EXT
if ( $EXT )
{
  # does a vmailmgr user named $EXT exist?
  # if yes, deliver mail to his Maildir instead
  CHECKMAILDIR = `dumpvuser $EXT | grep '^Directory' | awk '{ print $2 }'`
  if ( $CHECKMAILDIR )
  {
    MAILDIR="$HOME/$CHECKMAILDIR"
  }
}

writelog

Wenn gewünscht, sorgt das folgende Skript dafür, dass alle ausgelieferten Mails in ~/var/log/mailfilter{-<mailboxname>} protokolliert werden.

# set up logging if desired
if ( $WRITELOG )
{
  LOGFILENAME="$HOME/var/log/mailfilter.log"

  # change logfile name if we've been called from .qmail-EXT
  import EXT
  if ( $EXT )
  {
    LOGFILENAME="$HOME/var/log/mailfilter-$EXT.log"
  }
  
  logfile "$LOGFILENAME"
}

handlespam

Das Spam-Handling erfolgt zunächst einmal zentral, um die Mails nach dem Training neu ausliefern zu können.

Wenn die Umgebungsvariable REDELIVER_SPAM gesetzt ist, wird die Mail direkt in den Spamordner verschoben. Wenn hingegen REDELIVER_HAM gesetzt ist, wird die Mail an den Spamfiltern vorbei direkt an die Filterregeln weitergereicht. Auf diese Weise landen auch false positives zu guter Letzt im richtigen Ordner.

# Handle Spam. Take care of re-trained messages from dspam-learn.
import REDELIVER_SPAM
if ( $REDELIVER_SPAM )
{
  DESTDIR="$MAILDIR/.Spam"
  SILENT_DESTDIR=$SILENT_SPAM
  include "$HOME/.mailfilters/deliver"
}

import REDELIVER_HAM
if ( ! $REDELIVER_HAM )
{
  if ( $SPAMASSASSIN_ENABLE )
  {
    # Show mail to SpamAssassin
    include "$HOME/.mailfilters/spamassassin"
  }

  if ( $DSPAM_ENABLE )
  {
    # Show mail to DSPAM
    include "$HOME/.mailfilters/dspam"
  }
}

spamassassin

Dieses Modul lässt die Mail vom SpamAssassin begutachten und verschiebt die Mail bei Bedarf in das Spam-Verzeichnis.

# show the mail to SpamAssassin
xfilter "/usr/bin/spamc"

# process SPAM
if ( /^X-Spam-Level: \*{$SPAMASSASSIN_MINSPAMSCORE,}$/ )
{
  DESTDIR="$MAILDIR/.Spam"
  SILENT_DESTDIR=$SILENT_SPAM
  include "$HOME/.mailfilters/deliver"
}

dspam

Das DSPAM-Modul funktioniert genau so, nur dass hier noch zusätzlich bei Bedarf die Trainingsverzeichnisse angelegt werden. Im Gegensatz zum Uberspace-Wiki habe ich mich hier für englische Ordnernamen entschieden. Außerdem landet verdächtige Mail nicht in einem weiteren Unterordner, sondern direkt im Spamfilter-Ordner.

# check folder structure
`test -d "$MAILDIR/.Spam"`
if( $RETURNCODE == 1 )
{
  `maildirmake "$MAILDIR/.Spam"`
}
`test -d "$MAILDIR/.Spam.Learn as Ham"`
if( $RETURNCODE == 1 )
{
  `maildirmake "$MAILDIR/.Spam.Learn as Ham"`
}
`test -d "$MAILDIR/.Spam.Learn as Spam"`
if( $RETURNCODE == 1 )
{
  `maildirmake "$MAILDIR/.Spam.Learn as Spam"`
}

# show the mail to DSPAM
xfilter "/package/host/localhost/dspam/bin/dspam --mode=teft --deliver=innocent,spam --stdout"

# process SPAM
if ( /^X-DSPAM-Result: Spam/ )
{
  DESTDIR="$MAILDIR/.Spam"
  SILENT_DESTDIR=$SILENT_SPAM
  include "$HOME/.mailfilters/deliver"
}

deliver

Fehlt noch die eigentliche Zustellung. Hier wird je nach Bedarf das Zielverzeichnis angelegt, und die Zustellung kann auch still erfolgen:

# Hierarchically create DESTDIR if it does not already exist.
HIER="$DESTDIR"
CONTINUE=1
while ( $CONTINUE && $HIER =~ /^(.*\/(\.[^.]+)*)(\.[^.]+)$/ )
{
  if ( $MATCH3 ne ".INBOX" )
  {
    `test -d "$MATCH"`
    if ( $RETURNCODE == 1 )
    {
      `maildirmake "$MATCH"`
    }
    else
    {
      CONTINUE=0
    }
  }
  HIER=$MATCH1
}

# Deliver mail. If SILENT_DESTDIR is set, mark all mail in
# DESTDIR as read.
if ( $SILENT_DESTDIR )
{
  # mark as read
  cc "$DESTDIR"
  `find "$DESTDIR/new/" -mindepth 1 -maxdepth 1 -type f -printf '%f\0' | xargs -0 -I {} mv "$DESTDIR/new/{}" "$DESTDIR/cur/{}:2,S"`
  exit
}
else
{
  to "$DESTDIR"
}

Dieses Skript beendet auf jeden Fall den aktuellen Skriptdurchlauf, entweder per exit, nachdem die Mail mit cc zugestellt und als gelesen markiert wurde, oder per regulärer Zustellung mit to. Aus der maildropfilter man-page:

The to statement is the final delivery statement. maildrop delivers message, then immediately terminates, [...]

^{Danke an LDer für den Hinweis, dass dieses Verhalten in der ursprünglichen Version des Artikels zu kurz gekommen war!}

~/.mailfilter-<mailboxname>

Während alle vorangegangenen Helfer-Skripte in ~/.mailfilters/ landen, kommt das eigentliche Filterfile direkt ins Hauptverzeichnis. Durch den modularen Aufbau wird das Grundgerüst relativ kurz:

# Configuration

WRITELOG="0"
SPAMASSASSIN_ENABLE="1"
SPAMASSASSIN_MINSPAMSCORE="5"
DSPAM_ENABLE="1"
SILENT_SPAM="0"

# ------------------------------------------------------

# Write log file, if desrired. Set Maildir. Handle Spam.
include "$HOME/.mailfilters/writelog"
include "$HOME/.mailfilters/checkmaildir"
include "$HOME/.mailfilters/handlespam"


# Set default destination Maildir
DESTDIR="$MAILDIR"
SILENT_DESTDIR="0"

# ------------------------------------------------------

# Here go the filter rules...

# ------------------------------------------------------

# Finally, deliver mail
include "$HOME/.mailfilters/deliver"

Ganz oben lässt sich das Verhalten der Helferskripte konfigurieren. Für die Schalter gilt dabei: Werte ungleich Null sind true, Null oder nicht gesetzt false. Im gekennzeichneten Mittelteil lassen sich dann unter anderem die im letzten Artikel vorgeschlagenen Filterregeln unterbringen.

Ein kleiner Nachteil der Modularisierung sei nicht verschwiegen: Normalerweise macht maildrop beim Start eine Syntaxprüfung des Filterfiles und steigt gegebenenfalls. sofort mit einer Fehlermeldung aus. Dies trifft aber nicht auf mit include eingebundene Skripte zu. Die werden erst geladen und überprüft, wenn sie tatsächlich gebraucht werden. Das kann das Debugging erschweren und zu seltsamen Effekten führen.

dspam-learn anpassen

Jetzt müssen wir nur noch dafür sorgen, dass dspam-learn die Mails nach dem Bearbeiten nicht einfach löscht sondern eine neue Zustellung startet.

Dazu übergeben wir den Nachrichtentext erneut an maildrop und setzen dabei REDELIVER_HAM und REDELIVER_SPAM entsprechend. Außerdem muss natürlich der Benutzer und sein zugehöriges Filterfile ermittelt werden. Damit das funktioniert, muss das Filterfile unbedingt unter ~/.mailfilter-<mailboxname> für VMailMgr-Postfächer, bzw. ~/.mailfilter für die Default-Mailbox abgelegt werden.

Das Skript geht übrigens stillschweigend davon aus, dass das Filterfile für jede betroffene Mailbox tatsächlich existiert. Alles andere ergibt ja auch keinen Sinn - irgendwie müssen die Spammails ja zunächst wegsortiert werden.

#!/bin/bash
###############################################################
# 2013-07-16 Christopher Hirschmann
#            c.hirschmann@jonaspasche.com
# 2014-05-10 Modifications for re-delivery by Thorsten Koester
###############################################################
#
# This program is free software: you can redistribute it
# and/or modify it under the terms of the GNU General Public
# License as published by the Free Software Foundation, either
# version 3 of the License, or (at your option) any later
# version.
#
# This program is distributed in the hope that it will be
# useful, but WITHOUT ANY WARRANTY; without even the implied
# warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
# PURPOSE.  See the GNU General Public License for more
# details.
#
# You should have received a copy of the GNU General Public
# License along with this program.  If not, see
# <http://www.gnu.org/licenses/>.
#
###############################################################
#
# This script will look for a system user's primary maildir
# $HOME/Maildir and possible vMailMgr maildir under
# $HOME/users/ and search them for folders indicating a
# certain DSPAM setup:
#
# \
#  \___ Inbox
#   \
#    \___ Spam
#          \
#           \___ Learn as Ham
#            \
#             \___ Learn as Spam
#
# If it finds this folder structure in any maildir, it will
# show files from the folders 'Learn as Ham' and 'Learn as
# Spam' to DSPAM (so it can learn) and after that it will
# re-deliver them via maildrop.
#
# You can make this script more verbose with '-v'.
#
###############################################################

while getopts ":hv" Option
do
	case $Option in
		h       )       echo -e "Usage:\n-v\tbe verbose\n-h\tthis help message"; exit 0;;
		v       )       VERBOSE=1; ;;
		*       )       echo -e "ERROR: Unimplemented option chosen: -${OPTARG}"; exit 1;;
	esac
done

if [ ! `grep -q "CentOS release 5" /etc/redhat-release` ]; then
# ionice -c3 is not supported on CentOS 5 for users != root
# (needs Linux => 2.6.25)
# so let's fall back to ionice -c2 -n7 which is better than
# nothing
    BE_NICE="nice -n 19 ionice -c2 -n7"
else
    BE_NICE="nice -n 19 ionice -c3"
fi

for DIR in $HOME/Maildir `find ${HOME}/users/ -mindepth 1 -maxdepth 1 -type d`;
do
	if [ "${VERBOSE}" == "1" ];
	then
		echo "Looking for mails in ${DIR}."
	fi
	if [ -d "$DIR/.Spam.Learn as Spam" ];
	then
		for SUBDIR in new cur ;
		do
# In order to be able to process filenames regardless of any
# kind of weird characters we need to list these files
# separated by null bytes and process them accordingly.
# To achieve this we use bash process substitution (look it
# up, if this looks weird for you).
# The relevant steps are these:
#
#   while IFS= read -d $'\0' -r file;
#   # do stuff
#   done < <(find "$DIR/.Spam.Learn as Spam/$SUBDIR" -type f -print0)

			IFSSAVE=$IFS;
			while IFS= read -d $'\0' -r file;
			do
				if [ "${VERBOSE}" == "1" ];
				then
					echo "Eating \"$file\". Yuk!";
				fi
				$BE_NICE /package/host/localhost/dspam/bin/dspam --class=spam --source=error --stdout < "${file}";
				if [ "${DIR}" == "$HOME/Maildir" ];
				then
					if [ "${VERBOSE}" == "1" ];
					then
						echo "Re-Delivering Spam to default mailbox.";
					fi
					REDELIVER_SPAM=1 /usr/bin/maildrop $HOME/.mailfilter < "${file}";
				else
					if [ "${VERBOSE}" == "1" ];
					then
						echo "Re-Delivering Spam to user \"${DIR##*/}\".";
					fi
					EXT=${DIR##*/} REDELIVER_SPAM=1 /usr/bin/maildrop $HOME/.mailfilter-${DIR##*/} < "${file}";
				fi
				rm -f "${file}";
			done < <(find "$DIR/.Spam.Learn as Spam/$SUBDIR" -type f -print0)
			IFS=$IFSSAVE;
		done
	fi
	if [ -d "$DIR/.Spam.Learn as Ham" ];
	then
		for SUBDIR in new cur ;
		do
			IFSSAVE=$IFS;
			while IFS= read -d $'\0' -r file;
			do
				if [ "${VERBOSE}" == "1" ];
				then
					echo "Eating \"$file\". Yum!";
				fi
				$BE_NICE /package/host/localhost/dspam/bin/dspam --class=innocent --source=error --stdout < "${file}";
				if [ "${DIR}" == "$HOME/Maildir" ];
				then
					if [ "${VERBOSE}" == "1" ];
					then
						echo "Re-Delivering Ham to default mailbox.";
					fi
					REDELIVER_HAM=1 /usr/bin/maildrop $HOME/.mailfilter < "${file}";
				else
					if [ "${VERBOSE}" == "1" ];
					then
						echo "Re-Delivering Ham to user \"${DIR##*/}\".";
					fi
					EXT=${DIR##*/} REDELIVER_HAM=1 /usr/bin/maildrop $HOME/.mailfilter-${DIR##*/} < "${file}";
				fi
				rm -f "${file}";
			done < <(find "$DIR/.Spam.Learn as Ham/$SUBDIR" -type f -print0)
			IFS=$IFSSAVE;
		done
	fi
done

if [ "${VERBOSE}" == "1" ];
then
	echo "Done looking for mails."
fi

Inbetriebnahme

Wie aus dem Uberspace-Wiki bekannt, muss dspam-learn regelmäßig als Service aufgerufen werden. Selbstverständlich verwenden wir hier die eben modifizierte Version:

test -d ~/service || uberspace-setup-svscan
runwhen-conf ~/etc/run-dspam-learn "$HOME/bin/dspam-learn"
sed -i -e "s/^RUNWHEN=.*/RUNWHEN=\",M=`awk 'BEGIN { srand(); printf("%d\n",rand()*60) }'`\"/" ~/etc/run-dspam-learn/run
ln -s ~/etc/run-dspam-learn ~/service/dspam-learn

Auch sollte man seine DSPAM-Datenbank regelmäßig bereinigen lassen:

test -d ~/service || uberspace-setup-svscan
runwhen-conf ~/etc/run-dspam_clean_hashdb "/usr/local/bin/dspam_clean_hashdb"
sed -i -e "s/^RUNWHEN=.*/RUNWHEN=\",H=`awk 'BEGIN { srand(); printf("%d\n",rand()*24) }'`\"/" ~/etc/run-dspam_clean_hashdb/run
ln -s ~/etc/run-dspam_clean_hashdb ~/service/dspam_clean_hashdb

Damit müsste DSPAM funktionieren. Allerdings dürfte es einige Spammails lang dauern, bis der Filter soweit angelernt ist, dass er korrekt arbeitet.

Im laufenden Betrieb ist es wichtig zu wissen, dass bereits von SpamAssassin ausgefilterte Mails nicht DSPAM zum Umlernen vorgelegt werden können. DSPAM hat diese Mail ja nie gesehen und kann auch gar nicht mehr in die Filterung eingreifen.

Im Uberspace-Standard-Setup werden Mails, die SpamAssassin für verdächtig hält, ab einer Spam-Punktzahl von fünf mit [SPAM] im Betreff gekennzeichnet. Normalerweise ist SpamAssassin damit, zumindest bei mir, eher auf der sicheren Seite. Es bietet sich daher an, $SPAMASSASSIN_MINSPAMSCORE="5" zu setzen, SpamAssassin als Werkzeug fürs Grobe zu nutzen, und die Feinarbeit dann DSPAM zu überlassen. Wenn man sein eigenes SpamAssassin-Setup eingerichtet hat, sollte man die Einstellungen natürlich entsprechend anpassen.

Seit knapp zwei Monaten bin ich jetzt bei Uberspace. Zeit, meinen Mailfilter aufzusetzen.

Wenn man IMAP nutzt, bietet es sich ja geradezu an, seine Mails in Ordner vorzusortieren. So kann man hinterher die ganzen Newsletter, die abzubestellen man zu faul ist, auf einen Schlag löschen. :-)

Für meine Experimente war die maildrop Dokumentation von Uberspace zusammen mit der man page für die maildrop Filter-Syntax ein guter Ausgangspunkt.

Mein Grundgerüst

Zunächst einmal habe ich das Grundgerüst ein wenig überarbeitet. Am Anfang sollte auf jeden Fall die Variable $MAILDIR gesetzt werden. Wir sind ja schließlich paranoid und wollen auf jeden Fall einen gültigen Wert haben, auch wenn dumpvuser aus irgendwelchen Gründen kein Verzeichnis zurückliefert:

# set default Maildir
MAILDIR="$HOME/Maildir"

# check if we're called from a .qmail-EXT  instead of .qmail
import EXT
if ( $EXT )
{
  # does a vmailmgr user named $EXT exist?
  # if yes, deliver mail to his Maildir instead
  CHECKMAILDIR = `dumpvuser $EXT | grep '^Directory' | awk '{ print $2 }'`
  if ( $CHECKMAILDIR )
  {
    MAILDIR=$CHECKMAILDIR
  }
}

Damit ist $MAILDIR festgelegt und zeigt auf das eigentliche Postfach. Ankommende Mails sollen nach $DESTDIR ausgeliefert werden. So können wir in aufeinanderfolgenden Filterregeln immer wieder auf $MAILDIR zurückgreifen. Daher ist vor allen weiteren Filterregeln folgende Zuweisung als Defaultwert notwendig:

# Set default destination Maildir
DESTDIR="$MAILDIR"

Danach kommen wie gesagt die Filterregeln. Und weil wir zu faul sind, alle Unterordner von Hand anzulegen, lassen wir das bei Bedarf auch den Computer machen, kurz bevor die Mail ausgeliefert wird:

# Hierarchically create DESTDIR if it does not already exist,
# and deliver mail

HIER="$DESTDIR"
CONTINUE=1
while ( $CONTINUE && $HIER =~ /^(.*\/(\.[^.]+)*)(\.[^.]+)$/ )
{
  if ( $MATCH3 ne ".INBOX" )
  {
    `test -d "$MATCH"`
    if ( $RETURNCODE == 1 )
    {
      `maildirmake "$MATCH"`
    }
    else
    {
      CONTINUE=0
    }
  }
  HIER=$MATCH1
}
to "$DESTDIR"

Das Skript hangelt sich im Verzeichnisbaum so lange nach oben, bis es ein bereits angelegtes Mailverzeichnis findet. Außerdem spart es den virtuellen Ordner .INBOX aus: Der muss zwar in der IMAP-Hierarchie angegeben werden, wenn ein Ordner unterhalb des Posteingangsordners liegen soll, aber die Mails an sich liegen ja in $MAILDIR.

Meine Filterregeln

Grundprinzip

Eigentlich muss eine Filterregel jetzt "nur" noch $DESTDIR in Abhängigkeit von irgendwelchen Eigenschaften der auszuliefernden Mail setzen:

DESTDIR="$MAILDIR/.INBOX.<Unterordner>"

Und da wir $MAILDIR nicht überschrieben haben, können wir es weiter unten wiederverwenden, wenn wir festgestellt haben, dass die Mail nicht nach .INBOX.<Unterordner> sondern anderswohin gehört:

DESTDIR="$MAILDIR/.INBOX.<Unterordner>.<Unter-Unterordner>"

So weit, so gut. Und wie filtern wir jetzt eigentlich? Momentan komme ich mit vier Typen von Filterregeln aus, nämlich: Local Part, Mailingliste, Empfänger und Absender.

Local Part

Falls mehrere Adressen per .qmail-... im selben Postfach landen, kann man ein Feature von qmail ausnutzen, das eigentlich Mail-Loops verhindern soll: den Delivered-To: Header:

# Filter by incoming local part
if ( /^Delivered-To:.*-adresse1@.*$/:h )
{
  DESTDIR="$MAILDIR/.INBOX.Adresse1"
}
elsif ( /^Delivered-To:.*-adresse2@.*$/:h )
{
  DESTDIR="$MAILDIR/.INBOX.Adresse2"
}
elsif ( /^Delivered-To:.*-adresse3@.*$/:h )
{
  DESTDIR="$MAILDIR/.INBOX.Unterordner.Adresse3"
}

Dabei ist zu beachten, dass vor der eigentlichen Adresse auf jeden Fall der Uberspace-Benutzername und ggf. noch der Namensraum stehen. Ein vollständiger Delivered-To: Header sieht auf Uberspace im Allgemeinen so aus:

Delivered-To: <User>-<Namespace>-<Address>@<domain>.<tld>

Richtig interessant wird das, wenn mehrere Umleitungen per .qmail-... ins Spiel kommen. Grundsätzlich fügt qmail nämlich für jede Umleitung eine Delivered-To: Zeile in den Header ein. Normalerweise sollte aber auch in so einem Fall ein einziger Patternvergleich reichen.

Mailingliste

Wenn ein Mailinglisten-Administrator so nett war, und seine Mailingliste mit einer List-ID: gemäß RFC 2919 ausgestattet hat, kann man solche Mails zum Beispiel folgendermaßen filtern:

# Filter by originating mailing list
if ( /^List-ID:.*<(.*)>/:h )
{
  LIST=tolower($MATCH1)
  if ( $LIST =~ /liste\.erstedomain\.tld/ )
  {
    DESTDIR="$MAILDIR/.INBOX.ErsteDomain"
  }
  elsif ( $LIST =~ /(.*)\.zweitedomain\.tld/ )
  {
    DESTDIR="$MAILDIR/.INBOX.MehrereListen"
    LIST=tolower($MATCH1)
    if ( $LIST =~ /erste-liste/ )
    {
      DESTDIR="$MAILDIR/.INBOX.MehrereListen.EineListe"
    }
    elsif ( $LIST =~ /zweite-liste/ )
    {
      DESTDIR="$MAILDIR/.INBOX.MehrereListen.AndereListe"
    }
  }
  elsif ( $LIST =~ /(.*)\.drittedomain\.tld/ )
  {
      DESTDIR="$MAILDIR/.INBOX.ListenVonDritterDomain"
  }
}

Empfänger

Manchmal gibt es aber auch nicht ganz so nette Listen-Admins. Dann fehlt der List-ID: Header. In dem Fall kann man sich aber möglicherweise den Umstand zu Nutze machen, dass die Mailingliste als Empfänger einer Mail eingetragen ist. maildrop stellt hier sogar die Funktion hasaddr() zur Verfügung, die einem das Parsen eines Headers nach RFC 822 abnimmt:

# Filter by destination
if ( hasaddr("liste1@listen-ohne-id.tld") || \
     hasaddr("liste2@listen-ohne-id.tld") )
{
  DESTDIR="$MAILDIR/.INBOX.ListenOhneID"
}

Aber Achtung: Auch Mails, die z.B. per CC: an die Liste gingen, werden auf diese Weise wegsortiert. hasaddr() sucht nämlich in den To:, Cc:, Resent-To: und Resent-Cc: Headern nach der angegebenen Adresse.

Absender

Man kann natürlich seine Mails auch ganz klassisch nach ihrem Absender sortieren:

# Filter by sender
if ( /^From: (.*)/:h )
{
  ADDR=getaddr($MATCH1)
  if ( $ADDR =~ /.*@example\.com/ )
  {
    DESTDIR="$MAILDIR/.INBOX.Example_com"
  }
  elsif ( $ADDR =~ /.*@example\.org/ )
  {
    DESTDIR="$MAILDIR/.INBOX.Example_org"
  }
}

Noch vor 48 Stunden hätte ich nicht im Traum daran gedacht, einen Blog aufzumachen. Was soll ich schon groß schreiben? Doch dann...

Eigentlich fing die Geschichte schon vor längerer Zeit an: Ich war auf der Suche nach einer Möglichkeit, meine Mails, Kontakte und Kalender selber zu hosten. Ein Freund machte mich damals auf Uberspace aufmerksam, und irgendwann habe ich dann einfach mal ein Konto für mich angelegt. Besondere Erwartungen hatte ich eigentlich keine. Aber was soll ich sagen: ich war hin und weg, von Anfang an.

Nicht nur, dass einem ein vollwertiger Unix-Account zur Verfügung steht. Bei den Tools merkt man zum Beispiel, dass die Jungs sie so eingerichtet haben, wie sie selber gerne damit arbeiten. Und nicht zuletzt der Support: Jede Anfrage wird freundlich und kompetent beantwortet, oft auch außerhalb der "üblichen" Bürozeiten.

Letztlich führte eine solche Anfrage dazu, dass Moritz vom Uberspace-Team meinte, er würde gerne Teile meiner Mailfilter-Konfiguration den anderen Ubernauten zugänglich machen. Oder ob ich das tun wolle, und ob ich nicht einen Blog hätte, in dem ich dazu was schreiben könnte. Hatte ich natürlich nicht.

Das war vorgestern.

In diesem Sinne: To boldly go where no man has gone before...