10.2    Antivirus- und Spam-Filter mit Amavisd-new, ClamAV und SpamAssassin

Amavisd-new, der Advanced Mail Virus Scanner Daemon, ist die Schnittstelle zwischen Postfix, SpamAssassin und filebasierten Antivirenprogrammen, die naturgemäß wenig von E-Mails und dem SMTP-Protokoll verstehen. Amavis wurde Mitte der 90er-Jahre ins Leben gerufen und hat sich zu einem mächtigen und sehr robusten Tool entwickelt, das alle möglichen Helfer unter seiner Haube vereint und koordiniert.

Vielerorten gilt es nach wie vor noch als gute Idee, dass E-Mails bei einem Spam- oder Virenbefund in einen Quarantäne-Ordner verschoben oder mit einer Spam-Markierung im Betreff zugestellt werden. Damit sollte zunächst vor allem das Problem gelöst werden, dass einmal angenommene E-Mails auch bei Spam- oder Virenbefund nicht einfach zum Absender zurückgesandt werden können, da die Absenderangaben dieser E-Mails typischerweise gefälscht sind und unschuldige Dritte sonst durch Millionen von E-Mail-Rückläufern außer Gefecht gesetzt werden würden. Wie bereits im Unterabschnitt »Dynamische Empfängervalidierung« des Abschnitts 10.1.3, »Die Postfix-Restrictions: Der Schlüssel zu Postfix«, erläutert wurde, sind Backscatter-Systeme eine echte Gefahr. Daher werden diese Systeme auch zu Recht in RBL-Sperrlisten aufgenommen.

Doch wenn Sie die hier vorgestellte Kombination von Postfix und Amavis nutzen, können Sie das Problem viel besser lösen: Im Handumdrehen installieren Sie damit ein System, das E-Mails noch während der Annahme, also in Echtzeit, nach Spam- und Virenmerkmalen durchsucht. Da die Mail sich noch in der Annahmephase befindet, kann sie nun im Falle eines Befundes noch gefahrlos abgelehnt werden.

Es handelt sich dabei um einen REJECT (die Mail wurde nie quittiert empfangen), was etwas völlig anderes ist als ein Bounce (die Mail wurde empfangen und kurz darauf zurückgesendet). Bei einem REJECT wird die Mail gegenüber dem ursprünglichen Client abgelehnt, sodass dieser sich überlegen muss, ob und wie er die Mail zurücksendet.

Backscatter-Bounces würden also nicht bei Ihnen, sondern beim einliefernden System entstehen – und Spam-Botnetze, die versuchen, bei Ihnen besagte Mails mit gefälschten Absendern einzuliefern, würden natürlich gar kein Bounce erzeugen, sondern die fehlgeschlagene Einlieferung abbrechen.

So schlagen Sie mehrere Fliegen mit einer Klappe:

Vor allem aber sorgen Sie dafür, dass im Falle eines False Positives, also einer fälschlicherweise gefilterten echten E-Mail, der Absender davon Kenntnis erhält, dass seine E-Mail den Empfänger nicht erreicht hat. Denn was ist die Realität? Versackt ein solcher False Positive in der Quarantäne, im Spam-Folder oder wird er gar ersatzlos gelöscht, erfahren weder der Absender noch der Empfänger davon, dass eine Mail nicht angekommen ist. Hilfreich ist das für die Beteiligten nicht und es war in der Vergangenheit auch bereits Gegenstand gerichtlicher Auseinandersetzungen mit empfindlichen Schadenersatzzahlungen desjenigen, der seine Mails in der Spam-Quarantäne verloren hat.

Aber keine Angst: Auch mit dem hier vorgestellten Setup könnten Sie weiterhin Mails in die Quarantäne filtern oder im Betreff markieren lassen, denn auch bei einer Echtzeit-Filterung können Sie Amavis anweisen, problematische Mails trotzdem zu akzeptieren und lediglich zu markieren. Sie können es – aber Sie müssen es nicht (mehr).

10.2.1    Installation

Beginnen Sie mit der Installation der benötigten Softwarepakete. Diese haben in aller Regel relativ viele Abhängigkeiten wie Packprogramme oder zahlreiche Perl-Bibliotheken. Wundern Sie sich nicht, wenn die endgültige Installationsliste etwas länger ausfällt. Sie benötigen die folgenden Pakete:

Die Razor- bzw. Pyzor-Pakete sind streng genommen nicht unbedingt notwendig, aber sehr zu empfehlen, denn diese Module erhöhen die Genauigkeit der Spam-Analyse.

Wenn alles installiert ist, geht es an die Konfiguration.

10.2.2    ClamAV konfigurieren

Unter openSUSE Leap arbeiten dank guter Paketierung Amavis und ClamAV sofort Hand in Hand zusammen, denn hier laufen sowohl Amavis als auch ClamAV unter der gemeinsamen Userkennung vscan.

Bei Debian-, Ubuntu- und CentOS-Systemen ist das leider nicht der Fall: Hier müssen Sie den User clamav noch der Gruppe amavis hinzufügen, damit ClamAV später auch auf die von Amavis unter seiner User-ID bereitgestellten Maildateien zugreifen und diese prüfen kann.

mail:~ # usermod -a -G amavis clamav

Listing 10.30    Debian, Ubuntu und CentOS: Hinzufügen des »clamav«-Users in die Amavis-Gruppe

Der Dienst freshclam wird sich um die Updates der ClamAV-Regeln kümmern; je nach Vorliebe Ihrer Distribution wird er regelmäßig per Cronjob aufgerufen oder als permanent laufender freshclamd im Hintergrund bleiben und alle zwei Stunden nach neuen Regeln schauen.

Die Pakete der Distributionen sind jedoch bereits etliche Wochen oder Monate alt – und die darin enthaltenen Regeln ebenfalls. Manche Distributionen liefern ClamAV darum gleich ganz ohne vorinstallierte Regelsätze aus. Damit Sie nicht auf den nächsten Cronjob warten müssen, bevor Sie ClamAV starten können, sollten Sie einmal freshclam von Hand ausführen. Bei CentOS- und openSUSE-Leap-Systemen können Sie dies als root durchführen:

mail:~ # freshclam

Listing 10.31    CentOS/openSUSE Leap: Der manuelle Start von »freshclam«

Bei Debian- und Ubuntu-Systemen hingegen müssen Sie dies als User clamav ausführen:

mail:~ # sudo clamav freshclam

Listing 10.32    Ubuntu: Der manuelle Start von »freshclam«

10.2.3    Updates für SpamAssassin konfigurieren

SpamAssassin bringt einen eigenen Dämon spamd mit, der – in Zusammenarbeit mit dem Client spamc – auch E-Mails empfangen und weiterleiten kann. Auch dafür finden Sie im Internet verschiedene Anleitungen.

Doch diese Aufgabe wird in unserem Szenario vollständig von Amavis übernommen, das SpamAssassin als Perl-Bibliothek nachlädt und benutzt. Anders als in anderen Anleitungen gezeigt, spielen spamd und spamc für uns keine Rolle, und alle SpamAssassin-bezogenen Konfigurationsarbeiten finden nicht in den SpamAssassin-Dateien /etc/mail/spamassassin/* statt, sondern werden über die Amavis-Konfiguration an SpamAssassin durchgereicht.

Wie ein Virenkiller benötigt auch SpamAssassin von Zeit zu Zeit aktualisierte Regeldateien und besitzt mit sa-update ein Tool zum Download neuer Regeln. Wenn man so will, handelt es sich dabei also um den (zweieiigen) Zwillingsbruder zu freshclam. Dabei wird sa-update von den Distributionen üblicherweise einmal täglich als Cronjob über /etc/cron.daily aufgerufen.

Auf Debian- und Ubuntu-Systemen müssen Sie den Cronjob sa-update in /etc/default/spamassassin noch manuell am Ende der Datei /etc/default/spamassassin aktivieren:

# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

Listing 10.33    Ubuntu: »sa-update« als täglichen Cronjob in »/etc/default/spamassassin« aktivieren

Beim nächsten Durchlauf der täglichen Cronjobs wird sa-update die SpamAssassin-Regeln per HTTP-Download vom SpamAssassin-Server laden und nach /var/lib/spamassassin entpacken.

Die Cron-Skripte der Distributionen werden gegebenenfalls auch Amavis neu starten, sodass Sie sich um nichts weiter kümmern müssen.

10.2.4    Amavisd-new konfigurieren

Die Konfigurationsdateien von Amavisd-new sind keine reinen Textdateien, sondern ausführbare Perl-Skripte. Aus diesem Grund muss ganz besonders auf die richtige Syntax geachtet werden. Vor allem die in Perl notwendigen permanenten Abschlüsse über ein Semikolon werden gerne vergessen und sind anfangs eine große Quelle für Frust. Beachten Sie also:

Als Erstes sollten Sie den per Default extrem schweigsamen Log-Level von Amavis hochsetzen, damit Sie vor allem während der Einrichtungsphase alle Dinge sauber nachvollziehen und kontrollieren können. Tragen Sie dazu bei Debian/Ubuntu in /etc/amavis/conf.d/50-user Folgendes ein:

use strict;
$log_level = 3;
1;  # insure a defined return

Listing 10.34    Anpassen des Log-Levels unter Debian/Ubuntu

Bei SUSE finden Sie in /etc/amavisd.conf und bei CentOS unter /etc/amavisd/amavisd.conf einen vorbereiteten Eintrag, den Sie nur aktivieren und anpassen müssen.

Log-Level 3 ist recht gesprächig, manchmal aufgrund der Fülle der Log-Zeilen sogar teilweise etwas verwirrend, doch protokolliert Amavis hier sehr genau, welche Spam-Merkmale einer E-Mail erkannt wurden und wie diese zum Gesamt-Score von SpamAssassin beigetragen haben. Später werden Sie den Log-Level im laufenden Betrieb vielleicht lieber auf $loglevel = 2; absenken wollen, um den Umfang der Meldungen etwas übersichtlicher zu halten. Amavisd-new lässt Ihnen die Wahl, ob Sie den Antivirusfilter, den Spam-Filter oder beides aktivieren möchten. Die Vorgehensweise ist für Debian/Ubuntu und CentOS/SUSE etwas unterschiedlich:

Amavis nutzt SpamAssassin, um die Spam-Wahrscheinlichkeit einer E-Mail zu berechnen, den Score. Je höher dieser Spam-Score ist, umso wahrscheinlicher ist es eine Spam-Mail. Auch wenn sehr gute E-Mails (Ham) am Ende sogar einen negativen Spam-Score aufweisen können, ist es noch lange nicht so, dass jeder Score-Wert über 0 bedeutet, dass die geprüfte E-Mail Spam ist.

Im Bereich von 0 bis 5 Score-Punkten tummeln sich Spam- und Ham-Mails gleichermaßen. Das Scoring von SpamAssassin ist dabei auch nicht willkürlich, es unterliegt komplexen statistischen Berechnungsmethoden, und so ist es auch kein Wunder, dass Filterregeln bis auf ein Tausendstel hinter dem Komma berechnete Punktwerte haben.

Im Gegenzug können Sie für jeden Score-Wert mathematisch genau ausrechnen, wie viele Spam- und wie viele Ham-Mails es statistisch mit dem jeweiligen Score-Wert gibt. Denn das gilt es zu bedenken: Wenn Sie festlegen, ab welchem Score-Wert Sie eine Nachricht als Spam ansehen, haben Sie einen Schieberegler vor sich, der sich stets zu beiden Seiten auswirkt. Filtern Sie zu lasch, lassen Sie zu viel Spam durch (False Negatives).

Filtern Sie zu aggressiv, filtern Sie zu viele echte Nachrichten (False Positives). Die Mathematik zeigt klar: Zwischen 6.0 und 6.5 Punkten liegt das optimale Filterergebnis aus beiden Bereichen. Für uns ganz klar: Bei 6.31 Punkten haben Sie beste Spam-Erkennung bei bestmöglich wenig falsch gefilterten echten E-Mails. SpamAssassin/Amavis kennen drei wichtige Bereiche bei der Auswertung des Spam-Scores:

Unser Tipp: Vergessen Sie das Spam-Tagging. Es sorgt nur dafür, dass eventuelle False Positives erst recht unbemerkt bleiben und verloren gehen. Setzen Sie $sa_tag2_level_deflt auf den identischen Wert wie $sa_kill_level_deflt, also auf »6.31«. In diesen Fällen wird nie getaggt, sondern eine Mail ist Ham (wird zugestellt und vom User gelesen) oder Spam (wird nicht angenommen, Absender erhält Bounce von seinem Mailserver). Achten Sie darauf, dass in Ihrem Amavis folgende Werte eingestellt sind:

$sa_tag_level_deflt  = 2.0;
$sa_tag2_level_deflt = 6.31;
$sa_kill_level_deflt = 6.31;

Listing 10.37    Sind »$sa_tag2_level_deflt« und »$sa_kill_level_deflt« identisch, wird nicht getaggt.

CentOS/openSUSE Leap hat diese Parameter bereits in der amavisd.conf zur Anpassung vorbereitet. Unter Debian/Ubuntu stehen diese in /etc/amavis/conf.d/20-debian_defaults und können für eigene Anpassungen nach /etc/amavis/conf.d/50-user übertragen werden, damit sie bei zukünftigen Updates nicht überschrieben werden. Gleichzeitig sollten Sie regeln, dass Viren und Spam mit einem Score über $sa_kill_level_deflt auch tatsächlich abgelehnt werden. Passen Sie unter CentOS/openSUSE Leap die vorhandenen Einträge in amavisd.conf an, bzw. ergänzen Sie unter Debian/Ubuntu die Datei /etc/amavis/conf.d/50-user wie folgt:

$final_virus_destiny =      D_REJECT;  # Default: D_BOUNCE
$final_banned_destiny =     D_REJECT;  # Default: D_BOUNCE
$final_spam_destiny =       D_REJECT;  # Default: D_REJECT
$final_bad_header_destiny = D_PASS;    # Default: D_PASS

Listing 10.38    Destiny-Einträge

Und das bedeuten die Destiny-Einträge im Einzelnen:

Für jeden der Destiny-Einträge haben Sie die Wahl aus vier »Schicksalen«, die Ihre Mails ereilen können:

[ ! ]  Achtung: »BOUNCE« und »DISCARD« sind gefährlich!

Die Optionen BOUNCE und DISCARD mögen vor 15 Jahren eine gute Option gewesen sein, um unliebsame Mails zurückzusenden oder kurzerhand zu löschen. Heute ist das jedoch brandgefährlich. Spam und Viren tragen fast durchweg gefälschte Absenderangaben; würden Sie (oder andere Mailserver) daraufhin Bounces erzeugen, würde der missbrauchte unschuldige Absender von Millionen von Bounces erschlagen und außer Gefecht gesetzt werden – ein klassischer Distributed Denial of Service-Angriff (DDoS). Wir können diesen wichtigen Punkt gar nicht oft genug wiederholen: Völlig zu Recht landen Mailserver, die Bounces auf Spam- und Virenmails erzeugen, selbst auf einschlägigen RBL-Sperrlisten, weil von diesen Backscatter-Systemen eine erhebliche Gefahr für die Allgemeinheit ausgeht!

Auch ein DISCARD, also das kommentarlose Löschen, ist in unseren Breitengraden zumindest aus juristischen Gründen keine sinnvolle Option. Zum einen würden weder Absender noch Empfänger im Falle einer zu Unrecht gefilterten E-Mail über den Verlust der Nachricht informiert werden; zum anderen ist das »unbefugte Unterdrücken einer anvertrauten Nachricht« ein Fall des §206 StGB.

Sie können Mails also getaggt zustellen oder in die Quarantäne verschieben – oder aber Sie nutzen wie gezeigt REJECT, um die Annahme der E-Mail zu verweigern, was alle rechtlichen und technischen Probleme löst: Es handelt sich dabei weder um den Tatbestand der »Unterdrückung anvertrauter Nachrichten« (sie ist ja mangels erfolgreicher Übertragung nicht »anvertraut«), noch betreiben Sie ein bouncendes Backscatter-System, wenn Sie durch ein REJECT die Nachricht von vornherein nicht annehmen.

Ablehnung durch D_REJECT hin oder her: Amavis würde die Kopie einer Spam- oder Viren-E-Mail trotzdem in seinem Quarantäne-Verzeichnis /var/lib/amavis/virusmails (Debian/Ubuntu) bzw. /var/spool/amavis/virusmails (SUSE) speichern – bei CenTOS muss der Parameter $QUARANTINEDIR vorab in amavisd.conf gesetzt werden.

Das kann anfangs zum Debugging und zur Kontrolle hilfreich sein, doch im laufenden Betrieb möchten Sie weder ein ewig anwachsendes Quarantäne-Verzeichnis, noch möchten Sie die schizophrene Situation haben, dass Sie eine E-Mail einerseits gar nicht erst erhalten wollen, andererseits im Quarantäne-Verzeichnis eine Kopie gespeichert wurde.

Da alle Mails nun sicher abgelehnt werden, sollten Sie dann die Quarantäne-Funktion in Amavis wie folgt ausschalten:

$bad_header_quarantine_to = undef;       # don't quarantine messages
$banned_quarantine_to     = undef;       # don't quarantine messages
$spam_quarantine_to       = undef;       # don't quarantine messages
$virus_quarantine_to      = undef;       # don't quarantine messages

Listing 10.39    Abschalten der Quarantäne-Speicherung in Amavis

10.2.5    Eine Quarantäne mit Amavis betreiben

Natürlich wollen wir Ihnen nicht vorenthalten, wie man Amavis mit einem Quarantäne-Verzeichnis und/oder Spam-Tagging betreiben kann.

Amavis schreibt Mails nur dann im Betreff um, wenn er sich für die Empfänger-Domain zuständig fühlt, sie also an eine lokale Domain adressiert sind. Damit soll verhindert werden, dass Amavis versehentlich eigene ausgehende E-Mails umschreibt und peinlicherweise als Spam markiert an externe Empfänger versendet.[ 12 ] Wenn Sie Spam-Tagging verwenden wollen, müssen Sie Ihre Domains also wie folgt in @local_domains_maps aufnehmen:

@local_domains_maps =  ( [qw(.example.com .example.net, .example.org)] );

Listing 10.40    Manuelle Definition der lokalen Domains in Amavis

Wenn Sie wie oben gezeigt in Postfix die Datei /etc/postfix/relay_domains verwenden, haben Sie dort bereits alle Ihre Domains zusammengetragen. Sie können diese Datei bequem von Amavis einlesen lassen:

@local_domains_maps =  ( [qw(.example.com .example.net, .example.org)], \
                         read_hash('/etc/postfix/relay_domains );

Listing 10.41    Automatisches Einlesen der »relay_domains«

Wollen Sie den Graubereich zwischen 5 und 6.31 Punkten als verdächtig markieren, alles über 6.31 jedoch ablehnen, so setzen Sie:

$sa_tag2_level_deflt = 5.0;
$sa_kill_level_deflt = 6.31;
$final_spam_destiny  = D_REJECT;     # Default:  D_REJECT

Listing 10.42    Einstellungen für Quarantäne-Betrieb bei Mails im Graubereich

Wollen Sie hingegen nie ablehnen und auch den übelsten Spam stets annehmen und alles über ein Tagging im Betreff der Mail regeln, so setzen Sie nun:

$sa_tag2_level_deflt = 5.0;
$sa_kill_level_deflt = 999.0;
$final_spam_destiny  = D_PASS;     # Default:  D_REJECT

Listing 10.43    Einstellungen für ausschließlichen Quarantäne-Betrieb

Um die Quarantäne ab Erreichen des $sa_kill_level_deflt zu aktivieren, müssen Sie die oben gezeigte Zeile $spam_quarantine_to wieder aus Ihrer Konfiguration entfernen, damit der dahinterliegende Default-Wert die Quarantäne aktiviert:

$bad_header_quarantine_to   = undef;       # don't quarantine messages
# $banned_quarantine_to     = undef;       # don't quarantine messages
# $spam_quarantine_to       = undef;       # don't quarantine messages
# $virus_quarantine_to      = undef;       # don't quarantine messages

Listing 10.44    Abschalten der Quarantäne-Speicherung in Amavis

Ist eine E-Mail in der Quarantäne gelandet, so protokolliert Amavis das deutlich im Logfile. In der Regel werden Sie mit grep recipient@example.com /var/log/mail.log|grep quarantine schnell finden, was Sie suchen.

Aug 27 18:58:27 mail amavis[6578]: (06578-02) Blocked SPAM,
[188.120.xxx.xxx] [188.120.xxx.xxx]
<sender@example.net> -> <recipient@example.com>,
quarantine: spam-DhsB-0mN5rUd.gz,
Message-ID: <20100827165821.F08CA1152F5C@kuehnast.com>,
mail_id: DhsB-0mN5rUd,
Hits: 33.233,
size: 1226, 5068 ms

Listing 10.45    Log-Einträge einer in die Quarantäne verschobenen E-Mail (lesbar umgebrochen)

Im Feld nach quarantine: finden Sie die ID, unter der Amavis die E-Mail abgelegt hat (hier: DhsB-0mN5rUd.gz). Ein Blick in das Quarantäne-Verzeichnis bestätigt das auch:

mail:/var/lib/amavis/virusmails # ls -l *DhsB-0mN5rUd*
-rw-r----- 1 amavis amavis 1848 2010-08-27 18:58 spam-DhsB-0mN5rUd.gz

Listing 10.46    Mail im Quarantäne-Verzeichnis finden

Mit dem Befehl amavisd-release können Sie die Mail nun anhand ihrer ID freigeben und automatisch an den ursprünglichen Empfänger zustellen lassen. Amavis wird die Mail an Postfix zur Zustellung übergeben, als ob nichts geschehen wäre.

mail:~ # amavisd-release DhsB-0mN5rUd

Listing 10.47    Mail aus dem Quarantäne-Verzeichnis freigeben

[+]  Noch ein Tipp: Das Quarantäne-Verzeichnis wird nicht automatisch geleert, Mails bleiben ewig darin liegen. Ein Eintrag in der crontab des Users amavis sorgt für Ordnung. Öffnen Sie mit crontab -u amavis -e den Crontab-Editor, und fügen Sie die Zeile aus Listing 10.48 hinzu. Mit diesem Einzeiler werden nachts um 4:00 Uhr alle Mails aus dem Quarantäne-Verzeichnis gelöscht, die älter als sieben Tage sind.

0 4 * * * /usr/bin/find /var/lib/amavis/virusmails/ \
-type f -mtime +7 -exec rm -f {} \;

Listing 10.48    Crontab-Eintrag, um alte Mails aus der Quarantäne zu löschen

10.2.6    Postfix für die Verwendung mit Amavisd-new konfigurieren

Sie sind fast am Ziel: Amavis befindet sich fertig konfiguriert in den Startlöchern, er hat auf localhost Port »10024« seinen SMTP-Dämon gestartet, an den Postfix Mails zur Prüfung ausleiten kann. Ergänzen Sie dazu in Ihrer Postfix-Konfiguration ganz oben in Ihrer master.cf den Aufruf des smtpd-Moduls um den zusätzlichen Parameter smtpd_proxy_filter in einer eingerückten Zeile.

smtp inet    n       -       -       -       -       smtpd
        -o content_filter=
        -o smtpd_proxy_filter=127.0.0.1:10024

Listing 10.49    Definition eines »smtpd_proxy_filter« in Postfix

Aber die Mails müssen auch wieder zurück zu Postfix gelangen können, wenn Amavisdnew seine Arbeit getan hat. Er kann sie nicht einfach wieder auf Port 25 in den Maileingang schieben, als seien es neue Mails – denn dann würde Postfix sie gemäß dem smtpd_proxy_filter-Eintrag postwendend wieder in Amavisd-new stecken, und Sie hätten eine Mail-Endlosschleife.[ 13 ]

In den Standardeinstellungen versucht Amavis, die Mail auf Port 10025 zurück an Postfix zu geben. Passen Sie also Ihre master.cf weiter an, indem Sie den vorhandenen smtpd-Eintrag kopieren und wie folgt abändern:

127.0.0.1:10025 inet    n       -       -       -       -       smtpd
        -o content_filter=
        -o smtpd_proxy_filter=
        -o smtpd_authorized_xforward_hosts=127.0.0.0/8

Listing 10.50    Rückweg von »Amavisd-new« in den Postfix

Manche Distributionen haben einen solchen Port »10025« in der master.cf vorbereitet. Auch viele im Internet kursierende HowTo-Anleitungen zeigen, wie ein Port »10025« definiert wird, und fast alle geben hier völlig überflüssigerweise ein Dutzend wild gemixter Aufrufparameter an, die Sie angeblich auf Port 10025 setzen sollten. Alles Humbug! Zum einen basieren fast alle dieser Anleitungen auf der Idee, dass Mails nicht über smtpd_proxy_filter, sondern über content_filter behandelt werden, was in der Folge einige Weichen anders stellen würde, als es bei dem hier gezeigten Weg der Fall ist.

Zum anderen sind diese Anleitungen oft nachweisbar falsch und sinnfrei widersprüchlich, werden aber mit Begeisterung seit Jahren wieder und wieder (falsch) abgeschrieben und erneut zitiert. Meine Bitte: Machen Sie es so, wie hier gezeigt, tippen Sie nichts aus dem Internet ab, was Ihnen in den Auswirkungen unklar ist. Das hier gezeigte Setup verschafft Ihnen mit wenigen Handgriffen bereits einen hocheffizienten und dank Echtzeitprüfung sogar besonders (rechts-)sicheren Spam-Schutz. Gerade auch zusammen mit den Greylisting- und RBL-Prüfungen, die wir Ihnen bereits in Abschnitt 10.1.3, »Die Postfix-Restrictions: der Schlüssel zu Postfix«, gezeigt haben, sollten Ihre Spam-Probleme nun Vergangenheit sein.

Große Mailrelays oder auf Maildienste spezialisierte Provider könnten das Filter-Setup in Postfix hier noch erheblich ausbauen. Das Postfix-Buch unseres Autors Peer Heinlein[ 14 ] geht hier erheblich weiter in die Tiefe und gibt Anleitungen und Tipps zu Mail-Setups aller Varianten und Größenordnungen.

Aber für normale Setups gilt: Komplexität ist der Feind der Zuverlässigkeit. Je weniger Sie hier machen, umso besser. Es ist ja wirklich nicht viel zu tun, denn – Sie sind bereits fertig!