AmaVis

Fr Jul 31 10:41:27 CEST 2015

Hallo Patrick,

danke für die ausführliche Erklärung!

Am 31.07.15 um 10:28 schrieb 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

-- 

Mit freundlichen Grüßen

*Verlag + Druck LINUS WITTICH KG*

i. A. Michael Grundmann

54343 Föhren
Europaallee 2
E-Mail: m.grundmann at wittich-foehren.de
<mailto:m.grundmann at wittich-foehren.de>
Internet: http://www.wittich.de
Tel.: +49 6502/9147210
Fax: +49 6502/9147332

Sitz der Gesellschaft: Föhren
Geschäftsführer: Dietmar Kaupp
Amtsgericht: Wittlich HR 4199
USt ID gemäß §27 a UStG DE 149324406

*Kennen Sie schon localbook? Nein? Hier >>> <http://www.localbook.de> *

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20150731/ad6da73c/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 868 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20150731/ad6da73c/attachment.asc>