Als Alternative zum SPF (in der Realität eher als Zusatz) hat sich Microsoft vor einier Zeit das “CallerID-Sender Framework” ausgedacht. Wie bereits sein großer Bruder SPF wird das CallerID-Sender Framework im DNS hinterlegt, und soll dem empfangendem Mail-Server erlauben zu prüfen ob der Absender einer E-Mail bzw. der sendende Host wirklich zur zugehörigen Domain gehört.
Leider scheint es nicht so hüpsche Generatoren wie für SPF zu geben, daher habe ich mir die Beispiele etwas genauer angesehen. Es werden im Einzelnen folgende Fälle behandelt:
Das Framework basiert auf XML-Daten, die als TXT-Record im DNS hinterlegt werden. Lautet die Domain foobar.baz, so lautet der notwendige TXT-Record inkl. seinem Präfix _ep.foobar.baz. Der Präfix _ep. ist dabei wichtig, da der TXT-Record ja nicht generell für das CallerID-Sender Framework verwendet wird.
Das “Drumherum”, um diese XML-Daten lautet generell:
1
2
3
4
5
6
7
| <ep xmlns="http://ms.net/#">
<out>
<m>
</m>
</out>
</ep> |
Nun zu den einzelnen Beispielen.
Für Domains die nur zum Empfangen von E-Mails genutzt werden, bietet es sich an potentiellen Spammern direkt den Hahn abzudrehen.
1
2
3
4
5
6
7
| <ep xmlns="http://ms.net/1">
<out>
<m>
<nomailservers />
</m>
</out>
</ep> |
Die Direktive <noMailservers/> verbietet direkt jeden Empfang von dieser Domain. Sollte diese Domain jemals doch für Mails verwendet werden, so muß dieser Eintrag selbstverständlich angepasst werden!
Wenn der komplette Mail-Verkehr über eine einzelne Maschine abgewickelt wird, und diese auch als MX der Domain eingetragen ist, so reicht die Direktive <mx/>:
1
2
3
4
5
6
7
| <ep xmlns="http://ms.net/1">
<out>
<m>
<mx />
</m>
</out>
</ep> |
Für das Relay-System, über das die Mails für eine spezielle Domain gesendet werden, bietet sich folgender Eintrag an:
1
2
3
4
5
6
7
8
9
| <ep xmlns="http://ms.net/1">
<out>
<m>
<a>
10.11.12.13
</a>
</m>
</out>
</ep> |
In diesem Falle ist nur die IPv4-IP 10.11.12.13 berechtigt Mails zu senden.
Etwas komplizierter, aber immernoch recht einfach sieht es aus, wenn mehr als eine Maschine als Relay verwendet wird:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| <ep xmlns="http://ms.net/1">
<out>
<m>
<a>
10.11.12.13
</a>
<a>
10.11.12.14
</a>
<a>
10.11.12.15
</a>
</m>
</out>
</ep> |
Hier sind die IPs 10.11.12.13, 10.11.12.14 und 10.11.12.15 als Absender von E-Mails erlaubt. Hier findet sich allerdings auch schon das erste Problem: DNS läuft traditionell über UDP-Pakete, und diese sind i.A. 512 Bytes lang. Bei zu vielen IPs die einzeln erlaubt werden, bietet es sich an Ranges (siehe unten) zu nutzen, oder den TXT-Record in mehrere Records aufzusplitten. π x Daumen sollten 10 einzelne IPs ± noch in die Begrenzung passen.
Ein komplettes Subnetz voller Relay-Server kann mit <r> abgebildet werden:
1
2
3
4
5
6
7
8
9
| <ep xmlns="http://ms.net/1">
<out>
<m>
<r>
10.211.30.0/25
</r>
</m>
</out>
</ep> |
Hier wird das komplette Subnetz 10.211.30.0/25 für den Mail-Versand zugelassen. Kleiner Tip aus der Praxis: auch wenn die Kisten in dem Netz nicht alle für Mail verwendet werden, im Normalfall sollte keine davon zur Spam-Schleuder werden, da man die Maschinen ja unter Kontrolle hat haben sollte. So kann man die Begrenzung von <a> auch umgehen.
Das Mail-Relay des ISPs kann selbstverständlich auch genutzt werden; in diesem Fall hilft <indirect> und die Angabe der sendenden Domäne.
1
2
3
4
5
6
7
8
9
| <ep xmlns="http://ms.net/1">
<out>
<m>
<indirect>
interdose.net
</indirect>
</m>
</out>
</ep> |
Das obige Beispiel wälzt also die Verantwortung auf die Server innerhalb der Domain interdose.net ab. Natürlich sollten diese Maschinen dann korrekt gesichert und administriert sein.
Nutzt man hosted E-Mail wie z.B. Google Apps, so ist auch hier die Konfiguration relativ einfach. Zu beachten ist eigentlich nur, daß hier zwei Direktiven kombiniert sind.
<mx/> und <indirect>.
1
2
3
4
5
6
7
8
9
10
| <ep xmlns="http://ms.net/1">
<out>
<m>
<mx />
<indirect>
google.com
</indirect>
</m>
</out>
</ep> |
Damit wäre auch schon ein wichtiger Punkt erreicht: die einzelnen Direktiven kann man kombinieren und auch wiederholt nutzen. So ist z.B. eine mehrfach-Nennung von <indirect> genauso legitim wie von <a> oder <r>. Nur z.B. <mx/> ergibt mehrfach einfach keinen Sinn.
So ist z.B. für meine private Domain folgender Eintrag im TXT-Record eine valide Kombination aus vier Direktiven:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| <ep xmlns="http://ms.net/1">
<out>
<m>
<mx />
<indirect>
google.com
</indirect>
<r>
80.190.170.0/23
</r>
<r>
80.190.172.0/24
</r>
</m>
</out>
</ep> |
Die hüpschen Zeilenumbrüche sind im DNS allerdings nicht vorhanden, da steht dann alles in einer Zeile.
Weiter oben hatte ich bereits davon gesprochen, aber hier nochmals genauer: was tun, wenn ich diese Daten aktualisieren möchte? Das erste Beispiel mit keinem Mailer trifft für die Domain foobar.baz nicht mehr zu, es sollten <r>-Direktiven dazu, allerdings werden TXT-Records ja z.T. sehr lange gecached. Auch hier kann geholfen werden:
1
2
3
4
5
6
7
8
9
| <ep xmlns="http://ms.net/2">
<out>
<m>
<r>
192.168.42.0/29
</r>
</m>
</out>
</ep> |
Na – wer hat’s gesehen? Richtig – die umfassende <ep>-Direktive wurde geändert. Aus xmlns="http://ms.net/1" wurde xmlns="http://ms.net/2" – denn ähnlich wie bei der Zonen-Serial kann diese Zahl beliebig hoch gezählt werden, um eine Aktualisierung des Eintrags anzuzeigen.
Eigentlich ganz einfach, oder?
Interdose
Nach dem Hype den Google mit Wave ausgelöst hat scheint diese Welle bereits gewaltig abgeflacht zu sein; einige sagen sogar Wave war eine Totgeburt. Ob Wave wirklich tot ist oder nicht soll nicht Thema dieses Artikels sein, denn z.B. ich nutze Wave nach wie vor gerne und regelmäßig. 
