AmaVis

[Patrick Ben Koetter]

* Günther J. Niederwimmer <postfixbuch-users at listen.jpberlin.de>:
> Hallo Patrick,
> 
> danke für die ausführliche Erklärung, wenn Du noch Beispiele dazu packst 
> hätten wir ein sehr gutes HowTo ;-).

Zwei Dumme, ein Gedanke... ;)

Ich habe IMO das Notwendige zusammengeschrieben. Falls was fehlt einfach
melden:

    https://sys4.de/de/blog/2015/07/31/amavisd-milter-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) :-(

Du willst das EPEL-Repo. Der Rest ist IMNSHO unbrauchbar.

p at rick



> 
> 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

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein