RMX Records - die tiefreichende Vorbeute gegen Spam

[cycomate]

<blockquote>
Von Adressfälschern und einem, der auszog, jenen das Fürchten zu lehren
Wer kennt sie nicht, die abertausenden von Spam mails, die von ewwoimrcrax[at]aol.com oder makemoney4711[at]netscape.net hereinkommen, aber ganz heimlich nicht von den Personen geschickt wurden, denen möglicherweise diese email Adressen gehören? Wer kennt nicht die Unmengen an bounces, die morgens die inbox bevölkern - bounces auf Nachrichten, die man nie geschickt hat? Oder beim wem klopft ein gewisser Swen nicht täglich ans Postfach?
Jeder kann eine email unter beliebigem Absender verschicken. Diesen Umstand machen sich besonders Spammer zunutze - so setzten die Spammer in der Anfangszeit noch brav ihre eigene email Adresse ein, bis die ersten Filter aufkamen, die genau diese Adressen blockierten. Die Spammer reagierten, indem die email Adressen verfälscht wurden: zunächst benutzte man ungültige domains, als jedoch auch diese gefiltert wurden, mußten Adressen größerer Provider als vermeintliche Absender herhalten.
Hadmut Danisch kennt die Lösung des Problems. Zugegeben, die Lösung ist weder neu noch krempelt sie alles bisher dagewesene um - aber sie ist effektiv, und darauf kommt es an.
Danisch macht sich die Tatsache zunutze, daß email Provider ohne Authentifizierung - sei es via SMTP AUTH, SMTP-after-POP, o.ä. - keine emails relayen (sollten) und der Adressfälscher somit einen alternativen SMTP Server benutzen muß, z.B. ein open relay oder die SMTP engine des klick-and-spam Programmes, welche dann über seinen dialup host sendet.
Die Idee ist, eine Gegenprüfung des Absenderhosts zur Absenderdomain durchzuführen. Hier kommt der RMX Eintrag ins Spiel.
Der Domaininhaber setzt dazu etwa folgenden RR im zuständigen DNS:
domain.tld. IN RMX host:relayhost.provider.tld
Es gibt noch andere Varianten, etwa für IPv4|6 Adressen oder APL (address prefixes list), aber ich möchte hier nicht zu sehr ins Detail gehen. Dem geneigten Leser möchte ich daher die Quelle[1] und eine gut illustrierte Beschreibung des Verfahrens[2] nahelegen.
Versucht man nun, eine email mit einem Absender der domain `domain.tld` zu verschicken, schaut sich der MTA des Empfängers zunächst den domain part der im MAIL FROM angegebenen Adresse an und fragt den für diese domain zuständigen DNS Server nach dem RMX Eintrag. Diesen widerum vergleicht er mit dem Absenderhost und akzeptiert die email nur, wenn der Absenderhost positiv in den RMX Einträgen auftaucht.
Schon früher versuchte man mit entsprechenden Bordmitteln der MTA etwas derartiges zu erreichen, was dann auch mehr oder weniger funktionierte. Prominentestes Beispiel ist hier wohl die Kombination aus check_sender_access und check_client_access unter Postfix, welche unter [3] beschrieben ist. Nachteil dieser Konstuktion ist, daß hier domains zusammengefaßt werden und Kreuzverbindungen der ACL möglich sind.
Diese neue Methode könnte ein entscheidener Meilenstein in der Spamprävention sein. Andererseits gibt es auch Kritik. So ist es nicht mehr ohne weiteres möglich, ein einzelnes SMTP relay zu nutzen, um unter verschiedenen Absenderadressen zu mailen, auch wenn das relay es theoretisch erlaubt (etwa nach SMTP Auth auf eine Prüfung des Absenders verzichtet). Nunmehr braucht man für jede domain der Absenderadressen ein dafür vorgesehes SMTP relay - was aber für aktuellere Email Programme kein Problem darstellen sollte und auch über die transports Anweisung der MTA realisiert werden kann.
Unbequem wird es auch für jemanden, der direkt über seinen eigenen Mail server ausliefern möchte. Da in der Regel seine Absender IP nicht in den RMX Einträgen auftauchen wird, ist derjenige gezwungen, das mail relay des Providers zu nutzen.
Auch Benutzer von DynDNS Diensten werden sich umstellen müssen.
Letztendlich ist jedes Problem lösbar, aber die Lösungen sind teils mit Umgewöhnung verbunden. Der eine wird sich in seinen Freiheiten eingeschränkt sehen, der andere nimmt die Festlegung auf ein relay gern in Kauf für ein paar Atemzüge ohne Spam. Doch früher oder später lassen sich die Spammer etwas neues einfallen.

[1] [Link nur für registrierte Mitglieder sichtbar. ]
[2] [Link nur für registrierte Mitglieder sichtbar. ]
[3] [Link nur für registrierte Mitglieder sichtbar. ]</blockquote>
Was haltet Ihr von der Einführung von RMX? Ich freue mich auf eine angeregte Diskussion!
--

Disclaimer:This post is for educational and entertainment purpose only

[Manfred]

So ist es nicht mehr ohne weiteres möglich, ein einzelnes SMTP relay zu nutzen, um unter verschiedenen Absenderadressen zu mailen, auch wenn das relay es theoretisch erlaubt (etwa nach SMTP Auth auf eine Prüfung des Absenders verzichtet). Nunmehr braucht man für jede domain der Absenderadressen ein dafür vorgesehes SMTP relay - was aber für aktuellere Email Programme kein Problem darstellen sollte und auch über die transports Anweisung der MTA realisiert werden kann.
Unbequem wird es auch für jemanden, der direkt über seinen eigenen Mail server ausliefern möchte. Da in der Regel seine Absender IP nicht in den RMX Einträgen auftauchen wird, ist derjenige gezwungen, das mail relay des Providers zu nutzen.
Auch Benutzer von DynDNS Diensten werden sich umstellen müssen.

Also wenn man einen Vorteil all diesen Nachteilen gegenüberstellt, würde ich die Idee als nicht praktikabel einstufen. Wie Du schreibst sind solche Mechanismen schon mehrfach angedacht aber genau deswegen wieder fallengelassen worden. Allein auf dem T-O... SMTP-Relay müßten zehntausende RMX-Einträge verwaltet werden.
Und was hindert die Spammer daran, auch dafür kurzlebige "Spamdomains" mit entrsprechenden RMX-Einträgen einzurichten? Sie tun`s ja schon für die beworbenen Sites. Es wurde also alles wieder mindestens einen Schritt hinterherhinken.
Da gibt`s also wirklich bessere und bereits erprobte Systeme ohne Eingriffe in die Infrastriktur des Internet (siehe unten).
Manfred

--
...und dann ging den Spammern das Publikum aus:
[Link nur für registrierte Mitglieder sichtbar. ]

[cycomate]

Also wenn man einen Vorteil all diesen Nachteilen gegenüberstellt, würde ich die Idee als nicht praktikabel einstufen.

Ich erachte den Vorteil als weitaus gewichtiger als die Nachteile. Allein die Tatsache, sich nicht mehr mit hunderttausend bounces herumschlagen zu müssen, trafficfressende Würmer direkt abweisen zu können ohne erst nach der Übertragung nach patterns suchen zu müssen oder JoeJobs auszuschließen, ist für mich sehr viel Wert.
Die angeführten Nachteile sind alle lösbar, sei es via transports oder (im Fall von DynDNS) analoge Änderung des RMX Eintrages.

Wie Du schreibst sind solche Mechanismen schon mehrfach angedacht aber genau deswegen wieder fallengelassen worden.

Nicht wirklich - sie wurden nur nie vernünftig umgesetzt.

Allein auf dem T-O... SMTP-Relay müßten zehntausende RMX-Einträge verwaltet werden.

Umgekehrt, jede domain müßte die IP des T-Online SMTP relays freischalten, was bei einem so großen Provider nicht unbedingt ein Problem darstellen sollte (Stichwort: trusted relays). Nichtsdestoweniger sehe ich keinen Grund, nicht die mail relays der zu den domains gehörenden provider zu nutzen.

Und was hindert die Spammer daran, auch dafür kurzlebige "Spamdomains" mit entrsprechenden RMX-Einträgen einzurichten? Sie tun`s ja schon für die beworbenen Sites

Zunächst einmal hieß es niemals, daß Spam vermieden, sondern reduziert wird. Zum anderen ist der Aufwand höher, allein die Infrastruktur ist eine ganz andere als bei den Spamdomains. Subdomain services fallen ohnehin flach, da selbst wenn der subdomain service RMX Einträge anbietet, die secondlevel domain als spamfriendly blacklisted werden kann. Und eine eigene secondlevel domain zu registrieren und zu verwalten wird sich für die Spammer kaum lohnen. Man wird die existierenden blacklists auch weiter verwenden, d.h. entweder der Spammer schaltet in seinem RMX Eintrag ständig wechselnd das gerade benutzte open relay frei (Aufwand relativ hoch), oder er benutzt seine eigene IP (sehr schnell zu blacklisten) oder er definiert das gesamte Internet (0/0) im RMX, wobei dieser spezielle Fall in der Implementierung bestimmt auch gefiltert werden kann.

Da gibt`s also wirklich bessere und bereits erprobte Systeme ohne Eingriffe in die Infrastriktur des Internet (siehe unten).

Ich setze lieber auf access control direkt am MTA und lasse die Übertragung gar nicht erst zu, als eine Windows software für jeden client zu benutzen, wenn ich das richtig überflogen habe.

--

Disclaimer:This post is for educational and entertainment purpose only

[MadMax]

Ich finde die Idee toll und wäre für eine möglichst schnelle Umsetzung.
Das Problem ist, die Realisierung: würden die meisten Provider heute beginnen, RMX Records zu setzen, wann kann man dann den eigenen Mailserver anweisen, diese zu beachten, damit keine E-Mails geblockt werden, die eigentlich authentisch sind, aber leider noch über keinen RMX verfügen?
Das ist aber nur ein kleines, praktisches Problem, das jeder selbst einschätzen kann. Große Provider müssen wohl noch eine ganze Weile warten, bis sie ihre MTAs auf die RMXs ansetzen.
Grundlegend ist`s aber, wie gesagt, eine tolle Idee, die ich unterstützen würde.
Nachteile gibt`s nur, wenn der Provider unfähig ist, die richtigen RMX Records zu setzen oder wirklich keine Individualeinstellungen für die DNS Records zulässt. In dem Falle wäre ein Providerwechsel ratsam.
Die Leute, die Mails über einen Dialup Host direkt verschicken, haben in meinen Augen eh keine Berechtigung auf Zustellung, nicht umsonst nutze ich auch die Blacklist dynablock.easynet.nl! Von Dialup IPs will ich keine Post.
Je mehr ich darüber nachdenke, desto besser finde ich die Idee. Der Spam bleibt dann zwar nicht aus, aber man kann den Spammern dann zurückschreiben!
Max