Anti-Spam II

Die eben beschriebenen Maßnahmen reduzieren zwar den Ansturm von unerwünschter Mail, aber korrekt konfigurierte Systeme können dem eigenen Server noch immer Spam schicken. Daher empfiehlt sich die Installation einer zweiten Verteidigungsebene: »amavisd-new« als »content_filter« . Der »content_filter« nimmt eine Mail zur weiteren Zustellung an, verarbeitet den Inhalt der Mail und gibt die Mail entweder wieder an Postfix zurück oder verwirft sie, zum Beispiel wenn es Spam oder ein Virus ist.

Die Verarbeitung einer Mail durch »amavisd« -new ist relativ aufwendig: Die Mail wird gespeichert, die Anhänge werden separat gespeichert, entpackt, dann wird auf Viren gescannt, dann geht die Mail an Spamasssassin, der auf Anzeichen von Spam prüft. Schlussendlich erhält Postfix "saubere" Mail zurück, im Spam- oder Viren-Mails werden verworfen – wobei darauf zu achten ist, die Mail nicht erneut demselben Prozedere zu unterziehen.

Nach der Installation von »amavisd-new« müssen Sie in »/etc/amavisd.conf« lediglich einige Kleinigkeiten konfigurieren:

$mydomain = 'charite.de';

Diese Einstellung legt fest, welche Empfänger Statusmeldungen in die Header geschrieben bekommen und wer für lokale Auslieferung in Betracht kommt, wenn Offsite Notification ausgeschaltet ist.

$inet_socket_port = 10025;

»amavisd-new« lauscht auf Port 10025 (localhost). Standardmäßig wird die Mail auf localhost:10026 wieder an Postfix zurückgegeben (siehe Abbildung 2).

Abbildung 2: Der Weg einer E-Mail bei einer komplexen Spam-Überprüfung.

In der Datei »master.cf« konfigurieren Sie den Server so, dass er die Mail an den »content_filter« auf »[127.0.0.1]:10025« abgibt (Listing 2).

smtp      inet  n       -       -       -        -      smtpd
   -o receive_override_options=no_address_mappings
   -o content_filter=amavisd:[127.0.0.1]:10025
   -o smtpd_authorized_xforward_hosts=127.0.0.1
   -o smtpd_authorized_xclient_hosts=127.0.0.1

In diesem Beispiel schreibt der Server die Adressen nicht um (»no_address_mappings« ), sodass »amavisd-new« die ursprünglichen Empfängeradressen zu sehen bekommt, bevor »virtual_alias_maps« und Konsorten zum Einsatz kommen. Als Transportweg von Postfix zu »amavisd-new« (»amavisd:[127.0.0.1]:10025« ) kommt der eigens in »master.cf« definierte Transport »amavisd« zum Einsatz (Listing 3). Es handelt sich dabei um einen LMTP-Transport mit speziellen, in der Amavis-Dokumentation angegebenen Einstellungen [7].

amavisd   unix  -       -       -       -       10      lmtp
     -o lmtp_data_done_timeout=1200
     -o lmtp_send_xforward_command=yes

Wenn Postfix die Mail an Amavis abgegeben hat, muss sie irgendwann einen Weg zurück in Postfix finden, der nicht wieder derselben Filterung unterworfen ist (Listing 4). Man sieht, dass der »smtpd« auf »localhost:10026« nur Mail von 127.0.0.0/8 annimmt. Tests auf unbekannte Empfänger fallen weg; die hat »smtpd« bereits vor dem »content_filter« durchgeführt. Der »content_filter« ist dafür explizit deaktiviert.

localhost:10026 inet  n       -       -       -        -      smtpd
   -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=

SMTP-Auth/TLS

In den obigen Beispielen ist das Relaying immer explizit durch das Setzen von »mynetworks« auf einen vorher bekannten, festen IP-Bereich erlaubt worden. Mobile User, deren IP-Adressen nicht im Vorfeld bekannt sind, benötigen eine adressunabhängige Authentifizierungsmethode.

Postfix implementiert dazu SMTP-Auth, eine Erweiterung, die die Autorisierung eines Benutzers im SMTP-Dialog erlaubt. Nach erfolgreicher Autorisierung mit Benutzername und Kennwort erlaubt Postfix für die aktuelle SMTP-Sitzung Relaying, sonst nicht. Die Auth-Fähigkeiten der Clients bestimmen, welche Mechanismen der Server anbieten muss. Einen Überblick über die Auth-Fähigkeiten verschiedener Mailprogramme gibt der Cyrus-SASL-Entwickler Alexeji Melnikov unter [8].

Der nächsten Schritt reduziert die Auswahl auf die sichersten Auth-Methoden. Sind Plaintext-Mechanismen weiterhin mit von der Partie (und dies wird in der Praxis höchstwahrscheinlich der Fall sein) sollten Sie den Austausch von Benutzername und Passwort mit TLS absichern. Dazu aber gleich mehr.

Im Hintergrund gibt Postfix die Autorisierungsaufgabe an SASL (Simple Authentication and Security Layer) weiter (Abbildung 3). SASL kann auf folgende Authentication Backends zugreifen: Posix-Accounts, PAM, IMAP, LDAP, LDAPDB, SASLDB und SQL. Das hier vorgeführte Beispiel beschränkt sich auf Posix-Accounts.

Abbildung 3: Authentifizierung eines Mail-Clients über SMTP-AUTH und SASL.

Im Paket »sasl2-bin« befindet sich der Daemon »saslauthd« . Sie müssen ihn mit »saslauthd -a shadow« starten, damit er auf »/etc/shadow« als Authentication Backend zugreift: Nun können Sie mit »testsaslauthd« prüfen, ob »saslauthd« einen User authentifizieren kann:

testsaslauthd -u test -p testpass

Damit Postfix weiß, dass er mit »saslauthd« zu tun hat und dieser nur Plaintext-Mechanismen beherrscht, erstellen Sie folgende Konfiguration in »/usr/lib/sasl2/smtpd.conf« (bei Debian »/etc/postfix/sasl/smtpd.conf« ):

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
log_level: 3

In der Datei »main.cf« ergänzen Sie am besten noch:

broken_sasl_auth_clients = yes

Diese Zeile sorgt dafür, dass Postfix die Autorisierung auch Clients anbietet, die einen alten Draft des RFC implementieren. Die folgende Zeile aktiviert SMTP-AUTH im SMTPD-Prozess:

smtpd_sasl_auth_enable = yes

Die lokale Domain von SASL setzen Sie mit:

smtpd_sasl_local_domain =

Dann legen Sie fest, welche Mechanismen Postfix nicht anbieten darf. Der Parameter »noanonymous« verhindert, dass jemand den Anonymous-Mechanismus nutzt, der beliebige Usernamen- und Passwortkombinationen erlaubt:

smtpd_sasl_security_options = noanonymous

Schlussendlich müssen Sie noch die Restriktionen so ergänzen, dass Postfix authentifizierten Clients das Relaying erlaubt. Dazu fügen Sie nach »permit_mynetworks,« die Anweisung »permit_sasl_authenticated,« ein. Mit den folgenden Kommandozeilen erzeugen Sie Plaintext-Teststrings für die Authentisierung im SMTP-Dialog (User »test« , Passwort »testpass« ):

perl -MMIME::Base64 -e 'print encode_↩
base64("test\0test\0testpass");'
dGVzdAB0ZXN0AHRlc3RwYXNz

Nach einem »postfix reload« können Sie sich mit dem Server auf Port 25 verbinden und Ihre Zugangsdaten testen (Listing 5).

220 mail.example.com ESMTP Postfix
EHLO example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-XVERP
250 8BITMIME
AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
235 Authentication successful
QUIT
221 Bye