close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

13 Wie externe Content-Filter funktionieren

EinbettenHerunterladen
181
13
Wie externe Content-Filter
funktionieren
Die in Postfix eingebauten Filtermechanismen aus dem vorigen Kapitel sind nur für
rudimentäre Aufgaben brauchbar; raffiniertere Anforderungen ans Filtern müssen
durch Delegierung an externe Programme realisiert werden.
Postfix kann den Inhalt einer Mail vor oder nach dem Einstellen in die Queue
inspizieren lassen. Wenn eine Mail gefiltert wird, bevor sie in die Queue gelangt, kann
Postfix die Benachrichtigung über eine Nichtzustellung auf den Client abwälzen.
Wenn die Mail allerdings erst in Queue akzeptiert wird, liegt diese Verantwortung
bei Postfix.
Dieses Kapitel skizziert den Prozess der Delegierung von E-Mails an externe
Programme. Sie werden lernen, wie die Postfix-Dämonen konfiguriert werden müssen, damit externe Filter die E-Mail erhalten und nach dem Filtern die E-Mail wieder
von Postfix weiterbearbeitet werden kann.
Die externen Filter machen dort weiter, wo die internen Filtermechanismen enden;
sie erlauben nicht nur die Analyse und das Abweisen von Mails, sondern auch die
Veränderung des Mail-Inhaltes. Einige typische Aufgaben für externe Filter sind:
ᆕ Hinzufügen von Ausschlussklauseln an eine Mail (disclaimer)
ᆕ Scannen auf Viren
ᆕ Erkennung von Spam
ᆕ Archivierung
Postfix besitzt zwei Mechanismen, content_filter und smtpd_proxy_filter. Diese
unterscheiden sich darin, welche Transporttypen genutzt werden können und ob
vor oder nach dem Queuing gefiltert wird:
)LOWHU1DPH
7UDQVSRUWV
$EZHLVHYHUKDOWHQ
FRQWHQWBILOWHU
VPWSOPWSSLSH
5(-(&7QDFK4XHXLQJ
VPWSGBSUR[\BILOWHU
VPWS
5(-(&7YRU4XHXLQJ
Tab. 13-1: Transporttypen externer Content-Filter
Dieses Kapitel beschreibt die Unterschiede im Detail und gibt Entscheidungshilfen
für die Auswahl des geeigneten Filtertyps.
182
13 Wie externe Content-Filter funktionieren
13. 1
Was ist der beste Zeitpunkt zum Filtern der Mail?
Gemäß der RFC-Standards darf ein Mailserver eine Mail spätestens am Ende der
DATA-Phase des SMTP-Dialogs abweisen. Der Client schickt die gesamte Mail, der
Mailserver muss dann die Mail scannen und erst dann – bevor der Client in ein Timeout rennt – möglichst schnell signalisieren, ob die Mail angenommen oder abgewiesen werden soll. In der Praxis bedeutet diese Vorgabe, dass für die Untersuchung
der E-Mail nicht viel Zeit zur Verfügung steht – der Client wird nicht ewig warten,
weil er sich so vor defekten Mailservern schützt.
Hinweis
Der Timeout von Postfix' smtp-Client ist durch den smtp_data_done_timeout-Parameter definiert, der auf tolerante 600 Sekunden voreingestellt ist.
Gelingt es dem Mailserver, die Analyse einer E-Mail abzuschließen, bevor der Mailclient die Verbindung abbricht, gibt es keinerlei Probleme, und der Server teilt dem
Client rechtzeitig mit, ob er die Mail akzeptiert. Wenn der Server aber zu langsam
ist, wird der Client die Verbindung abbrechen und hoffentlich zu einem späteren
Zeitpunkt eine erneute Zustellung versuchen – und dann geht das ganze Spiel wahrscheinlich wieder von vorne los.
Postfix' content_filter löst dieses Problem:
1. Der Client sendet die Mail.
2. Postfix' smtpd akzeptiert die Mail und stellt sie in die Mail-Queue ein.
3. Der Queue-Manager schickt die E-Mail an den Transport, der durch den
content_filter-Eintrag definiert ist.
4. Postfix übergibt die E-Mail an ein externes Programm.
5. Das externe Programm übernimmt die Verantwortung für die Zustellung der
Mail. Nun kann das Programm alles Mögliche mit der Mail machen:
a) Die Mail annehmen und später an Postfix zurückgeben.
b) Die Mail annehmen und sie an ein anderes Programm oder einen anderen
Server abgeben.
c) Die Mail verwerfen oder zurückschicken.
Der zweite Filtertyp, smtpd_proxy_filter, funktioniert anders:
1. Der Client sendet die Mail.
2. Postfix' smtpd reicht die SMTP-Befehle und Daten an ein externes Programm
durch (welches daher offensichtlich SMTP sprechen können muss).
3. Das externe Programm sendet SMTP-Statuscodes zurück an Postfix' smtpd, der
diese an den Client durchreicht.
13. 2 content_filter: Erst queuen, dann filtern
183
So interessant dieser Ansatz klingt, weil Postfix mit diesem Prüfverfahren die E-Mail
nicht annehmen muss, so hat sie doch zwei erhebliche Einschränkungen. Erstens kann
dieser Filtertyp das oben genannte Timeout-Problem hervorrufen, und zweitens skaliert der Ansatz nicht bei einer großen Anzahl paralleler Verbindungen. Das liegt
daran, dass der Filter keine eigene Queue besitzt und deshalb die Mail in Echtzeit
bearbeiten muss.
Das Ergebnis dieser Arbeitsweise ist, dass viele parallele Verbindungen auch viele
parallel laufende Filterprozesse mit sich bringen, die um die Zahl ihrer Instanzen
langsamer laufen und so noch eher Gefahr laufen, das Zeitlimit des Clients zu überschreiten. Sehr arbeitsintensive Vorgänge wie z.B. die Filterung von Mail auf Spam
oder Virenscanning (durch das zeitaufwändige Auspacken und Dekodieren von Dateianhängen) sind deshalb für einen smtpd_proxy_filter eher ungeeignet.
Beide Filtertypen haben ihre Vor- und Nachteile:
ᆕ content_filter generiert ggf. zusätzlichen Netzwerkverkehr, weil jede Mail initial
angenommen wird, aber bei Nichtgefallen dem Absender eine Nichtzustellbarkeitsmitteilung (Bounce) gesendet werden muss.
ᆕ smtpd_proxy_filter kann unerwünschte Mail noch vor dem Queuing abweisen,
skaliert aber nicht gut.
13. 2
content_filter: Erst queuen, dann filtern
Sie benötigen zwei unterschiedlich konfigurierte smtpd-Dämonen, damit Sie den
content_filter-Mechanismus nutzen können (siehe Abb. 13-1). Der erste nimmt die
ungefilterten Mails aus dem Netz an und lässt sie an den content_filter übergeben.
Die zweite smtpd-Instanz nimmt ausschließlich Verbindungen von dem externen Filter
an, sorgt aber vor allem dafür, dass die E-Mail nicht noch einmal an den
content_filter übergeben, sondern zugestellt wird.
Warnung!
Die zweite smtpd-Instanz darf auf keinen Fall denselben content_filter wie die erste
Instanz nutzen. Dies würde zu einer Endlosschleife führen, weil die gefilterte Mail
immer wieder an den Filter geschickt würde.
184
13 Wie externe Content-Filter funktionieren
Internet
Mailserver/
Mailclient
Mailserver
Postfix
Filter-Software
smtpd
mit
content_filter
smtpd
ohne
content_filter
cleanup
Filter
qmgr
pipe
local
uucp
Mailbox
smtp
tcp
Internet
Mailserver
Mailserver
Abb. 13-1: Zustellprozess eines content_filter
Alle content_filter funktionieren nach diesem Prinzip:
1. Der externe smtpd, er hat content_filter konfiguriert, nimmt die E-Mail und gibt
sie an den Queue-Manager.
13. 2 content_filter: Erst queuen, dann filtern
185
2. Der Queue-Manager veranlasst, dass die E-Mail per smtp-, lmtp- oder pipe-Transport an den externen Filter weitergereicht wird.
Hinweis
Abb. 13-1 zeigt nur einen der möglichen Transports, nämlich smtp.
3. Der externe Filter übernimmt die E-Mail und filtert sie.
4. Ist der Filter mit seiner Arbeit fertig, kontaktiert er eine weitere, interne smtpdInstanz. Diese Instanz nutzt keinen oder einen anderen content_filter (Filterkette).
5. Der interne smtpd-Daemon gibt die Mail an den Queue-Manager weiter.
6. Postfix stellt die Mail weiter zu.
Neben der Nachricht selbst können in Abhängigkeit vom gewählten Transporttyp
zusätzliche Informationen an einen content_filter übergeben werden. Welche genau
hängt vom Transporttyp ab, über den wir im nächsten Abschnitt sprechen werden.
13.2.1
Transporttypen für content_filter
Wenn Sie einen content_filter als Filter einsetzen, stehen Ihnen drei verschiedene
Transporttypen zur Verfügung. Diese unterschieden sich darin, wie sie funktionieren
und welche Meta-Informationen sie an den externen Filter übertragen können:
pipe
Der pipe-Daemon schickt die E-Mails an die Standardeingabe der von
ihm aufgerufenen externen Programme. pipe kann theoretisch jedes beliebige Programm oder Skript aufrufen und mittels zahlreicher Flags und
Parameter, die sie konfigurieren können, Meta-Informationen an das
externe Programm übergeben (siehe pipe (8)).
Üblicherweise gelangt so gefilterte Mail über den Aufruf des sendmailBefehls wieder in Postfix hinein.
smtp
Der smtp-Client kann E-Mails an externe Programme weiterschicken,
die entweder das SMTP- oder ESMTP-Protokoll beherrschen (z.B. amavisd-new oder ein anderer MTA). Die Informationen, die dabei an das
externe Programm weitergegeben werden können, sind auf die Möglichkeiten (siehe smtp (8)) des jeweiligen Protokolls beschränkt.
lmtp
Postfix's lmtp, ein LMTP-Client, kann genau wie der smtp-Client EMails an externe Programme weiterschicken, die in diesem Fall das
LMTP-Protokoll verstehen müssen (z.B. amavisd-new oder cyrus).
Auch hier beschränkt das LMTP-Protokoll Art und Form der übermittelten Informationen (siehe lmtp (8)).
186
13 Wie externe Content-Filter funktionieren
Hinweis
Anders als Postfix' smtp-Client, der durch die Beschränkungen des SMTP-Protokolls nicht in der Lage ist, einzelne Zustellbenachrichtigungen zu erstellen, erlaubt
das LMTP-Protokoll dem Server, für jeden einzelnen Empfänger einer Mail separat
eine Status-Nachricht zu senden (d.h. bei einer Mail mit vielen Empfängern kann
die Mail für einige Empfänger angenommen, für andere aber abgewiesen werden).
Dies macht es möglich, verwirrende Zustellbenachrichtigungen zu vermeiden in
Fällen, in denen die Mail für einige Empfänger angenommen, aber für andere abgewiesen wurde, aber alle die Nachricht mit der Bounce-Meldung erhalten.
13.2.2
Grundlagen für die Konfiguration eines content_filter
Um E-Mails über einen content_filter an ein externes Programm zu schicken, muss
das Verhalten aller Dämonen, die eingehende Mail annehmen, verändert werden.
Folgende Schritte sind notwendig:
1. Einen Transport in main.cf als content_filter definieren.
2. Diesen Transport in master.cf anlegen.
3. Einen zusätzlichen Daemon für den Wiedereintritt der E-Mail in Postfix in
master.cf definieren.
Alternativ gibt es noch die Möglichkeit, den content_filter nur für die Instanz des
smtpd zu definieren, die Mail aus dem Netzwerk entgegennimmt. In diesem Falle sind
folgende Schritte notwendig:
1. Einen Transport in master.cf als content_filter für den smtpd definieren, der Mail
aus dem Netzwerk entgegennimmt.
2. Diesen Transport in master.cf anlegen.
3. Einen zusätzlichen Daemon für den Wiedereintritt der E-Mail in Postfix in
master.cf definieren.
content_filter in main.cf definieren
Als Erstes müssen Sie Postfix anweisen, E-Mails an einen externen Content-Filter zu
senden. Dazu müssen Sie den Content-Filter (als Transport) mit dem
content_filter-Parameter in main.cf benennen. Im folgenden Beispiel werden alle
Mails mittels des Transports meinfilter (der anschließend in master.cf definiert werden wird) an die IP-Adresse 127.0.0.1 auf Port 54321 weitergegeben. Die eckigen
Klammern vermeiden dabei MX-Lookups für den eingeklammerten Hostnamen:
content_filter = meinfilter:[127.0.0.1]:54321
13. 2 content_filter: Erst queuen, dann filtern
187
Soll der lokale content_filter über IPv6 angesprochen werden, tragen Sie Folgendes
ein:
content_filter = meinfilter:[::1]:54321
Transport in master.cf anlegen
Als Nächstes legen Sie den eigentlichen Transport in master.cf an. Dazu benötigen
Sie folgende Informationen:
1. Den Namen des Transports (hier: meinfilter).
2. Den Namen des Postfix-Daemon, der den Transport durchführen soll (z.B.
lmtp, smtp oder pipe).
3. Optionen und andere Informationen, die der gewählte Transporttyp ggf. noch
braucht.
Hier ein Beispiel für unseren Transport meinfilter:
#=================================================================
# service
type
private unpriv chroot wakeup maxproc command
#
(yes) (yes)
(yes) (never) (100)
# ================================================================
...
meinfilter ᆺ unix
n
2
smtp ᆻ
-o smtp_data_done_timeout=1200s ᆼ
-o disable_dns_lookups=yes ᆽ
...
ᆺ Die Zeile, die mit meinfilter anfängt, ist die wichtigste Zeile: In ihr definieren die
acht Spalten (service, type, private, unpriv, chroot, wakeup, maxproc und command) die Eigenschaften des Transports meinfilter.
ᆻ Die 1. Spalte legt den service-Namen fest, der mit dem aus main.cf übereinstimmen
muss.
ᆼ Die Spalte command enthält den Namen des Postfix-Daemons, der den Transport
realisiert, sowie ggf. zusätzliche Parameter. Diese befinden sich in unserem Beispiel
der Lesbarkeit halber auf den nächsten Zeilen. Da diese Zeilen aber alle mit Leerzeichen beginnen, setzen Sie die vorige Zeile immer fort.
ᆽ Beachten Sie, dass zwischen Parametern (z.B. disable_dns_lookups), dem Gleichheitszeichen »=« und dem Wert yes keine Leerzeichen stehen dürfen, weil Postfix das
Kommando sonst nicht richtig interpretieren kann.
Damit haben Sie einen Transport meinfilter konfiguriert, der seine Daten per smtpClient mit maximal zwei gleichzeitigen Instanzen sendet. Der smtp-Client hat einen
erhöhten Timeout, damit er nicht gleich abbricht, wenn der externe Content-Filter
ein wenig länger braucht, und der Client führt keine DNS-Lookups durch, weil wir
auf localhost senden, und das sind wir ja selber.
188
13 Wie externe Content-Filter funktionieren
So weit, so gut. Postfix kann jetzt also E-Mails an das externe Programm weitergeben. Damit hat die E-Mail dann Postfix und damit den regulären Zustellweg
verlassen. Jetzt benötigen wir einen Wiedereintrittspunkt, damit die E-Mail wieder
in den normalen Zustellweg zurückgebracht werden kann.
Wiedereintritt für content_filter definieren
Ein Wiedereintrittspunkt ist nichts anderes als ein weiterer Daemon, der E-Mail annimmt. Allerdings haben wir spezielle Anforderungen an diesen Daemon, denn er
darf sich nicht aller globalen Konfigurationen aus main.cf bedienen, sondern muss
den dort gesetzten content_filter ignorieren. Andernfalls würde dieser Daemon die
soeben vom Filter angenommene E-Mail sofort wieder an den Filter senden lassen.
Im Regelfall benützen Sie einfach eine weitere Instanz eines smtpd-Daemon und
versehen diese mit speziellen Optionen, damit diese beispielsweise nur auf
localhost (127.0.0.1) ansprechbar ist und den content_filter aus main.cf ignoriert.
Für unser Beispiel legen wir dazu in master.cf einen smtpd-Damon an, der auf
localhost, Port 10025 horcht:
#=================================================================
# service type
private unpriv chroot wakeup maxproc command
#
(yes) (yes)
(yes) (never) (100)
# ================================================================
...
127.0.0.1:10025 ᆺ inet ᆻ n
n
smtpd
-o content_filter= ᆼ
-o receive_override_options=no_unknown_recipient_checks ᆽ
-o smtpd_recipient_restrictions=permit_mynetworks,reject ᆾ
-o mynetworks=127.0.0.0/8 ᆿ
...
Der ganze Eintrag ist nicht anders als eine Kopie des normalen smtpd-Eintrages aus
master.cf. Wir haben lediglich die erste Spalte und die Optionen abgewandelt:
ᆺ In der ersten Spalte sehen Sie, dass dieser smtpd auf 127.0.0.1, Port 10025 horcht.
ᆻ Hier ist der Typ inet (für Internet, statt unix für Unix Domain Socket wie in dem
Eintrag für den Transport meinfilter).
Hinweis
Sie können Dienste vom Typ inet in der Form host:port ohne vorherige Definition
in main.cf anlegen. host kann dabei ein Hostname oder eine IP-Adresse aus /etc/
hosts sein und port ein Servicename oder eine Portnummer aus /etc/services.
Wenn Sie host weglassen, bindet das den service an alle Interfaces, die mit
dem inet_interfaces-Parameter für Postfix freigegeben wurden!
ᆼ Diese Option setzt den content_filter aus main.cf außer Kraft!
13. 3 content_filter und Adressumschreibung
189
ᆽ Diese Option deaktiviert den Test auf unbekannte lokale Empfänger (gegen
local_recipient_maps, relay_recipient_maps), weil der andere, externe smtpd dies
schon für uns erledigt hat.
ᆾ Die letzten beiden Parameter zusammen erlauben lediglich dem Netz 127.0.0.0/8,
E-Mails über diesen smtpd zu versenden. Selbst wenn Sie versehentlich diesen smtpd
an alle Interfaces binden lassen sollten, könnte er doch nicht von anderen Netzen
genutzt werden.
ᆿ Siehe ᆾ
Ein Beispiel für IPv6 tauscht lediglich die IP-Adresse aus:
#=================================================================
# service type
private unpriv chroot wakeup maxproc command
#
(yes) (yes)
(yes) (never) (100)
# ================================================================
...
[::1]:10025 inet n
n
smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=[::1]/128
...
Mit diesem letzten Schritt hätten Sie einen kompletten content_filter in Postfix konfiguriert.
13. 3
content_filter und Adressumschreibung
Wenn Sie Adressen umschreiben lassen (z.B. durch virtual_alias_maps), sollten Sie
sich überlegen, ob Sie dies vor oder nach dem Filtervorgang durchführen lassen.
Schreiben Sie die Adressen vor dem Filtern um, riskieren Sie, Bounces oder Warnmitteilungen an interne Adressen zu verschicken. Eine Warnung auf eine Mail, die
ursprünglich an homer_simpson@example.com ging, könnte beispielsweise den internen
User- und Servernamen hs123@mailbox.example.com erhalten haben; der Empfänger
einer solchen Mail wäre zu Recht verwundert, denn er hat die E-Mail nie an diese
Adresse geschickt.
Aus unserer Sicht ist es daher am sinnvollsten, dem Filter die Adressen in ihrer
unverfälschten Form zu übergeben und die Adressumschreibung erst hinter dem Filter
stattfinden zu lassen. Dies erlaubt es dem externen Programm, die Originaladressen
zu sehen.
Sie haben zwei Möglichkeiten, die Adressumschreibung zu deaktivieren. Die erste
setzt global in main.cf an:
receive_override_options = no_address_mappings
Die zweite Methode geht selektiv vor und beeinflusst jene smtpd-Instanz, die E-Mail
aus dem Internet annimmt, über einen Eintrag in master.cf:
190
13 Wie externe Content-Filter funktionieren
smtp
inet n
n
smtpd
-o content_filter=meinfilter:[127.0.0.1]:54321
-o receive_override_options=no_address_mappings
...
Hat der Filter die Mail bearbeitet, wird sie üblicherweise wieder in den Zustellprozess
von Postfix zurückgeführt; das ist der Zeitpunkt, an dem die Adressumschreibung
stattfinden sollte. Dann benötigen Sie z.B. eine zusätzliche smtpd-Instanz, die interne
E-Mail annimmt, sie aber nicht noch einmal der Filterung unterwirft, sondern nur
die
Adressumschreibung
veranlasst.
Anstelle
der
Option
receive_override_options=no_address_mappings benutzt diese zweite, interne smtpd-Instanz die Option receive_override_options=no_unknown_recipient_checks (die erste
smtpd-Instanz hat dies ja schon gemacht). Mehr Details zu content_filter und
smtpd_proxy_filter folgen in den nächsten Abschnitten.
13. 4
smtpd_proxy_filter: Erst filtern, dann queuen
Wenn Sie den smtpd_proxy_filter-Mechanismus nutzen wollen, müssen Sie dazu
die Konfiguration des bestehenden smtpd-Daemon (der smtpd vor dem Filter) so abändern, dass dieser SMTP-Verbindungen an ein externes Programm durchreicht
(Abb. 13-2).
Hinweis
Es wäre auch möglich, das externe Programm direkt Verbindungen annehmen zu
lassen und dieses nach getaner Arbeit die E-Mail an Postfix weiterreichen zu lassen.
Nicht alle Software ist jedoch so robust geschrieben wie Postfix, sodass dies ein
Sicherheitsrisiko darstellen könnte.
Lassen Sie lieber Postfix »den Kopf aus dem Fenster strecken«, und es wird
den SMTP-Datenstrom aufarbeiten, potenziell gefährliche Dinge wie ESMTP-Pipelining, lange Argumente und seltsame Zeichen ausfiltern, und an das externe
Programm weitergeben.
Generell sieht ein smtpd_proxy_filter-Zustellprozess wie folgt aus:
1. Der smtpd vor dem Filter baut eine Verbindung zu dem externen Programm auf.
2. Der smtpd vor dem Filter reicht die SMTP-Kommandos und die Maildaten an das
externe Programm weiter.
3. Das externe Programm hält die Verbindung offen, während es die Mail verarbeitet.
4. Wenn das externe Programm die Mail akzeptiert, kann es sie an den smtpd hinter
dem Filter übergeben oder sie an einen anderen Filter oder MTA senden.
191
13. 4 smtpd_proxy_filter: Erst filtern, dann queuen
5. Nach der Entscheidung (Ablehnen oder Annehmen) sendet das externe Programm den entsprechenden SMTP-Statuscode (250 OK oder 554 Reject) an den
smtpd-Daemon vor dem Filter.
6. Der smtpd-Daemon vor dem Filter reicht diese Antwort an den Client weiter.
Internet
Mailserver/
Mailclient
Mailserver
Filter-Software
Postfix
before-filter
Filter
smtpd
cleanup
after-filter
smtpd
qmgr
pipe
local
smtp
uucp
Mailbox
tcp
Internet
Mailserver
Mailserver
Abb. 13-2: Zustellprozess mit einem smtpd_proxy_filter
192
13.4.1
13 Wie externe Content-Filter funktionieren
Betrachtungen zum Proxy-Filter
Wenn Sie mit dem smtpd_proxy_filter arbeiten wollen, bedenken Sie die folgenden
Punkte:
ESMTP-Kommunikation
Wenn Postfix eine Mail an den Filter schickt, wird ESMTP, aber kein Command Pipelining benutzt. Postfix' smtpd erzeugt seine eigenen EHLO-, XFORWARD(fürs Loggen der Client-IP statt nur localhost, das ja der wirkliche Client
ist), DATA- und QUIT-Kommandos. Ansonsten werden unveränderte Kopien
der MAIL FROM- und RCPT TO-Kommandos durchgereicht, die der smtpd vor dem
Filter vom Client erhält.
Anforderungen an das externe Programm
Der Filter (der natürlich SMTP sprechen muss) sollte dieselbe MAIL FROMund RCPT TO-Kommandosyntax wie Postfix' smtpd verstehen.
Reinjizierung
Der Filter muss die SMTP-Kommandos vom smtpd vor dem Filter ohne Änderungen an den smtpd nach dem Filter durchreichen.
Abweisen von Inhalten
Wenn der Filter Inhalte abweist, so muss er einen abschlägigen SMTP-Statuscode (also einen 5xx-Code) an den smtpd vor dem Filter zurückliefern und dann
die Verbindung mit dem smtpd hinter dem Filter abbrechen ohne die SMTPKommunikation abzuschließen! Anderenfalls könnte der smtpd hinter dem
Filter die Mail versehentlich doch zustellen!
13.4.2
Grundlagen für die Konfiguration eines smtpd_proxy_filter
Sie müssen zuerst das Verhalten des bestehenden smtpd-Daemons verändern, damit
ein Filtern mit dem smtpd_proxy_filter-Parameter möglich wird. Die folgenden zwei
Schritte sind nötig:
1. Sie müssen den bestehenden smtpd anpassen. Wir nennen ihn ab jetzt »smtpd vor
dem Filter«.
2. Sie müssen einen zusätzlichen Punkt zum Wiedereintritt einer E-Mail in Postfix
definieren.
Anpassung des bestehenden smtpd (smtpd vor dem Filter)
Um den bestehenden smtpd-Daemon Verbindungen an den externen Content-Filter
weiterreichen zu lassen, müssen Sie in der smtpd-Zeile in master.cf die Option
smtpd_proxy_filter einfügen. Sie müssen dabei das Ziel, also Hostname oder IPAdresse und Port, angeben, auf dem der Content-Filter erreichbar ist:
13. 4 smtpd_proxy_filter: Erst filtern, dann queuen
193
#=================================================================
# service type
private unpriv chroot wakeup maxproc command
#
(yes) (yes)
(yes) (never) (100)
# ================================================================
...
smtp
inet
n
n
20
smtpd
-o smtpd_proxy_filter=localhost:10024
Wiedereintritt für smtpd_proxy_filter definieren
Den Wiedereintritt für E-Mails des externen Content-Filter definieren Sie, mit einer
Ausnahme, genau so wie beim »Wiedereintritt für content_filter definieren« auf Seite
188. Dieses Mal müssen Sie nicht den content_filter aus main.cf außer Kraft setzen,
sondern den smtpd_proxy_filter, wie Ihnen das folgende Beispiel zeigt:
#=================================================================
# service type
private unpriv chroot wakeup maxproc command
#
(yes) (yes)
(yes) (never) (100)
# ================================================================
...
# Beispiel für IPv4
127.0.0.1:10025
inet n
n
smtpd
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o receive_override_options=no_unknown_recipient_checks
-o content_filter=
-o smtpd_proxy_filter=
# Beispiel für IPv6:
[::1]:10025
inet n
n
smtpd
-o smtpd_authorized_xforward_hosts=[::1]/128
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=[::1]/128
-o receive_override_options=no_unknown_recipient_checks
-o content_filter=
-o smtpd_proxy_filter=
Document
Kategorie
Technik
Seitenansichten
8
Dateigröße
584 KB
Tags
1/--Seiten
melden