AmaVis

[Günther J. Niederwimmer]

Hallo Patrick,

danke für die ausführliche Erklärung, wenn Du noch Beispiele dazu packst 
hätten wir ein sehr gutes HowTo ;-).

Ich werde also versuchen den Milter in meinen neuen Centos 7 Server 
einzubinden, wenn ich nicht wieder in alle Fallen laufe, die es gibt (ist 
meine Spezialität) :-(

Nochmal Danke.

Am Freitag, 31. Juli 2015, 00:08:33 schrieb Patrick Ben Koetter:
> Günther,
> 
> * Günther J. Niederwimmer <postfixbuch-users at listen.jpberlin.de>:
> > was ist eigentlich der "bessere" Weg um amavis einzubinden amavis-milter
> > oder der "normale" Weg.
> 
> die Antwort ist, denke ich, einfach. Die Erklärung aber nicht. Sie führt
> über ein paar Umwege. (Ist lang, aber kürzer kriege ich es gerade nicht
> hin.)
> 
> Vorneweg: Wir (sys4) setzen bevorzugt Milter ein. Für uns waren (seitdem
> Wietse begonnen hatte MILTER in Postfix zu integrieren) die erweiterten
> Möglichkeiten, die sich durch deren Einsatz ergeben, ausschlaggebend.
> 
> Um das zu begründen stelle ich die Filter-Schnittstellen und ihre
> Möglichkeiten mal gegenüber:
> 
> In Postfix gibt es Connection Filter, die policy-Schnittstelle, Content
> Filter und MILTER. Was zeichnet diese Schnittstellen aus?
> 
> Connection Filter
> Über Connection Filter kannst Du amavis nicht einbinden. Sie sind aber super
> für RBLs und anderen, selber programmierten Kram. ;)
> 
> Session Filter
> Mit policy-Services "sieht" der policy-Server die SMTP Session zwischen
> Client und Server. Vom Content erfährt ein policy-Server nichts.
> 
> Content Filter
> Ein Content Filter, Du kannst die content- oder smtpd_proxy-Filter
> Schnittstelle nehmen, hat Einblick in den Content. Wenn das Filter XFOWARD
> versteht, kann es noch eingeschränkt Session-Daten wahrnehmen.
> 
> Milter
> Ein Milter sieht alles - Session und Content. Es kann Postfix zu jedem
> Zeitpunkt - egal zu welchem Session Step oder welcher Zeile im
> vorbeiströmenden Content - seine Entscheidung verkünden. Ein Milter arbeitet
> ausschliesslich im Arbeitsspeicher. Es kann Content modifizieren und on the
> fly austauschen.
> 
> 
> Was hat man davon?
> 
> 1. Du kannst E-Mail programmieren (und nicht nur konfigurieren).
> Wenn Du E-Mail "machst", dann ist die Milter-Schnittstelle die API mit der
> Du arbeiten willst - Du kannst aus dem Vollen schöpfen. Diesen
> prinzipbedingten Vorteil der Milter-Schnittstelle nutzen wir z.B. um den
> Funktionsumfang von Postfix nach den Vorstellungen unserer Kunden zu
> erweitern.
> 
>     Als aktuelles Beispiel kann ich Dir https://github.com/sys4/smilla
> nennen. Dort haben wir ein Programm geschrieben, das pre-Queue über DNSSEC
> nach (über DANE) veröffentlichten S/MIME-Zertifikaten sucht und - sodann
> ein S/MIME-Cert vorhanden - die Mail an den Empfänger auf dem Server
> verschlüsselt und sie dann verschlüsselt zustellt.
> 
> 
> 2. Du kannst Funktionen umsetzen, die mit den anderen Filter-APIs nicht
> möglich sind.
> Wenn Du z.B. DMARC einsetzen willst (im Enterprise, Carrier und ISP-Bereich
> willst du das sehr wahrscheinlich) bist Du im Grunde auf die MILTER-API
> angewiesen. So wie wir uns DMARC-Verarbeitung vorstellen, willst Du die
> DMARC-Filter Entscheidungen (annehmen, ablehnen) gesetzeskonform "in
> Session" treffen.
> DMARC setzt eine (vorausgegangene) SPF- und DKIM-Valdierung voraus. SPF
> bekommst Du mit einem Session Filter hin, aber DKIM nicht. Für DKIM *muss*
> das Filter Header _und_ Body, also den Content, sehen.
> Wenn Du also "in Session" DMARC machen willst, musst Du *vor* dem
> DMARC-Filter in den Content gesehen und eine DKIM-Validierung durchgeführt
> haben, damit du dann "in Session" die DMARC-Entscheidung bekannt geben
> kannst.
> Kein Problem, wirst Du Dir sagen, das mache ich alles live in amavis.
> Vielleicht irgendwann mal, aber heute nicht. Als DMARC vor 4 Jahren auf der
> MAAWG in Paris vorgestellt wurde, habe ich sofort Mark angemailed und ihn
> auf DMARC aufmerksam gemacht. Er entschied sich dagegen, es zu
> implementieren. Bleibt, an nicht-kommerziellen Applikationen, heute
> opendmarc und das ist ein MILTER.
> 
> 
> Was kannst Du mit den APIs in Postfix anfangen?
> 
> Die Nutzung der APis kannst Du, so wie Wietse sie implementiert hat,
> unterschiedlich umfangreich kontrollieren.
> 
> Connection Filter
> Null Kontrolle. Total auf Speed optimiert.
> 
> Policy-Server
> Policy-Server bieten keine Kontrollmöglichkeiten. Postfix "bläst" alle
> Infos, die es zu der SMTP-Phase in der der policy-Service gerufen wird
> kennt, zu dem Service rüber. Der entscheidet 'was' und 'sagt' es Postfix.
> Ende. Aus.
> 
>     Ich mag policy-Server, weil man so ressourcensparend mit ihnen arbeiten
>     kann. Die fehlende Kontrolle mag ich aber nicht. Im Gegenteil! Wenn ein
>     policy-Server auf die Schnauze fällt, darf er das nicht einmal sagen. Er
> darf selbst dann nur "Ja und Amen" antworten.
> 
> Content Filter
> Du kannst pre-Queue kontrollieren, ob Postfix die Mail immer gleich zum
> Filter durchschiebt oder ggf. erst einmal zwischenspeichert (speed_adjust).
> Postfix geht aber *immer* davon aus, dass das Filter verfügbar ist. Wenn es
> failed, failed auch Postfix.
> 
> Milter
> Du kannst steuern welche Informationen (milter_*_macros) zu welcher Phase
> übermittelt werden. Bis Postfix 3.0 nur global, seit 3.0 aber per Milter
> verfügbar: Du kannst für jeden Milter einzeln Optionen (connect,
> default_action etc.) für die Zusammenarbeit festlegen.
> 
> Wenn, in einer Kette von Miltern, eines failed, kannst Du Dir überlegen, ob
> es arbeiten *muss* oder ob es möglicherweise zeitweilig auch ohne geht. Das
> kann für möglichst ununterbrochenen Betrieb eine entscheidene Kontrolle
> sein.
> 
> 
> Für uns sprechen also die Möglichkeiten, programmatisch in E-Mail
> einzugreifen und die feineren Kontrollmöglichkeiten, für Milter.
> 
> 
> Bleibt noch die Frage, ob die API in Postfix fehlerfrei, belastbar, und
> stabil ist.
> 
> Vor Postfix 3.0 gab es eine fiesen BUG in Postfix. Naja, sagen wir mal es
> war ein Feature. Wietse hatte die API so umgesetzt, dass die erste
> Header-Zeile unterdrückt wurde, um Sendmai-kompatibel zu sein. Diese
> Einschränkung (unsere Meinung) ist mit 3.0 nun weggefallen.
> 
> Wir haben die MILTER-API in Postfix intern getestet, weil es keine Daten
> dazu gab. MILTER sind so schnell wie die Aufgabe, die sie erledigen müssen,
> es ihnen gestattet. Wenn Du nur Daten erfassen und wegschreiben willst,
> kommst Du entspannt auf 140 msg/sec und mehr - je nach Hardware. Bei
> Virenscannen wird es weniger und bei Spam schlagen die umfangreichen und
> ressourcenhungrigen Tests von z.B. Spamassasin zu. Das kann den Server dann
> signifikant runterbremsen. An der MILTER-API liegt es nicht! Die Aufgabe
> des MILTER definiert die Grenzen seiner Performance.
> 
>     Weil wir bei sowas nicht spekulieren, messen wir einfach immer. Dann
>     können wir belastbare Aussagen treffen.
> 
> Ist Milter-Software stabil? Die MILTER-API in Postfix ist stabil. Wir haben
> wirklich viel Mail, auf eigenene und Kundensystemen, über die API gejagt und
> *nie* Probleme gehabt. Und die Programme? Die Meisten sind es. Die
> amavis-milter Bridge (MILTER <-> AM.PDP-Protokoll) ist es. Die Milter, die
> wir erstellen, sind es auch. Wir haben dazu wirklich viele Milter-Libraries
> ausprobiert und ausreichend Zeit damit verbracht, Spreu von Weizen zu
> trennen.
> 
> So und jetzt (endlich) die Antwort auf Deine Frage... ;)
> 
> Du willst amavis als Milter einbinden. Es spricht nichts dagegen. Es spricht
> sogar vieles dafür. Die kommenden Filter-Ansätze, wie z.B. DMARC, erfordern
> (zumindest heute) MILTER. Aber wenn MILTER, dann alles MILTER, denn sie
> mischen sich nicht gut mit smtpd_proxy_filtern.
> 
> Einer meiner Liebblingsgründe für amavis über MILTER: Das LOG sieht endlich
> wieder normal aus. Programme können es sauber in Serie parsen. Menschen
> können die Ereigniskette schlüssig von oben nach unten lesen. Allein das
> bestätigt mich immer wieder in der Entscheidung den smtpd_proxy_filtern vor
> Jahren den Rücken gekehrt zu haben. Ich habe es bis heute nicht bereut.
> 
> p at rick

-- 
mit freundlichen Grüssen / best regards,

 Günther J. Niederwimmer