Spam und UCE - Filter: SPF, SenderID

Das Prinzip als solches wird oft auch mit anderen Namen wie SPF, RMX, CallerID, DMP, MARID, bezeichnet. Ein ähnliches Konzept verbirgt sich hinter MTAMark.

Meldung vom 23.6 http://www.heise.de/newsticker/meldung/60961 bzw. Telepolis: http://www.heise.de/tp/r4/artikel/20/20411/1.html
"Authentifizier dich oder stirb" Microsoft will seine Antispam-Technik Sender-ID mit der Brechstange durchsetzen.

MSN/Hotmail will bald alle eingegangen Mails, deren Absender sich nicht mit SenderID identifiziert haben, als "potentiell Spam" betiteln. Also können wir davon ausgehen,  dass alle MSN/HotMail User demnächst 99% alle Mails als "potentiell Spam" lesen.
Auch wenn MSN damit ihren Standard forcieren möchten, so würde ich mir als Anwender eher die Umkehrung wünschen. Nachrichten von Sendern, die per SPF oder SenderID ihre Identität bestätigen, könnten mit einem Zusatz "Absender nicht gefälscht" versehen werden.

Update:
Angeblich sind aktuell 87% aller Domains, die mit SPF bzw. SenderID gekennzeichnet sind, Spamversender. Es ist schön zu wissen, dass die Domäne nicht gefälscht ist, aber solange jeder für 1 Euro ohne Identifizierung (Kreditkarten können gestohlen sein) eine Domäne kaufen, müssen Mails senden und wieder abmelden kann, sind diese Filter kein Schutz gegen Spam, sondern nur ein Schutz gegen "Phishing". Nur nutzen es die meisten Banken noch nicht und nur wenige Mailserver prüfen die Existenz von SPF/SenderID-Records.

Update:
Laut einem Microsoft Artikel stammen bereits 30% aller Mails  im Internet von Domänen, die einen SPF-Record veröffentlichen.

Achtung mit SubDomains:
Ein DMARC-Eintrag auf einer Domäne gilt auch für Subdomains !. DMARC-Prüfer haben dazu eine Liste der "Root-Domains", um z.B. "<firma>.de" von "<firma.co.uk>" zu unterscheiden. Ein SPF-Eintrag hingegen wirkt nur auf die Domains selbst. Versenden Sie auch Mails mit Unterdomänen, z.B. "info@crm.<firma>.de", dann müssen Sie auch für die Subdomains entsprechende Einträge setzen. Ein einfacher Weg ist dabei der Eintrag eines REDIRECT-Eintrags im DNS

"v=spf1 redirect=example.com"

So funktioniert es

Einen ganz anderen Weg gehen die Verfahren wie "Sender Policy Framework" oder CallerID. Das Ziel ist hierbei die Fälschung von Absenderadressen zu verhindern, d.h. über Einträge im DNS veröffentlicht eine Firma zugleich die IP-Adressen der ausgehenden Mailserver. Jeder Empfänger kann daher beim Empfang einer Mail feststellen, ob die absendende IP-Adresse dazu legitimiert ist und gegebenenfalls die Verbindung kappen.

Technisch wird dazu im DNS nicht nur ein Eintrag für eingehende Mails gepflegt,  sondern auch ein Eintrag, der die ausgehenden Mailserver beschreibt. Hier am Beispiel von Net at Work. (Die Abfrage erfolgt über einen DNS-Server der Telekom (Ich habe einen DSL-Anschluss genutzt).

Nachdem ich NSLOOKUP gestartet habe, habe ich die Anfrage auf "TXT" umgestellt und dann zwei Werte abgefragt:

  • _ep.netatwork.de (SenderID)
    Diese Anfrage liefert den Eintrag "_ep" der Domäne und ist ein Datensatz nach dem Microsoft Standard Sender-ID. Sie bekommen einen String, der ähnlich einer XML-Datei aufgebaut ist. Der ausgehende Mailserver für Adressen mit der Domäne "netatwork.de" ist die IP-Adresse 80.66.20.18.

<ep xmlns='http://ms.net/1' testing='false'>
    <out>
        <m>
            <a>80.66.20.18</a>
        </m>
    </out>
</ep>"

  • netatwork.de (SPF)
    Diese Abfrage liefert alle Texteinträge für die Domäne. In diesem Beispiel ist es genau ein Eintrag, der ebenfalls die ausgehenden Mailserver beschreibt. Bei SPF haben wir aber nicht nur die IP-Adresse, sondern auch einen Namen und generell die IP-Adresse als ausgehend definiert, die auch als eingehend (MX-Record) genutzt wird. Alle anderen Adressen sind nicht erlaubt

"v=spf1 mx a:rmx.netatwork.de ip4:80.66.20.18 -all"

Anhand dieser Informationen ist erkennbar, welche IP-Adressen und welche Server ausgehende Nachrichten für eine vorgegebene Domain senden. Es liegt natürlich nun an ihrem eigenen Mailserver, bei einer eingehenden Nachricht eben die Domäne der Absenderadresse zu nehmen und über DNS nachzufragen, ob die einliefernde IP-Adresse dazu passt.

Das ist natürlich nur eine "Einfachversion" eines Records. Es ist problemlos möglich, auch Subnetze zu spezifizieren oder andere Adressen per "Include" einzuschließen. Interessant ist der letzte Abschnitt, welcher die Behandlung für nicht gelistete IP-Adressen festschreibt.

  • +all  (PASS)
    Dieser Eintrag ist eigentlich überflüssig, weil er einfach nur sagt, das alle anderen IP-Adressen ebenfalls erlaubt sind. Ein Empfänger kann also nichts mit der Information anfangen.
  • ?all (NEUTRAL)
    Auch diese Einstellung ist eigentlich überflüssig, da der empfangende Server die Mails von fremden IP-Adressen ebenfalls annehmen soll, da der Absender nicht sicherstellen kann oder will, welche IP-Adressen aufgeführt werden. Insofern hätte sich der Administrator der Absenderdomain auch gleich den Aufwand sparen können.
  • ~all (SoftFail)
    Dies bewegt sich etwas zwischen "NEUTRAL" und "FAIL". Als Empfänger sollten Sie die Mails von nicht aufgeführten Adressen anhand anderer Kriterien noch bewerten und eventuell blocken. Es soll auch Administratoren geben, die auch hier die Mails abblocken. Schließlich bekommt der Absender eine Info, dass er nicht autorisiert ist und kann sich beim Betreiber des Mailservers beschweren.
  • -all  (FAIL)
    Alle anderen IP-Adressen sind keine gültigen Versender. Als annehmendes System sollten Sie daher die Mails ablehnen. Auch wenn dieser Eintrag eigentlich der "einzig Richtige" wäre, nutzen nur wenige Domänen aktuell diese scharfe Einstellung. Vermutlich haben die Administratoren einfach Angst, nicht alle ausgehenden Systeme aufgeführt zu haben.

Sinnvoll ist daher nur ein "-all", um eine Zustellung durch nicht autorisierte Mailserver aktiv zu verhindern. Details siehe auch http://www.openspf.org/svn/project/specs/rfc4408.txt

Eine nicht fälschbare Absenderadresse verhindert zwar keine Spamnachrichten, aber über einfach Blacklisten können die unerwünschten Domänen dann einfach gefahrlos blockiert werden. Der Aufwand (und die Kosten) für einen Spammer steigen. Firmen mit dynamischen IP-Adressen oder die ihre Webseite bei einem Hoster betreiben werden sich jedoch etwas einfallen lassen müssen. Entweder trägt der Provider die Records ein, wodurch Sie immer das Relay des Providers nutzen müssen. Hierfür wird der Provider sicher Geld verlangen, da er ihre Mails zusätzlich übertragen muss. Alternativ könnten Sie über DDNS diese Einträge aktualisieren. DynDNS erlaubt dies z.B.: schon.

Einträge generieren

Es ist nicht jedermanns Sache nun einen SPF oder Sender-ID-Eintrag einfach mal so zu entwerfen. Zum Glück gibt es entsprechende Webseiten, die bei der Erstellung der erforderlichen DNS Einträge helfen wie:

Die Ergebnisse müssen Sie dann aber immer noch in ihrem DNS-Server eintragen. Hoffentlich erlaubt ihr Provider diese Einträge und Sie haben nicht gerade einen dynamischen DNS-Eintrag

Einträge bei 1und1

Die Webseite msxfaq.de läuft schon seit dem Jahr 2000 bei 1und1. Auch hier sind TXT-Einträge möglich. Interessant ist, dass 1und1 am Anfang 2016 eigenständig entsprechende SPF-Records addiert hat. Das wird wohl damit begründet, dass man die Kundendomains gegen Spoofing schützen möchte. Nur Firmen, die ihre Domain zwar bei 1und1 hosten aber einen eigenen Mailserver betreiben und den MX-Record passend umgestellt hatten, müssen hier natürlich nachsteuren.

1und1.de        text = "v=spf1 include:_spf.1und1.de -all"
carius.de       text = "v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de -all"
msxfaq.de       text = "v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de -all"

Sie sehen anhand des SPF aber auch, dass 1und1 selbst wohl andere ausgehende Mailserver verwendet als die Server der Kunden. Dennoch ist es für vermutlich die meisten Kunden, die über die Mailserver von 1und1 per IMAP/POP und SMTP arbeiten, ein Gewinn, weil ihre eigene Domäne eben nicht mehr so einfach missbraucht werden kann. Wer hingegen einen eigenen Mailserver betreibt, sollte schon lange sich über einen eigenen SPF-Eintrag Gedanken gemacht haben.

Eigentlich fehlt nun nur noch die automatische Pflege eines DMARC-Records und der Einsammlung der Feedbacks um den Schutz weiter zu verbessern.

Probleme

Problematisch ist hierbei, dass es noch lange Zeit dauern wird, bis alle Domains der Welt diese Informationen veröffentlichen und bis dahin diese Liste nur als "Whitelist" genutzt werden kann aber noch nicht zur Blockade von Verbindungen. Leider kommt hinzu, dass die verschiedenen Interessengruppen unterschiedliche Vorschläge als Standard absegnen lassen wollen.

Aber auch technisch gibt es sicherlich das ein oder andere zu bewältigen. Wenn Sie ihre Mails nicht direkt, sondern über einen Provider erhalten, oder wenn der Provider nur einen BackupMX zur Verfügung stellt, dann muss ihr System auch damit umgehen können. In diesem Fall erhalten Sie die Mail nämlich nicht direkt von dem entfernten Server, sondern vom Relay. Die Auflösung der Domäne zu IP-Adresse funktioniert dann natürlich nicht.

Probleme, die ebenfalls schon bei mir aufgetreten sind, sind automatische Weiterleitungen Wenn ich eine Mail an "firma1.de" sende und diese dort an "firma2.de" weitergeleitet wird, dann bekommt der Mailserver von fima2.de diese Mail von der IP-Adresse von firma1.de und nicht mehr von mir. Aber die "MAIL FROM"-Zeile im SMTP-Envelope kann durchaus meine Adresse sein, je nach Art der Weiterleitung. Habe ich dann SPF-Einträge im DNS veröffentlicht, dann kommt es z.B.  zu folgendem Fehler:

Der Mailserver, welcher die Mail weiterleitet, muss entsprechend die "MAIL FROM"-Adresse im SMTP-Protokoll (Siehe SMTP-Telnet) umstellen

Listserver und Weiterleitungen

Ein weiteres Problem, auf welches Sie bei einem SPF-Check stoßen können, sind Weiterleitungen und Listserver. Hier kann das folgende passieren:

  • Mail an Kontakt
    Bei den meisten Mailsystemen können Sie Kontakte, einen Alias oder Weiterleiter definieren. Eine Mail von Extern an dieses Konto wird dann an eine andere Mailadresse weitergegeben, die sowohl intern als auch extern sein kann. Oft leiten Die Mailsysteme diese Nachricht natürlich mit der originalen Absenderadresse weiter. Hat der Absender nun einen SPF-Record gepflegt, dann versucht nun das System mit dem Weiterleiter im Namen des originalen Absenders zu senden. Überprüft das Zielsystem nun den SPF-Eintrag,  dann wird es die Mail ablehnen.
  • Verteilerliste und Listserver
    Viele Firmen nutzen z.B. Exchange Verteiler um Nachrichten an viele Personen zu addieren. Dazu können Sie im Active Directory eine Gruppe anlegen, in der auch externe Empfänger (Kontakte) Mitglied sein können. Als Folge wird eine Mail von einem externen Mitglied an diesen Verteiler natürlich auch wieder an alle Mitglieder verteilt. Auch hier kommt ohne besondere Vorkehrungen natürlich wieder die originale Absenderadresse zum Einsatz.

In beiden Fällen muss der Mailserver daher die Absenderadresse umschreiben, damit die Mails auch tatsächlich zugestellt werden kann. Exchange 2003 schreibt die Mail leider per Default nicht um. Dies kann aber über ein AddOn erreicht werden:

  • 915863 Messages that are sent through Exchange 2003 to an external messaging server are blocked by Sender ID checking
    Sender Rewriting um Mail an eine Dlist/Kontakt nach Extern umzuschreiben, dass SPF funktioniert.

Verbesserung erwünscht

Ich würde (auch wenn es keinen Standard gibt) auch den Download dieser Informationen per HTTP unterstützen wollen. Firmen, die keine Hoheit über ihren DNS haben, haben aber oft die Hoheit über ihre Webseite. Daher könnte z.B.: ein http://www.firma.de/_ep.txt oder http://www.firma.de/spf.txt ebenfalls die Informationen als TXT-Datei oder XML-Struktur liefern. Das Verfahren ist übrigens nicht sonderlich neu, da auch Suchmaschinen über eine Datei robots.txt gesteuert werden können.

Die großen Provider und ihre Einstellungen.

Nun könnte man denken, dass die Firmen, die ihr System besonders preisen, dies auch einsetzen. Entsprechende Datensätze sind bei den großen Providern zwar schon gepflegt aber bei weitem nicht perfekt. Hier ein paar Beispiele (Ende Nov 2005)

Firma (Typ)

DNS-Information

Bewertung
Microsoft SenderID

_ep.Microsoft.com text =

"<ep xmlns='http://ms.net/1' testing='true'><out><m>"
"<mx/><a>213.199.128.160</a>
<a>213.199.128.145</a>
<a>207.46.71.29</a>
<a>194.121.59.20</a>
<a>157.60.216.10</a>
<a>131.107.3.116</a>
<a>131.107.3.117</a>
<a>131.107.3.100</a>"
"</m></out></ep>"

Microsoft hat zwar nur ein paar IP-Adressen als ausgehende Server angegeben, aber durch die Einstellunge "testing='true*" wird allen Gegenstellen laut Definition gesagt, dass dies eventuell nicht alle Server sind und andere IP-Adressen auch erlaubt sein sollten. Die Information kann also nur genutzt werden, um z.B.: Mails von diesen Adressen als "ungefälscht" zu kennzeichnen. Ablehnen sollten Sie keine Mail von Microsoft, wenn Sie von anderen Adressen kommt
Microsoft SPF

"v=spf1 mx redirect=_spf.Microsoft.com"

_spf.Microsoft.com text = "v=spf1 ip4:213.199.128.139
ip4:213.199.128.145 ip4:207.46.50.72
ip4:207.46.50.82 ip4:131.107.3.116
ip4:131.107.3.117 ip4:131.107.3.100 ip4:131.107.3.108 a:delivery.pens.Microsoft.com
a:mh.Microsoft.m0.net mx:Microsoft.com ?all"

Zusätzlich pflegt Microsoft auch einen SPF-Record.

Dieser erlaubt alle Mailserver, die auch als MX-Record eingetragen sind.  Zusätzlich ist ein SPF-Alias eingetragen, der ebenfalls die IP-Adressen listet.

Auch hier bedeutet das "?all" am Ende, dass es noch andere Server geben kann.

Yahoo.com SenderID

_ep.yahoo.de canonical name = rc1.vip.ukl.yahoo.com
rc1.vip.ukl.yahoo.com internet address = 217.12.6.29

Das ist eigentlich schon sehr gut. Eine einzige IP-Adresse ist für den ausgehenden Versand.

Einen SPF-Record bietet Yahoo aber nicht an.

AOL.COM SPF

 "spf2.0/pra ip4:152.163.225.0/24
ip4:205.188.139.0/24 ip4:205.188.144.0/24
ip4:205.188.156.0/23 ip4:205.188.159.0/24
ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

"v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24
ip4:205.188.144.0/24 ip4:205.188.156.0/23
ip4:205.188.159.0/24 ip4:64.12.136.0/23
ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

AOL bietet sogar beide SPF-Versionen an.

Irritierend ist aber die Größe der Subnetze, die AOL hier als "ausgehend" definiert. Ob AOL wirklich über 2000 ausgehende Mailserver hat ?.

Zudem sind auch die AOL-Administratoren sich wohl  nicht sicher,  welche Mailserver Nachrichten mit Absendern "aol.com" versenden. Das "?all" entwertet die Daten.

Ein SenderID-Eintrag wird nicht veröffentlicht.

GMX.NET SPF
"v=spf1 ip4:213.165.64.0/23 -all"
Auch GMX veröffentlicht zumindest einen SPF-Record für die eigenen Mailserver. Allerdings die GMX auch einer der wenigen großen Provider, die mit dem "-all" es den Empfänger leicht macht, andere IP-Adressen abzulehnen. Gut so.
Hotmail

 "v=spf1 include:spf-a.hotmail.com
include:spf-b.hotmail.com include:spf-
c.hotmail.com include:spf-d.hotmail.com ~all"

spf-a.hotmail.com text =

"v=spf1 ip4:209.240.192.0/19
ip4:65.52.0.0/14 ip4:131.107.0.0/16
ip4:157.54.0.0/15 ip4:157.56.0.0/14
ip4:157.60.0.0/16 ip4:167.220.0.0/16
ip4:204.79.135.0/24 ip4:204.79.188.0/24
ip4:204.79.252.0/24 ip4:207.46.0.0/16
ip4:199.2.137.0/24 ~all"

_ep.hotmail.com text =

"<ep xmlns='http://ms.net/1' testing='true'><out><m><indirect>list1._ep.
hotmail.com</indirect><indirect>list2._ep.hotmail.com</indirect><indirect>list3.
_ep.hotmail.com</indirect></m></out></ep>"

Hotmail hat wie Microsoft und MSN auch wieder "Testing = true" gesetzt und entwertet damit die Daten.

Viel schlimmer ist aber die Auswertung der eingeschlossenen Adressen.

Eine Auswertung auf spf-a.hotmail.com liefert riesige Subnetze. Anscheinend erlaubt Microsoft alle IP-Adressen, die auch an Endkunden vergeben werden, den direkten Versand mit beliebigen "hotmail"-Adressen, ohne ein Relay oder weitere Authentifizierung.

Da hat jemand sicher nicht das Prinzip verstanden.

Zudem veröffentlicht Hotmail auch einen SenderID-Record, dessen verweisende Adressen allerdings nicht auflösbar sein.

WEB.DE
 "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.248/29 ip4:82.165.159.0/26 ip4:217.72.207.0/27 -all"
 
T-Online.de Keine Daten zu SPF oder SenderID veröffentlicht

Dieser kurze Test zeigt, dass auch die großen Provider sehr uneinig für die Nutzung dieser Technik und die Interpretation der Daten sind. So scheint bei Hotmail die "Funktion" vor der Nutzung zu überwiegen, während andere Provider zwar ihre Mailserver angeben, aber ebenfalls nicht wirklich sicher zu sein scheinen. Es bleibt noch viel zu tun.

NDR-Spam durch SPF

SPF und ähnliche Verfahren erlauben ja schon sehr früh bei der Verbindung die Gültigkeit der angegebenen "MAIL FROM"-Adresse zu prüfen. Entsprechend können Mailserver bei einer Verletzung die Verbindung mit einem Fehler einfach ablehnen. Solange der Spammer selbst direkt versendet und einen halbwegs sinnvoll konfigurierten Mailserver einsetzt, wird er die Mail nicht los und sonst passiert nichts weiter.

Leider sind sowohl Spammer als auch offene Relays ein Problem bei diesem frühen Ablehnen, welches ich auch als NDR Spamming beschrieben habe. Der Mailserver, welcher die Nachricht nicht zustellen kann, muss gemäß der RFC die Nachricht mit einer Quittung, bzw. einer "Unzustellbarkeitsquittung" an den Absender zurück melden. Dazu muss der Mailserver natürlich wissen, dass er selbst die Mail von einem "vertrauenswürdigen" Absender erhalten hat. Das machen offene Relays natürlich nicht und viele Mailserver, die von Spammern verwendet werden, senden auch munter NDRs. So finde ich dann ab und an Nachrichten wie die folgende in meinem Postfach.

Da hat also wohl der Postfix unter "seguin.cyframe.com" eine Unzustellbarkeitsquittung an mich gesendet, weil er eine Mail in meinem Namen an mail2.vip.su senden wollte, welcher diese aufgrund der SPF-Prüfung abgelehnt hat. Ob seguin.cyframe.com nun selbst der Spammer ist oder nur ein offenes Relay, habe ich nun nicht weiter untersucht.

Aber es ist auch hier gut ersichtlich, dass ein Spamfilter auch "Quittungen" analysieren" sollte und nur die Quittungen passieren dürfen, die eine Antwort auf eine ausgehende Nachricht darstellen können.

SPF mit 1und1

SPF ist ja nicht nur dafür da, dass der Empfänger den Absender prüfen und Spam abwehren kann. Aber interessant ist natürlich auch der Schutz des "Namens" des Absenders. Ich möchte z.B. nicht, dass jemand als "@msxfaq.de" Mails versendet und damit sich "als Frank" ausgibt. Daher habe ich bei mir natürlich auch die entsprechenden Einträge gesetzt. Wenn ihr Mailserver diese Einträge überprüft, können Sie zuverlässig verhindern, eine Mails von einem nicht autorisierten Server zu bekommen.

"v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de -all"
  • OVH
    Eine Testdomäne ist bei OVH gehostet, da dieser Provider z.B. DNSSEC unterstützt. OVH macht es sogar besonders einfach. Sie können einfach einen TXT-Record addieren, aber ebenso einen SPF-Assistenten nutzen, der die Eingabe der einzelnen Werte erlaubt und den SPF-Eintrag generiert oder sie können mit einem Klick die "OVH-Defaults" eintragen lassen.
"v=spf1 include:mx.ovh.com ~all"
  • HostEurope.de
    Historisch bedingt laufen auch noch einige Domains bei HostEurope, welche auch SPF unterstützen
"v=spf1 a mx ip4:80.237.138.0/24 ip6:2a01:488:42::/48 -all"

Wenn Sie nun fragen, warum die Provider zwar die DNS-Einträge für WebServer und MX-Records alleine setzen aber SPF eben nicht, muss sich einfach überlegen, dass jeder Kunden ja selbst entscheiden kann, ob er die Mails über den Provider versendet, bei dem auch die eingehende Mail ankommt oder er einen anderen Weg nutzt. Häufig sind dies insbesondere Newsletter-Versender oder Firmen, die bei einem anderen Provider noch Dienste hosten, die auch mit der Domain Mails versenden. Insofern muss ein Kunde hier schon selbst sich hinsetzen und die Systeme identifizieren, die Mails versenden und diese alle im SPF-Record aufführen.

Weitere Links