Wer einen Greylisting-Filter einsetzt, kennt das Problem: vor allem bei großen Mailprovidern die große Mailserverfarmen betreiben kommt es immer wieder zu Problemen bei der Zustellung der elektronischen Post. Ein Grund hierfür ist oft, dass ein und die selbe E-Mail beim erneuten Zustellversuch von einem anderen Server (und damit mit einer anderen IP-Adresse) ausgeliefert wird und somit das automatische Whitelisting nicht oder nur verspätet funktioniert. Eine manuell gepflegte Whitelist mit solchen “Problemservern” hilft hier — das Ermitteln der Server kann aber bei Anbietern wie GMail oder AOL zum Ratespiel werden. Mit Hilfe von SPF-Einträgen im DNS kann man sich hier viel Arbeit sparen.
Hilft bei der Suche nach den Sende-Mailservern einer Domain oft ein Blick auf die MX-Records im Nameserver führt dieser Ansatz bei großen Anbietern oft ins Leere. So besitzen z.B. Google für ihren GMail-Service oder AOL ganze Serverfarmen die nur für den Mail-Versand eingesetzt werden und sich von den MX-Servern, die den Empfang regeln unterscheiden. Wichtig für ein Whitelisting sind aber die IP-Adressen der Sende-Server. Und hier hilft uns das Sender Policy Framework. Die im DNS hinterlegten SPF-Informationen für Domains erlaubt es uns, die richtigen IP-Adressen der Sende-Server von “Problemdomains” zu ermitteln. Mit dem Programm dig(1) kann man das manuell sehr einfach machen:
$ dig gmail.com TXT +short
»v=spf1 redirect=_spf.google.com«
$ dig _spf.google.com TXT +short
»v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 \
ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 \
ip4:66.102.0.0/20 ip4:74.125.0.0/16 ?all«
Der erste Aufruf von dig ermittelt die TXT-Records der Domain gmail.com. Das Resultat verrät uns, dass es SPF-Einträge gibt und dass wir bitte nochmals für die Domain _spf.google.com anfragen sollen. Genau das wird mit dem zweiten Aufruf von dig auch getan und das Ergebnis sind die gewünschten IP-Adressbereiche der SMTP-Server, die für die Domain gmail.com Mails versenden dürfen.
Gibt es also in Zukunft Probleme mit einigen Domains sollte man zuerst im Nameserver nachsehen, ob dort nicht vielleicht SPF-Einträge vorhanden sind, die man für das manuelle Whitelisting nutzen kann.
Das einfache Auslesen der SPF-Informationen verleitet dazu, das ganze Verfahren zu automatisieren. Und das macht auch Sinn, da es ja auch vorkommen kann, dass Provider etwas an ihren Serverfarmen ändern. Sei es durch hinzufügen oder entfernen von Rechnern und IPs. Das folgende Script erstellt für eine definierte Liste von Domains IP-Listen die man direkt an spamd(8) verfüttern kann:
#!/bin/sh
domains=»_spf.google.com \
aol.com amazon.com \
spf-a.hotmail.com \
spf-b.hotmali.com \
spf-c.hotmail.com \
spf-d.hotmail.com \
_spf-a.microsoft.com \
_spf-b.microsoft.com \
_spf-c.microsoft.com \
s._spf.ebay.com \
m._spf.ebay.com \
p._spf.ebay.com \
c._spf.ebay.com \
securityfocus.com \
kundenserver.de \
mout-bounce.kundenserver.de \
gmx.de \
arcor.de \
byteorder.org«
for domain in ; do
echo »# «
dig TXT +short | tr »\ « »
« | grep ^ip4: | cut -d: -f2
echo »«
done
exit 0
Dieses Script regelmäßig per cron(8) gestartet und die Ausgabe in eine Datei umgeleitet (die man auch noch an pf(4) verfüttern kann) und man kann sich viel Arbeit für die manuelle Pflege der Whitelists sparen.
Das obige Script sucht allerdings nur nach ipv4-Einträgen in den SPF-Informationen, kann aber mit etwas Aufwand so angepasst werden, dass auch andere SPF-Informationen berücksichtigt werden (z.B. für redirect, a oder mx).
»I am root. If you see me laughing, you'd better have a backup!«