<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hallo Patrick,<br>
<br>
danke für die ausführliche Erklärung!<br>
<br>
<div class="moz-cite-prefix">Am 31.07.15 um 10:28 schrieb Patrick
Ben Koetter:<br>
</div>
<blockquote cite="mid:20150731082835.GD12329@sys4.de" type="cite">
<pre wrap="">* Günther J. Niederwimmer <a class="moz-txt-link-rfc2396E" href="mailto:postfixbuch-users@listen.jpberlin.de"><postfixbuch-users@listen.jpberlin.de></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Hallo Patrick,
danke für die ausführliche Erklärung, wenn Du noch Beispiele dazu packst
hätten wir ein sehr gutes HowTo ;-).
</pre>
</blockquote>
<pre wrap="">
Zwei Dumme, ein Gedanke... ;)
Ich habe IMO das Notwendige zusammengeschrieben. Falls was fehlt einfach
melden:
<a class="moz-txt-link-freetext" href="https://sys4.de/de/blog/2015/07/31/amavisd-milter-howto/">https://sys4.de/de/blog/2015/07/31/amavisd-milter-howto/</a>
</pre>
<blockquote type="cite">
<pre wrap="">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) :-(
</pre>
</blockquote>
<pre wrap="">
Du willst das EPEL-Repo. Der Rest ist IMNSHO unbrauchbar.
p@rick
</pre>
<blockquote type="cite">
<pre wrap="">
Nochmal Danke.
Am Freitag, 31. Juli 2015, 00:08:33 schrieb Patrick Ben Koetter:
</pre>
<blockquote type="cite">
<pre wrap="">Günther,
* Günther J. Niederwimmer <a class="moz-txt-link-rfc2396E" href="mailto:postfixbuch-users@listen.jpberlin.de"><postfixbuch-users@listen.jpberlin.de></a>:
</pre>
<blockquote type="cite">
<pre wrap="">was ist eigentlich der "bessere" Weg um amavis einzubinden amavis-milter
oder der "normale" Weg.
</pre>
</blockquote>
<pre wrap="">
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 <a class="moz-txt-link-freetext" href="https://github.com/sys4/smilla">https://github.com/sys4/smilla</a>
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@rick
</pre>
</blockquote>
<pre wrap="">
--
mit freundlichen Grüssen / best regards,
Günther J. Niederwimmer
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<style type="text/css">
body p {
font-size: 12px;
font-family: Arial, Helvetica, sans-serif;
}
</style>
<p>Mit freundlichen Grüßen</p>
<b><font face="Optima">Verlag + Druck LINUS WITTICH KG</font></b><br>
<p>i. A. Michael Grundmann</p>
<p>54343 Föhren<br>
Europaallee 2<br>
E-Mail: <a href="mailto:m.grundmann@wittich-foehren.de">m.grundmann@wittich-foehren.de</a><br>
Internet: <a href="http://www.wittich.de">http://www.wittich.de</a><br>
Tel.: +49 6502/9147210<br>
Fax: +49 6502/9147332</p>
<p>Sitz der Gesellschaft: Föhren<br>
Geschäftsführer: Dietmar Kaupp<br>
Amtsgericht: Wittlich HR 4199<br>
USt ID gemäß §27 a UStG DE 149324406</p>
<p><strong>Kennen Sie schon localbook? Nein? <a
href="http://www.localbook.de">Hier >>></a> </strong></p>
</div>
</body>
</html>