Spam und UCE - Filter: MTAMARK
Erstmalig gelesen habe ich von diesem Filter in der iX 5/2005 auf Seite 129
So funktioniert es
Im Internet können die Betreiber eines Mailservers einliefernde Systeme in zwei Klassen einteilen:
- Mailserver
Dies sind Systeme, die Mails für Firmen annehmen und an interne Postfächer verteilen und ihrerseits die Nachrichten interner Mitarbeiter annehmen und in das Internet versenden. - Clients
Dies sind PC's, an denen der Anwender arbeitet und seine Mails vom Mailserver bezieht (z.B. per POP3, IMAP4) und Antworten ebenfalls per SMTP an den Mailserver zurücksendet.
Normalerweise sprechen nur Mailserver miteinander. Versendet ein Absender eine Mail, so wird die von einem Client Arbeitsplatz erfolgen. Dieser Arbeitsplatz sendet die Mail an den Mailserver des Providers, der die Mail dann an den Mailserver des Empfängers weiterleitet. Es ist daher eigentlich nicht erforderlich, dass ein Endanwender direkt per SMTP eine Verbindung zu einem Mailserver aufbaut. Einige Provider sperren z.B. den Port 25, so dass Endanwender nicht direkt Mails versenden können. (Seit 1998 gibt es hierzu sogar eine RFC2476 - Message Submission, die den Port 587 für die Einlieferung von Nachrichten von Clients an den Server vorschlägt)
Spammer hingegen nutzen sehr oft die Anonymität von dynamischen Verbindungen, DSL oder Kabel-Netzwerken mit dynamischen IP-Adressen. Hinter diesen Adressen verbergen sich normalerweise nur Clients und diese senden ihre Mails per SMTP an den Server mit dem Postfach des Anwenders. Sie sollten daher nicht direkt an andere Mailserver senden.
MTAMARK basiert nun darauf, dass im DNS hinterlegt wird, von welcher IP-Adresse ein Mailserver seine Nachrichten versendet.. Damit ist dieser Ansatz nicht so weit gehen wie die Lösungen SPF/CallerID. Aber was hilft ein sehr gutes System, wenn es nicht einfach umzusetzen ist. Oft ist eine kleinere Lösung, die schnell umzusetzen ist. Das Sprichwort vom "Spatz in der Hand statt der Taube auf dem Dach" ist sicher jedem bekannt. Wenn nun alle Mailserver im Internet eine feste IP-Adresse hätten und im DNS auch als SMTP-Server gekennzeichnet wären, dann könnten alle Mailserver der Welt eingehende Verbindungen von nicht entsprechend gekennzeichneten IP-Adressen ablehnen.
Technisch ist dies ganze über DNS, bzw. genauer "Reverse DNS" realisiert. Über reverse DNS kann zu einer IP-Adresse ein Name aufgelöst werden. Über entsprechende Service Einträge kann damit auch die Funktion "SMTP" eingetragen werden:
_send._smtp._svr.1.2.168.192.in-addr.arpa IN TXT "1" _send._smtp._svr.2.2.168.192.in-addr.arpa IN TXT "0"
Diese Einträge teilen der Welt mit, dass die IP-Adresse 192.168.2.1 einen SMTP-Server betreibt während von 192.168.2.2 niemand eine Mail annehmen sollte. Eine Qualifizierung von einliefernden Systemen könnte natürlich auch über Listen wie RBL oder DUL erfolgen, aber MTAMARK hat den Vorteil, dass viel weniger IP-Adressen in der Datenbank (hier DNS) hinterlegt sein müssen.
Probleme
MTAMARK ist sehr ähnlich zu SPF und SenderID. Auch hier wird der absendende Server qualifiziert. Entsprechend sind auch die Probleme von MTAMARK:
- Firmen und dynamische IP-Adressen
Leider missbrauchen nicht nur Spammer die Verbindung über solche Zugänge, sondern auch immer mehr Firmen nutzen die günstigen DSL-Zugänge mit dynamischer Adresse (Siehe auch Exchange und dynamischem DNS und Exchange und T-Online/T-DSL). Insofern wird es auch zukünftig immer Server geben, die hinter einer IP-Adresse stehen, die nicht mit einem MTAMARK als Server gekennzeichnet ist. Solche Firmen können daher nur dann eine Mail an einen MTAMARK-prüfenden Server senden, wenn Sie die Mails über einen Provider versenden, der seine Server entsprechend markiert hat. Es liegt dann beim Provider über SMTP-Authentifizierung oder andere Wege sicher zu stellen, dass sein Server nicht zum Spam missbraucht wird. - MTAMARK Unterstützung bei Mailservern
Aber selbst wenn die IP-Adressen alle Mailserver mit einem MTAMARK versehen sind wird es noch sehr lange dauern, bis dann auch die Firmen ihre Mailserver entsprechend umkonfiguriert haben. Bei den zig tausend wenn nicht gar Millionen von Mailservern wird es sehr lange dauern. Sicher werden große Provider sehr schnell MTAMARK implementieren können, allerdings - Offene Relays
Solange es noch Tausende von offenen Relays gibt, werden Spammer diese weiter benutzen und sich besonders freuen, wenn der Betreiber seinen "Mailserver" über entsprechende DNS-Einträge markiert hat. Hier kann dann weiterhin nur mit entsprechenden Sperrlisten (RBL) gearbeitet werden. - Spammer mit fixer IP-Adresse
Wer eine feste IP-Adresse hat, ist zwar einfacher auszumachen und über Blocklisten auch einfacher auszusperren, aber auch heute gibt es viele Provider, die ihr Geld auch von Spamversendern bekommen. Würde ein Provider mit einem Massenversender wirklich Verlust machen, wäre es für ihn ein leichtes, diesen Kunden zu blockieren. Dies passiert aber nicht. Und es gibt heute schon Spamversender, die dies ganz offiziell mit einer festen IP-Adresse tun und damit auch mit MTAMARK keine Probleme haben werden. - Reverse DNS
Das aus meiner Sicht aber größte Problem ist die Pflege des Reverse DNS. Sehr viele Provider erlauben es nicht, dass ein Kunde seine IP-Adressen im Reverse DNS pflegt. Die meisten Provider lassen es auch nicht zu, dass die delegierten IP-Adressen auch im Reverse DNS delegiert werden. Allerdings muss man den Providern auch zugute halten, dass es nicht viele Administratoren gibt, die ein "classless reverse DNS" korrekt konfigurieren können. Insofern wird es bei sehr vielen Firmen einfach an den Möglichkeiten scheitern, ihre IP-Adresse des Mailservers als "MTA" zu markieren. Und solange dies nicht bei vielen Servern passiert, ist die Aussagekraft einer MTAMARK nur sehr bedingt für Spamschutz geeignet.
Insofern ist MTAMARK ähnlich wie SPF/CallerID ein interessanter Ansatz, aber meiner Meinung nach nicht sehr hilfreich. Allein die Markierung einer IP-Adresse als "Mailserver" ist zwar sehr viel einfacher als SPF/CallerID und damit theoretisch auch schneller umzusetzen, aber auf der anderen Seite dürfte dies keinen Spammer wirklich hindern, da MTAMARK nicht als Kriterium zur Blockade genutzt werden kann und als Kriterium für eine positive Bewertung ist MTAMARK auch wenig geeignet.
Weitere Links
- http://mtamark.space.net
- RFC 2476 - Message Submission
http://www.faqs.org/rfcs/rfc2476.html - SPF/CallerID
- DUL
- Classless Reverse DNS
www.Microsoft.com/technet/prodtechnol/windows2000serv/plan/w2kdns2.mspx - DNS Whitepaper
http://download.Microsoft.com/download/f/2/f/f2fc9f59-d90a-4dbc-8382-793c88b0b0d2/w2kdns.doc - RFC 2317 - Classless IN-ADDR.ARPA delegation
http://www.faqs.org/rfcs/rfc2317.html