Spam und UCE - Filter: ReverseSMTP
So funktioniert es
Wenn ihnen jemand eine Mail sendet, dann erwarten Sie für gewöhnlich, dass Sie diese Mail auch wieder beantworten können. So ist es z.B. denkbar, dass ein System schon vor der Zustellung der Mail an das Postfach versucht, eine Antwort zu senden. Lehnt der entfernte Mailserver diese Antwort ab, z.B.: weil das Postfach des Absenders voll ist noch nicht existiert, dann erscheint es logisch, dass die eingegangene Mail wahrscheinlich als Spam zu klassifizieren ist.
Dieses Verfahren wirkt daher z.B. sehr gut mit den großen Hostern wie GMX, Yahoo, HotMail etc, die eingehenden Mails bei der Verwendung von nicht bekannten Postfächern frühzeitig ablehnen. Dieses an sich sehr interessante Verfahren hat aber einige Probleme, die berücksichtigt werden wollen. Eine Verbindung in der folgenden Form wird von der Gegenseite entweder mit einem OK oder einem Fehler beantwortet.
HELO meinmailserver.example.com
MAIL FROM:
postmaster@example.com
RCPT TO:
absender@example.com
QUIT
Kann an den angeblichen Absender nämlich keine Mail gesendet werden, dann kann ich die Mail mit an Sicherheit grenzender Wahrscheinlichkeit ablehnen. Es gibt mehrere Gründe hierfür:
- Kein MX-Eintrag
Ohne MX-Eintrag in der Domäne kann ich keine Mails senden. Damit wirkt dieser Test zugleich auch bei nicht existenten Domänen - Mailserver Down
Selbst bei definiertem MX-Eintrag kann es sein, dass der Mailserver nicht funktioniert, weil es schon durch massenhaft Rückmeldungen auf Folge einer Spam Nachricht überfordert ist. - Mailbox nicht gültig/voll
Viele Mailserver prüfen schon beim Empfang des "RCPT TO"-Envelope die Gültigkeit des Postfachs. Gibt es die angegebene Mailbox nicht oder ist sie durch andere Rückantworten schon voll (Quota Exceeded), dann sollte der Absender erst mal sicherstellen, dass er eine erwünschte Antwort auch annehmen kann
Probleme
Dieser an sicht geniale Test hat wenige Nachteile:
- Zusätzliche Verbindungen
Die versuchte Verbindung bedeutet zusätzliche Anfragen am DNS; TCP/IP-Verbindungen und etwas Datenvolumen - Gefahr einer Loop
Wenn die Gegenseite schon nach dem Empfang das "MAIL FROM" den gleichen Test durchführt, dann haben sich zwei Server in einem Deadlock verfangen, aus dem sie nicht mehr heraus kommen. Dies muss verhindert werden. - Ausgehende Verbindungen
Der Server, der den Test durchführt, wird natürlich nach draußen eine Verbindung aufbauen. Dies muss in der Firewall entsprechend konfiguriert sein. Der Server muss aber auch so sicher sein, dass niemand auf der Gegenseite diese ausgehende Verbindung dann nutzt, um Sie zu stören, z.B.: indem der Spammer sie auf einen Mailserver leitet, der mit falschen Antworten versucht, ihre Verbindung zu blockieren oder Pufferüberläufe in ihrer Software zu erreichen und andere Dinge. - Mitarbeite des entfernten Gateways
Nicht alle Mailserver unterstützen eine Fehlermeldung, wenn der Empfänger der Antwort nicht erreichbar ist. Gerade Firmen, die noch stupide Relayserver betreiben, nehmen jede ohne Prüfung des Empfängers Mail an. Hier versagt dieser Test. - Gesplitteteter Mailfluss
Größere Firmen nutzen oft mehrere Mailserver und trennen eingehende und ausgehende Verkehre um im Fall eines Angriffs noch reagieren zu können. Der eingehende Mailserver würde sich dann durch das Proben des Absenders verraten und die Regeln der Firewall müssten erweitert werden. - Newsletter und Spezialadresse
Sehr viele Firmen versenden Mails mit besonderen Adressen. Auch Microsoft versendet ihren Newsletter mit einer individuellen Adresse je Teilnehmer. So kann ein Versender z.B. Unzustellbarkeitsmeldungen leichter zuordnen. Wenn dann der Mailserver eine Antwort ablehnt, weil es eben diese Absenderadresse nicht gibt, dass wird die Aussendung irrtümlich als Spam eingestuft.
So interessant dieser Filter auf den ersten Blick wirkt, so kritisch muss hinterfragt werden, ob dieser Filter mit allen Gegenstellen zu nutzen ist. Es ist sicher eine gute Idee, die großen Massenprovider wie GMX, HOTMAIL, YAHOO etc. auf diese Weise zu proben. So werden nicht existente Mailadressen oder bereits volle Postfächer von Absendern ausgefiltert.
Weitere Links
-
CERN Spam Schutz
http://mmmservices.web.cern.ch/mmmservices/Antispam/3StepsStatus.aspx
Reverse SMTP Connect rule is activated since 15th October 2004. We try to simulate a reply to the sender by connecting to the sender's domain MX. If connection fails, we reject the mail. Currently no major problem was found, outgoing mail queues were divided by 10 (mostly NDRs to invalid domains). 25% of previously accepted mails are rejected by this rule -
CERN Funktionsweise
http://mmmservices.web.cern.ch/mmmservices/Help/?kbid=171030
Leider prüft das CERN anscheinend nur einen CONNECT.
