Freude mit MTAs

Manche wissen ja, dass ich mich im Rahmen meiner Thesis mit Emails und Spambekämpfung beschäftige. Seit Silvester ist das ganze bei mir im produktiven Einsatz zur Evaluierung und einige sind da auch schon nichtsahnend reinmaschiert ;-)

Nun heute bin ich auf ein unerwartetes Problem gestoßen. Kurz zum Hintergrund: meine Implementierung antwortet automatisiert auf einkommende Mails unter bestimmten Voraussetzungen. Daher wird auch auf Spam Mails geantwortet und wie man das erwarten würde, wird diese Mail nie zugestellt und ein Mailserver wird mir das mitteilen. Da das ganze ja erwartet ist, ist die Implementierung darauf vorbereitet und behandelt diese Delivery Status Notifications (DSN) gesondert um zu verhindern, dass noch mal darauf eine Mail rausgesendet wird.

Mit dem RFC 3464 aus dem Jahre 2003 und seinem Vorgänger RFC 1894 aus dem Jahre 1996 gibt es dazu auch eine Standard. Eine DSN ist eine MIME Message mit dem Content-Type "multipart/report", der mehrere Bereiche enthält. Darunter die eigentliche Benachrichtigung ("Notification") und idR zwei Anhänge: den technischen "Delivery report" und die optionale ursprüngliche Nachricht. Für all diese Bereiche sind sinnvolle standardisierte MIME Types vergeben.

Auf meinem Server und lokal auf meinem Laptop läuft jeweils ein Postfix. Beim Implementieren hat das auch alles schön immer funktioniert – die Mail an foo@bar.baz kann nicht zugestellt werden und löst eine DSN nach RFC 3464 aus. Diese wird gut verarbeitet – selbst die optionale ursprüngliche Mail wird berücksichtigt. Auch die erste Woche in dem produktiven Einsatz zeigte keine Probleme. Der Standard ist ja schon recht alt und man kann ja davon ausgehen, dass alle Mail Transfer Agents (MTA) diesen umsetzen.

Tja, dass es MTAs gibt, die diesen RFC nicht implementieren, damit hatte ich nicht gerechnet. Aber es gibt ihn: Exim – der Standard MTA unter Debian. Der Feature Request es zu implementieren stammt aus dem Jahr 1999 und wurde in Bugzilla importiert – dürfte also noch älter sein. Ich frage mich ja jetzt wirklich warum eine Distribution einen MTA standardmäßig installiert, der dies nicht unterstützt. Die Bounces, die Exim rausschickt, sind keine MIME Messages und nur schwer automatisiert zu erkennen. Das einzige Indiz ist ein X-Failed-Recipients Header, die ursprüngliche Mail ist in den Message Body kopiert. Diese Mail wird von meiner Implementierung natürlich (noch) nicht erkannt und löst daher eine schöne Mail-Loop aus: automatisierte Mail raus, Notification rein, autmatisierte Mail raus usw. usw. Nach der dritten Mail hab ich bemerkt dass da was nicht stimmt und manuell unterbrochen.

Ach wie einfach wäre die Internet Welt, wenn sich doch mal alle an die Standards halten würden :-( Nun kann ich überlegen ob ich akzeptiere, dass bounces von Exim Probleme bereiten oder versuchen die Mails zu parsen. Auf letzteres würde ich gerne verzichten, weil es mir etwas zu unsicher ist, mich auf einen einzigen Header zu verlassen. Außerdem ist es wichtig, die ursprüngliche Mail zu extrahieren, da es die einzige verlässliche Information ist, ob die Mail von der Implementierung versendet wurde. Da man so freundlich ist die Mail in den Body zu hängen, gibt es natürlich keinen Anhaltspunkt wo sie beginnt und endet. Gäbe es prinzipiell aber laut $SUCHMASCHINE ist die Nachricht lokalisiert.

Ach so was macht Freude.

=-=-=-=-=
Powered by Blogilo

4 thoughts on “Freude mit MTAs”

  1. Auch wenn ich das Prinzip hinter deiner Software schlimm finde (meine Domain wird ab und zu in die gefälschten Absender von Spamwellen benutzt -> tausende Mails backscatter):
    wäre nicht eine Ruhephase nach jeder verschickten Mail sinnvoll? Ich meine, dass die meiste ähnliche Software (und Autoresponder generell) das Problem der Mail-loop umgehen, indem sie an jede individuelle Emailadresse nur eine Mail pro 24h schicken.

    1. tausende Mails backscatter

      Ist ja berücksichtigt – zum einen wird genau deswegen nichts aus der empfangenen Mail zitiert um nicht Spam weiterzuleiten zum anderen kann man einfach meine Implementierung einsetzen, weil es auch davor schützt :-D

      (Nebenbei zeigte bisher meine Evaluierung, dass alle Mails von nicht existierenden Mails versendet wurden)

      wäre nicht eine Ruhephase nach jeder verschickten Mail sinnvoll? Ich meine, dass die meiste ähnliche Software (und Autoresponder generell) das Problem der Mail-loop umgehen, indem sie an jede individuelle Emailadresse nur eine Mail pro 24h schicken.

      Nein, es gibt legitime Fälle für mehrere Mails pro Tag. Außerdem werden die Adressen an die gesendet wird nicht gespeichert ;-) Generell sollte eine Mailloop aber nicht möglich sein. Der einzige denkbare Fall sind die DSNs und die werden ja abgefangen (ja jetzt auch für Exim)

      1. zum anderen kann man einfach meine Implementierung einsetzen, weil es auch davor schützt :D

        Ah, du hast business-Vorlesungen von Mitarbeitern des ehemaligen BASIC-Herstellers gehabt ;-)

        Wie hast du das Problem jetzt gelöst? Du parst Mails?

        1. Wie hast du das Problem jetzt gelöst? Du parst Mails?

          Ich überprüfe ob der magische Header da ist und dann wird es als DSN angesehen. (Jetzt beim Schreiben merke ich gerade, dass ich damit einen Angriffsvektor geschaffen habe) Es beendet dann die Mailloop auch wenn es nicht die perfekte Lösung ist, da ich an die ursprünglich gesendete Mail nicht drankomme, welche ich eigentlich bräuchte. Wobei es eigentlich reichen würde die Mail nach einem einzigen String im Body zu durchsuchen. Es ist halt dumm, wenn es MIME wäre, wäre es bedeutend sicherer.

Comments are closed.