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,
Massenmails 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.
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 (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 Admins einfach Angst, nicht alle ausgehenden Systeme aufgeführt zu haben. - ?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.
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.
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 = |
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 |
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 |
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 "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 |
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 spf-a.hotmail.com text = _ep.hotmail.com text = |
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 | Keine Daten zu SPF oder SenderID veröffentlicht |
| 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.
NDRSpam 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.
Weitere Links
- 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. - RFC4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in
E-Mail, Version
http://www.openspf.org/svn/project/specs/rfc4408.txt - How to configure Sender of Policy Framework records in the Windows Server 2003 Domain Name System http://go.Microsoft.com/?linkid=4694399
- Exchange 2007 - Bekämpfen von SPAM und Phishing mit Sender ID
http://www.microsoft.com/technet/technetmag/issues/2006/12/SIDF/default.aspx?loc=de/ - SPF - Sender Policy Framwork
http://spf.pobox.com/ - RMX - reverse MX
http://www.mikerubel.org/computers/rmx_records/ - CallerID/SenderID
http://www.Microsoft.com/mscorp/twc/privacy/spam_callerid.mspx
http://www.Microsoft.com/spam
www.Microsoft.com/senderid
http://www.Microsoft.com/athome/security/email/sender_id.mspx
SenderID in Exchange 2003 SP2
http://msexchangeteam.com//archive/2005/10/13/412487.aspx -
Exchange Server 2003 Service Pack 2 (SP2) anti-spam features - order of
execution
http://msexchangeteam.com//archive/2005/08/24/409730.aspx -
Exchange 2003 Server Service Pack 2 (SP2) Anti-Spam Framework
http://msexchangeteam.com//archive/2005/07/18/407838.aspx - Exchange 2007 - Bekämpfen von SPAM und Phishing mit Sender ID http://www.microsoft.com/technet/technetmag/issues/2006/12/sidf/default.aspx?loc=de
- DMP - Designated Mailer Protocol
http://www.pan-am.ca/dmp/draft-fecyk-dmp-01.txt - MARID - MTA Authorization Records in DNS
http://www.ietf.org/html.charters/marid-charter.html - MTAMark
- http://de.wikipedia.org/wiki/Sender_Policy_Framework
- SPF Für Exchange
GFI Freeware http://www.gfisoftware.de/news/de/mes101launch.htm
SPF als Event Sink http://sourceforge.net/projects/spf-event-sink
Spam Assassin und andere "Vorschaltmodule" - SPF Wizard
http://spf.pobox.com/wizard.html - SenderID Wizard
http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx - SPF-Eintragsgenerator
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
