Die Integration von amavisd-new in den Postfix Zustellprozess setzt voraus, dass Postfix externe Content Filter einbinden kann. Die früheste Postfix-Version, die den content_filter-Parameter unterstützt, ist Postfix release-20010228.

Treten während der Integration von amavisd-new Fehler in der Konfiguration von Postfix auf, kann es schnell passieren, dass Postfix diese Fehler als endgültig klassifiziert. Postfix bricht die Zustellung ab, sendet eine Fehlermeldung an den Absender (bounce) und eine weitere, nach Korrektur des Fehlers, möglicherweise erfolgreiche Zustellung wird nicht stattfinden.

Die Aktivierung des soft_bounce-Parameters verhindert, dass E-Mails bei Zustellungsfehlern sofort gebounced werden. Der Parameter kann mit einem Editor in /etc/postfix/main.cf eingetragen werden oder mit Hilfe des postconf-Kommandos. Anschließend wird die neu Konfiguration mit postfix reload aktiviert:

# /usr/sbin/postconf -e "soft_bounce = yes"
# postfix reload

Postfix wird jetzt alle Fehler als temporäre Fehler behandeln und im Fehlerfall die E-Mails in seiner Mailqueue behalten, damit weitere Zustellversuche nach Korrektur evtueller Fehler vorgenommen werden können.

	Wichtig
	Nach der Integration von amavisd-new muss soft_bounce wieder deaktiviert werden, sonst wird Postfix keine Zustellfehler an die Absender von E-Mails melden!

Die Postfix-spezifische Anpassung einer amavisd-new-Konfiguration beantwortet die folgenden zwei Fragestellungen:

$inet_socket_port = 10024;

$notify_method  = 'smtp:[192.0.2.1]:20025';
$forward_method = 'smtp:[192.0.2.1]:20025';

Als erstes gilt es, einen dedizierten Transport einer E-Mail von Postfix zum amavisd-new-Daemon hin einzurichten. Der amavisd-Server ist in der Lage, Postfix sowohl eine SMTP- als auch eine LMTP-Session zur Übermittlung von E-Mail anzubieten.

Postfix kann, entweder mit dem smtp-Client oder dem lmtp-Client, beide Arten der Übermittlung nutzen. Dieser Abschnitt beschreibt die notwendigen Konfigurationsschritte für beide Arten.

	Anmerkung
	Postfix benötigt für den Transport zu amavisd-new entweder einen dedizierten smtp-Service oder einen dedizierten lmtp-Service. Aufgrund der erweiterten Fähigkeiten des LMTP-Protokolls - es kann bei einer Mail an mehrere Empfänger, einen Empfänger getrennt von allen anderen Empfängern über einen Fehler bei der Zustellung unterrichten - ist der Einsatz des lmtp-Clients vorzuziehen.

Warum überhaupt einen dedizierten Client einrichten?

Grundsätzlich wäre es möglich einen, der in /etc/postfix/master.cf bereits vorkonfigurierten, lmtp-, smtp- oder relay-Services für den Transport von E-Mails von Postfix zu amavisd-new hin zu nutzen.

Für den Einsatz eines solchen Clients mit amavisd-new müssen jedoch einige, besondere Konfigurationseinstellungen vorgenommen werden, die für diese global genutzten Clients von Nachteil hinsichtlich Performance und Skalierbarkeit wären.

Anmerkung

Es ist z.B. notwendig, die Anzahl der maximalen, gleichzeitig betriebenden Prozesse des dedizierten Clients auf die maximale Anzahl gestarteter amavisd-new-Daemon Kind-Prozesse abzustimmen. Wäre die Anzahl der Postfix Client-Prozesse höher als die der amavisd-new-Daemon Kind-Prozesse, würde es unter Last zu einer Abweisung des Postfix-Clients kommen, weil der amavisd-new-Daemon keine weiteren Verbindungen mehr annehmen kann und Postfix würde dies als (temporären) Fehler bei der Zustellung werten und die Absender der verzögerten Nachricht unnötigerweise davon in Kenntnis setzen.

1.2.2.1. Dedizierten lmtp-Client einrichten

Das folgende Listing fügt einen dedizierten lmtp-Client mit dem Namen amavisfeed in /etc/postfix/master.cf hinzu. Eine Erläuterung der Konfiguration folgt im Anschluss:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================

...

amavisfeed unix  -       -       n       -       2       lmtp
    -o lmtp_data_done_timeout=1200
    -o lmtp_send_xforward_command=yes
    -o disable_dns_lookups=yes

	Wichtig
	Service-spezifische Optionen werden in master.cf zeilenweise und eingerückt (leading whitespace) angegeben. Parameter und Werte müssen ohne Leerzeichen mit einem Ist-Gleich-Zeichen „=“ verbunden werden. Mehr dazu in master(5) oder master.cf selbst.

Hier ist eine Erläuterung der, vom Standard abweichenden Einstellungen:

maxproc

Die maximale Anzahl gleichzeitiger Postfix-amavisfeed-Service-Prozesse ist auf 2 (Standard: default_process_limit = 100) eingeschränkt. Dies ein guter Anfangswert, für eine Basiskonfiguration. Der Wert kann später angehoben werden, wenn das Gesamtsystem die damit steigende Last verarbeiten kann.

lmtp_data_done_timeout

Während der Überprüfung hält amavisd-new grundsätzlich die Verbindung zum Postfix amavisfeed-Service offen. amavisd-new beendet die Verbindung erst, wenn die E-Mail oder eine durch die Untersuchung ausgelöste Benachrichtigung, über den Rücktransport erfolgreich im Postfix System angelangt sind.

Es könnte sein, dass amavisd-new sehr lange benötigt, um eine E-Mail zu überprüfen. Damit der Postfix amavisfeed-Service während dieser Wartezeit nicht in einem timeout gerät, wird der timeout-Zeitraum verdoppelt (Standardwert: 600 [Sekunden]) und somit auf den Timeout-Wert von amavisd-new gesetzt.

lmtp_send_xforward_command

amavisd-new bzw. SpamAssassin können die IP-Adresse und den hostnamen des anliefernden Clients mit in die Beurteilung der Spamhaftigkeit einer E-Mail einbeziehen. Im Normalfall "sieht" amavisd-new nur die IP-Adresse und den Clientnamen des Postfix lmtp-Clients, wenn dieser sich mit amavisd-new verbindet.

Der aktivierte lmtp_send_xforward_command-Parameter instruiert Postfix den ursprünglichen Clientnamen und dessen IP-Adresse an amavisd-new über XFORWARD an amavisd-new weiterzugeben, sodass dieser den echten Hostnamen nutzen und loggen kann. Die Postfix man-Page lmtp(8) und das XFORWARD_README dokumentieren diese Erweiterung von Postfix.

disable_dns_lookups

Der Transportweg von Postfix zu amavisd-new, er wird später in Abschnitt 1.3, „Filter-Beispiele“ definiert, ist immer derselbe. Er wird sich - wahrscheinlich - nur bei einer Rekonfiguration des ganzen Systems ändern.

Weil der Transportweg sich nicht ändert, kann er (statisch) als IP-Adresse angegeben werden und muss nicht jedesmal „teuer“ über DNS-Abfragen aufgelöst werden. Dies spart drei DNS-Abfragen und somit Zeit und Ressourcen.

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================

...

amavisfeed unix  -       -       n       -      2        smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes

Der zweite Dienst, den es noch einzurichten gilt, schafft einen dedizierten SMTP-Server, dessen Aufgabe einzig und allein darin besteht, E-Mails, die von amavisd-new überprüft wurden, anzunehmen und in den Postfix Zustellprozess zurückzuführen.

Dazu wird eine weitere, dedizierte Instanz des Postfix smtpd-Daemon in master.cf hinzugefügt. Diese Instanz unterscheidet sich vor allem dadurch, dass sie den content_filter-Parameter ohne einen Wert setzt und damit bestehende Delegationen an externe Content Filter aufhebt.

	Wichtig
	Die Delegation von E-Mails an amavisd-new wird über den content_filter-Parameter konfiguriert. Fehlt der leere content_filter-Parameter, wird die aus amavisd-new rückkehrende E-Mail sofort wieder an amavisd-new delegiert und die E-Mail befindet sich somit in einem Endlos-Kreislauf.

Das folgende Beispiel greift die Standard-Einstellungen der amavisd-new $forward_method- und $notify_method-Parameter auf und konfiguriert deshalb einen dedizierten smtpd-Daemon, der auf localhost (127.0.0.1) und Port 10025 eingehende Verbindungen entgegennimmt.

Dazu müssen folgende Angaben in master.cf hinzugefügt werden:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================

...

127.0.0.1:10025 inet n  -       n       -       -       smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_delay_reject=no
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Hier ist eine Erläuterung der, vom Standard smtpd-Daemon, abweichenden Einstellungen:

Nach der Konfiguration stellen das postfix-Kommando, zusammen mit der Option reload ausgeführt, und ein Blick in die Maillog-Datei sicher, dass Postfix keine syntaktischen Probleme der neuen Konfiguration bemängelt:

# postfix reload && tail -f /var/log/maillog

Meldet das Maillog keine Fehler, kann mit dem Test der neuen Funktionalitäten begonnen werden.

Der Test der neuen Funktionalitäten besteht aus drei Einzeltests, die den Zustellprozess sozusagen „von hinten aufrollen“ und dabei folgende Fragen beantworten:

$ telnet localhost 10024
220 [127.0.0.1] ESMTP amavisd-new service ready
EHLO localhost
250-[127.0.0.1]
250-VRFY
250-PIPELINING
250-SIZE
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 XFORWARD NAME ADDR PROTO HELO
QUIT
221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel

$ telnet 127.0.0.1 10025
220 mail.example.com ESMTP Postfix
EHLO localhost
250-mail.example.com
250-PIPELINING
250-SIZE 40960000
250-ETRN
250-STARTTLS
250-AUTH PLAIN CRAM-MD5 LOGIN DIGEST-MD5
250-AUTH=PLAIN CRAM-MD5 LOGIN DIGEST-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
221 2.0.0 Bye

$ telnet localhost 10024
220 [127.0.0.1] ESMTP amavisd-new service ready
HELO localhost
250 [127.0.0.1]
MAIL FROM: <>
250 2.1.0 Sender  OK
RCPT TO: <postmaster>
250 2.1.5 Recipient postmaster OK
DATA
354 End data with <CR><LF>.<CR><LF>
From: virus-tester
To: undisclosed-recipients:;
Subject: amavisd test - simple - no spam test pattern

This is a simple test message from the amavisd-new test-messages.
.
250 2.6.0 Ok, id=30897-02, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 079474CE44
QUIT
221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel

Nov  1 11:28:10 mail postfix/smtpd[30986]: connect from localhost[127.0.0.1] 
Nov  1 11:28:10 mail postfix/smtpd[30986]: 079474CE44: client=localhost[127.0.0.1]
Nov  1 11:28:10 mail postfix/cleanup[30980]: 079474CE44: message-id=<20061101102810.079474CE44@mail.example.com>
Nov  1 11:28:10 mail postfix/qmgr[20432]: 079474CE44: from=<>, size=822, nrcpt=1 (queue active)
Nov  1 11:28:10 mail amavis[30897]: (30897-02) Passed BAD-HEADER, <> -> <postmaster>, quarantine: badh-le5gjszxowBk, mail_id: le5gjszxowBk, Hits: -1.76, queued_as: 079474CE44, 39505 ms 
Nov  1 11:28:10 mail postfix/smtpd[30986]: disconnect from localhost[127.0.0.1]
Nov  1 11:28:10 mail postfix/local[30987]: 079474CE44: to=<postmaster@example.com>, relay=local, delay=0.27, delays=0.14/0.05/0/0.08, dsn=2.0.0, status=sent (delivered to mailbox: postmaster) 
Nov  1 11:28:10 mail postfix/qmgr[20432]: 079474CE44: removed

In den meisten Fällen wird global - jede ein- und ausgehende E-Mail - gefiltert. Globale wirkende Einstellungen werden in Postfix in main.cf vorgenommen. Dort muss der content_filter-Parameter, der ein Versenden einer E-Mail an amavisd-new veranlaßt, eingefügt werden.

Der content_filter-Parameter verlangt die Angabe eines triplets, das aus service-Name (Name des in Abschnitt 1.2.2, „Transport von Postfix zu amavisd-new einrichten“ eingerichteten Dienstes), IP-Adresse und Port des Ziel-Dienstes besteht. Den Daten der vorhergenden Beispiele folgend, ergibt sich folgender Eintrag in main.cf:

content_filter=amavisfeed:[127.0.0.1]:10024

Nach einen postfix reload ist der externe Content Filter aktiviert und mit einer Test-E-Mail kann geprüft werden, ob sie bis in die Mailbox des Empfängers zugestellt wird.

Postfix kann E-Mails service-bezogen filtern. Der content_filter-Parameter, der E-Mails an amavisd-new delegiert, muss dazu - nicht wie in Abschnitt 1.3.1, „E-Mails global filtern“ angegeben - global in main.cf gesetzt werden, sondern service-bezogen in master.cf.

Das folgende Beispiel geht davon aus, dass der Postfix-Server über mehrere, konfigurierte Ethernet-Interfaces mit den IP-Adressen 192.0.34.166 (WAN), 127.0.0.1 (localhost) und 10.0.0.254 (LAN) verfügt.

Zuerst wird der globale Service smtp, der den smtpd-Daemon (command) aufruft, ausser Betrieb genommen. Anschließend werden drei separate Dienste, für jede IP-Adresse einer, erstellt. Der Service 192.0.34.166:25, für das WAN-Interface, erhält zusätzlich die Option content_filter:amavisfeed:[127.0.0.1]:10024, damit alle eingehenden E-Mails zur Überprüfung an amavisd-new delegiert werden.

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
# smtp      inet  n       -       n       -       -       smtpd

...

192.0.34.166:25 inet n  -       n       -       -       smtpd
    -o content_filter=amavisfeed:[127.0.0.1]:10024
    -o receive_override_options=no_address_mappings

10.0.0.254:25   inet n  -       n       -       -       smtpd

127.0.0.1:10025 inet n  -       n       -       -       smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -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 strict_rfc821_envelopes=yes
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Postfix kann E-Mails je nach eingehender Empfänger-Domain filtern. Dazu wird der content_filter-Parameter nicht, wie in Abschnitt 1.3.1, „E-Mails global filtern“ angegeben, global in main.cf gesetzt, sondern eine Map erstellt, die die zu prüfenden Empfänger-Domains zusammen mit der FILTER-Aktion listet.

Diese Filtermethode arbeitet nicht selektiv!

Jede E-Mail, die eine in der Map gelistete Empfänger-Domain enthält wird an amavisd-new gesendet werden. Auch dann, wenn die E-Mail weitere Empfänger benennt, deren Adresse das Filtern nicht auslösen oder möglicherweise ausdrücklich nicht gefiltert werden sollen. Wenn vollständig selektiv wirkende Filter-Methoden erforderlich sind, sollten E-Mails global an amavisd-new gesendet werden und die amavisd-new eigenen Regelsätze herangezogen werden, um ein präzises Filtern zu ermöglichen.

Die folgende Beispiel-Map /etc/postfix/filter_recipient_domains legt fest, dass für die Domain example.com E-Mails an den Filter amavisfeed gesendet werden sollen:

example.com               FILTER amavisfeed:[127.0.0.1]:10024

Mit dem Kommando postmap wird die Datei /etc/postfix/filter_recipient_domains anschließend in eine indizierte Map umgewandelt:

# postmap /etc/postfix/filter_recipient_domains

Ein weiterer Aufruf des postmap-Kommandos testet die Map, indem es nach der Domain example.com fragt. Findet postmap den Domain-Namen, listet es die damit verbundene Aktion auf:

# postmap -q "example.com" /etc/postfix/filter_recipient_domains
FILTER amavisfeed:[127.0.0.1]:10024

Die getestete Map wird anschließend in die Liste der smtpd_recipient_restrictions in main.cf eingebunden. Als Auslöser für die Prüfung der Map dient dabei der Postfix check_recipient_access-Parameter - er spricht auf den envelope-recipient an, den ein SMTP-Client in einer SMTP-Session an Postfix übergeben hat.

Das folgende Beispiel bindet die Map so ein, dass sie auf alle Clients angewendet wird:

smtpd_recipient_restrictions =
    ...
    check_recipient_access hash:/etc/postfix/filter_recipient_domains
    ...
    permit_mynetworks
    reject_unauth_destination
    ...

E-Mails pro Empfänger-Domain nur von externen Clients filtern

Dieses Beispiel bindet die Map so ein, dass nur Inhalte fremder (externer) Clients, die eine zu überprüfende Empfänger-Domain angegeben haben, an amavisd-new übergeben werden. Dies geschieht, indem vorher alle bekannte (interne) Clients durch die permit_mynetworks-Restriktion, von einer weiterer Auswertung der smtpd_recipient_restrictions ausgenommen werden:

smtpd_recipient_restrictions =
    ...
    permit_mynetworks
    reject_unauth_destination
    check_recipient_access hash:/etc/postfix/filter_recipient_domains

Generell macht es wenig Sinn, E-Mails anhand der Sender-Domain zu filtern, denn die Angabe der Sender-Domain im envelope-sender während einer SMTP-Session kann auf das Einfachste gefälscht werden.

Sinnvoll ist Filter pro Sender-Domain nur dann, wenn nicht global gefiltert wird, aber sichergestellt werden soll, dass alle ausgehenden E-Mails der eigenen Domain viren- und spamfrei sind.

	Anmerkung
	Die Konfiguration folgt im Wesentlichen den Angaben in Abschnitt 1.3.3, „E-Mails pro Empfänger-Domain filtern“, nur dass zum Filtern pro Sender-Domain der check_recipient_access-Parameter durch den check_sender_access-Parameter ausgetauscht wird.

Eine Map, z.B. /etc/postfix/filter_sender_domains, die das Filtern der Sender-Domain example.com veranlassen soll, sieht wie folgt aus:

example.com               FILTER amavisfeed:[127.0.0.1]:10024

Nach der Konvertierung der map mit postmap /etc/postfix/filter_sender_domains, wird die Map wie folgt in die smtpd_recipient_restrictions eingebaut:

smtpd_recipient_restrictions =
    ...
    check_sender_access hash:/etc/postfix/filter_sender_domains
    ...
    permit_mynetworks
    reject_unauth_destination
    ...

	Wichtig
	Die Map muss vor permit_mynetworks geprüft werden, denn nur dann findet sie auch Anwendung auf jene Clients, die aus mynetworks stammen.

Postfix kann, mit bewußten Einschränkungen (siehe Postfix: BUILTIN_FILTER_README), den Inhalt von header, body und auch MIME-header durchsuchen und bei einem Treffer Aktionen wie z.B. den Aufruf einers Filters veranlassen.

Das folgende Beispiel zeigt wie Postfix, wenn es den String offer im Subject:-Header einer E-Mail findet, diese zur Überprüfung an amavisd-new delegiert. Dazu wird eine Map /etc/postfix/filter_header erstellt, die ein passendes regexp-Suchmuster und die dazugehörige Aktion enthält:

/^Subject:*.offer/   FILTER amavisfeed:[127.0.0.1]:10024

	regexp- oder pcre-Map indizieren?
	regexp- oder pcre-Map sind und bleiben reine Text-Dateien. Sie müssen und können auch nicht mit dem postmap-Kommando in ein indiziertes Datenbankformat überführt werden. Tests der regexp- oder pcre-Maps mit dem postmap-Kommando und der Option -q sind allerdings möglich und sinnvoll.

Anschließend wird die Map in main.cf eingebunden. Weil in diesem Beispiel der Header einer E-Mail geprüft werden soll, wird dazu der header_checks-Parameter (und nicht body_checks oder mime_header_checks) verwendet:

header_checks = regexp:/etc/postfix/filter_header

Nach einem postfix reload wird Postfix jede E-Mail mit dem Wort offer im Subject:-Header zur Überprüfung an amavisd-new delegieren.

Wer mehr Kontrolle über den cleanup-Daemon haben möchte, als mit den receive_override_options möglich ist, muss mehrere Instanzen des cleanup-Daemon nutzen. Das ist entweder mit einem Multiple-Instance-Postfix (ab Postfix 2.6.) möglich oder indem mehrere cleanup-Dienste in master.cf mit entsprechenden Optionen konfiguriert und betrieben werden.

Das folgende Diagramm zeigt ein Setup mit zwei cleanup-Daemonen in einer einzigen Postfix-Instanz:

      .......................................
      :                Postfix              :
   ----->smtpd \                            :
      :         -pre-cleanup-\       /local---->
   ---->pickup /              -queue-       :
      :             -cleanup-/   |   \smtp----->
      :     bounces/    ^        v          :
      : and locally     |        v          :
      :   forwarded   smtpd  amavisfeed     :
      :    messages   10025      |          :
      ...........................|...........
                        ^        |
                        |        v
            ............|...............................
            :           |   $inet_socket_port=10024    :
            :           |                              :
            : $forward_method='smtp:[127.0.0.1]:10025' :
            : $notify_method ='smtp:[127.0.0.1]:10025' :
            :                                          :
            :    amavisd-new                           :
            ............................................

Folgende Schritte sind notwendig, um zwei unabhängige und dedizierte cleanup-Daemonen für zwei smtpd-Daemonen bereit zu stellen:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
# smtp      inet  n       -       n       -       -       smtpd

...

pre-cleanup unix    n       -       n       -       0       cleanup
    -o virtual_alias_maps= 

1.4.2.2. Modifizieren des bestehenden cleanup-Dienstes

Der originäre cleanup-Dienst mit dem Servicenamen cleanup ist in diesem Beispiel für Nachrichten zuständig, die nach dem content filter wieder in das Postfix-Mailsystem zurückgeschleift werden sollen.

Aufgaben, die bereits der pre-cleanup-Service durchgeführt hat, sollen jetzt nicht ein weiteres Mal durchgeführt werden. Das folgende Beispiel deaktiviert Tests, die ein pre-cleanup-Service typischerweise schon absolviert hat:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
# smtp      inet  n       -       n       -       -       smtpd

...

cleanup unix    n       -       n       -       0       cleanup
    -o mime_header_checks= 
    -o nested_header_checks= 
    -o body_checks= 
    -o header_checks= 

Diese Angaben deaktivieren für pre-cleanup-Dienste typische Header- und Body-Checks.

	always_bcc-Parameter
	Diese, nachgelagerte cleanup-Instanz ist auch die richtige, um always_bcc-Optionen zu setzen. Würde die Option stattdessen global in main.cf gesetzt, beträfe sie beide cleanup-Dienste und es würden jeweils zwei Kopien einer Nachricht an den BCC:-Empfänger gesendet.

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
# smtp      inet  n       -       n       -       -       smtpd

...

pickup    fifo  n       -       n       60      1       pickup
    -o cleanup_service_name=pre-cleanup
smtp      inet  n       -       n       -       -       smtpd
    -o cleanup_service_name=pre-cleanup
submission inet n       -       n       -       -       smtpd
    -o cleanup_service_name=pre-cleanup

Die wichtigste Stellschraube beim Abstimmen und Optimieren von Postfix und amavisd-new aufeinander ist die Anzahl maximaler Content Filter Prozesse:

Ein in der Praxis erprobter, konservativer Startwert ist eine Anzahl von maximal 2 Content Filter Prozessen. Im Alltag kann dieser Wert oft bis auf maximal 10 Content Filter Prozesse gesteigert werden. Der genaue Wert hängt davon ab, welche Ressourcen das Host-System bereitstellen kann und welche Anforderungen die in amavisd-new eingebundene Anti-Virus und Anti-Spam-Software an das System stellen.

Auf jeden Fall ist es unbedingt notwendig, die Anzahl maximaler Content Filter Prozesse beider Dienste, Postfix und amavisd-new, aufeinander abzustimmen. In amavisd-new steuert der $max_servers-Parameter der Konfigurationsdatei amavisd.conf die Anzahl maximaler Content Filter Prozesse; in Postfix regelt dies der Feld-Eintrag maxproc in master.cf des dedizierten Transports zu amavisd.

Diese Werte sollten immer gleich sein. Bietet amavisd-new mehr Prozesse an, als von Postfix genutzt werden, werden Ressourcen verschwendet. Andersrum, wenn Postfix mehr dedizierte Transporte gleichzeitig startet als amavisd-new Verbindungen annehmen kann, wird der dedizierte Postfix Client abgewiesen und Fehler melden.

Anzahl maximaler Content Filter Prozesse in main.cf steuern

Anstatt die Anzahl maximaler Content Filter Prozesse in master.cf für den dedizierten Transport zu amavisd-new hin festzulegen, kann der Standardwert (100) mit „-“ in notiert werden und stattdessen folgender Parameter in main.cf gesetzt werden: amavisfeed_destination_concurrency_limit = 2 Der Name des Parameters beginnt mit dem Namen des Services in master.cf, hier amavisfeed, und setzt sich mit der Endung _destination_concurrency_limit fort. Als Vorgabe wird auch hier der konservative Wert 2 verwendet.

Weitere Optimierungs-Tipps finden Sie in der amavisd-new Dokumentation README.performance und den Folien des Vortrags amavisd-new, advanced configuration and management von Mark Martinec.