AmaVis

[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

-- 
[*] 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