Postfix UCE-HOWTO
Postfix hat nach der Installation standardmäßig keine Anti-UCE-Einstellungen. Diese sollten vom Admin nach der Konfiguration nach den jeweiligen Verhältnissen gemacht werden.
Voraussetzung
Dieses HOWTO basiert auf Postfix snapshot 20031026. Die 1.x Versionen von Postfix sind sozusagen veraltet. Ich empfehle jedem, auf Postfix der Version 2.x zu upgraden, da diese viele neue Anti-UCE-Funktionen enthält, mit denen man die nicht gewollten Emails besser bzw. präziser filtern kann.
Postfix hat nach der Installation standardmäßig keine Anti-UCE-Einstellungen. Diese sollten vom Admin nach der Konfiguration nach den jeweiligen Verhältnissen gemacht werden. Dieses HOWTO befasst sich nicht mit der Installation, somit gehe ich davon aus, daß jeder einen funktionierenden Postfix-MTA auf dem Computer hat.
Wichtig
Im folgenden Text werde ich zum Teil auch meine eigene Konfiguration zeigen, was NICHT heisst, dass diese Einstellungen auch für euch geeignet sind, deshalb: ICH ÜBERNEHME KEINE VERANTWORTUNG!
Was ist Postfix?
Postfix ist ein MTA (Mail Transfer Agent), der den bekannten sendmail Email-Server "ersetzt". Postfix ist schnell, leicht zu konfigurieren und sicher, während es kompatibel mit sendmail ist. Daher sieht er zwar von außen so aus wie sendmail, ist aber im Innern ganz etwas anderes.
Was ist UCE?
Die Bedeutung von UCE ist: Unsolicited Commercial Email. Heutzutage ist es eher als »Spam« bekannt und gehört (leider) schon zu unserem Alltag. Aber können wir dagegen nichts unternehmen? Doch! Das bedeutet nicht, dass Postfix alle Spam-Emails filtern kann, aber den größten Teil kann man schon bei der SMTP-Verbindung filtern, danach folgen dann weitere Filter (z.B. Spamassassin). Diese nennt man content-filter. Sie werden erst nach der SMTP-Verbindung wirksam. Weil diese ziemlich viele Ressourcen brauchen, ist es sinnvoll, wenn man schon während der SMTP-Verbindung mit verschiedenen Methoden filtern kann. Diese Verfahren nennt man in Postfix "restrictions", auf deutsch: Beschränkungen.
Konfiguration
Wie ich schon erwähnt habe, hat die Standard-Postfix-Konfiguration keine Anti-UCE-Beschränkungen eingebaut, aber ich glaube, dass es auch keinen Sinn machen würde, denn man weiss ja nicht, als was Postfix nach der Installation eingesetzt wird (mail-hub, relay, etc...). Daher ist es die Aufgabe des Admins, dem entsprechenden Umfeld angepaßt seine eigenen Anti-UCE-Regeln zu definieren.
In Postfix gibt es drei verschiedene Beschränkungen:
- Beschränkungsphasen
- Beschränkungen
- Liste von Zugriffsrechten
Postfix verarbeitet die Beschränkungsphasen in folgender Reihenfolge:
smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions
Ich werde diese kurz erklären.
smtpd_client_restricions
Die MTAs »sprechen« miteinander im SMTP-Protokoll. Deshalb muss sowohl der Client als auch der Server SMTP verstehen. Diese Beschränkungsphase steht für die Beschränkung der Adresse oder des Hostnamen des SMTP-Clients. Der Client bedeutet hier der zum Server verbundene TCP/IP-Client.
smtpd_helo_restrictions
In der Regel schicken die SMTP-Clients zum Server ein HELO/EHLO zur Begrüßung, in welchem sie ihren eigenen Hostnamen bekanntgeben. In dieser Beschränkungsphase können wir bestimmen, welche Hostnamen der Client schicken kann. Es wäre sicher nicht sinnvoll, wenn ein externer Client unseren eigenen Hostnamen schicken würde (Spammer-Methode). Es ist sinnvoll, zu konfigurieren, dass ein SMTP-Client ein HELO/EHLO schicken muss. Mit diesem Verfahren kann man viele Spam-Software filtern. Dies kann man so machen:
smtpd_helo_required=yes
smtpd_sender_restrictions
In dieser Beschränkungsphase können wir einstellen, welchen Sender unser Postfix MTA im "MAIL FROM:"-Befehl empfangen soll, da viele Spammer ins "MAIL FROM:" nicht existierende oder ungültige Email-Adressen schreiben (z.B. peter@foobar.de oder peter@foo@bar.de). In diesem Fall gehen wir davon aus, dass die Domain foobar.de nicht existiert.
smtpd_recipient_restrictions
Diese Beschränkungsphase setzt fest, was als Wert für den Befehl "RCPT TO:" zugelassen ist. Die Spammer können auch hier ungültige Adressen angeben, welche wir mit verschiedenen Optionen filtern können.
smtpd_data_restrictions
Bevor ihr es falsch versteht... nein, hier wird nicht der Inhalt des DATA-Befehls gefiltert, sondern der Befehl selber. Dies filtert den SMTP-Client, der nicht die Regeln des SMTP-Protokolls einhält.
Ihr habt sicher gemerkt, dass in vielen Postfix-Konfigurationen alle Beschränkungen unter smtpd_recipient_restrictions sind. Nun, dies hat auch einen Grund. Postfix führt standardmäßig erst nach dem Befehl "RCPT TO:" die UCE-Filter durch, da die Variable smtpd_delay_reject auf »yes« gesetzt ist (wenn man diese nicht zuvor geändert hat). Ich empfehle nicht, diese zu ändern, da einige SMTP-Clients dies nicht unbedingt mögen werden (ich will jetzt nicht unbedingt auf die SMTP-Clients von Microsoft zielen ;-)
Dies ist auch der Grund, warum smtpd_delay_reject=yes Standard ist. Es gibt nämlich (wirklich) einige MS SMTP-Clients, welche nach dem HELO/EHLO umsonst ein REJECT bekommen würden, weil diese es nicht verstehen und dennoch die ganzen Daten senden würden. Wenn jemand z.B. eine 3 MB große Datei herumschickt mit solch einem MS-Client, dann würde der Client vergeblich vom Server nach dem HELO/EHLO schon ein REJECT bekommen, weil der dann schließlich doch die Daten sendet. Darum ist in Postfix smtpd_delay_reject auf "yes" gesetzt.
Es ist wichtig, dass wir die Beschränkungen in der richtigen Reihenfolge angeben, weil diese dann von Postfix so verarbeitet werden. So entscheidet es, ob es den Prozess weitergeben oder stoppen soll.
Nachdem wir jetzt die Beschränkungsphasen angeschaut haben, werfen wir einen Blick auf die Beschränkungen.
smtpd_client_restrictions
reject_unknown_client
Verwirft die Anfrage, wenn der Hostname des SMTP-Clients unbekannt ist (die IP-Adresse oder der Hostname des TCP/IP-Clients).
reject_rbl_client domain.tld
Verwirft die Anfrage, wenn der SMTP-Client einen DNS-Record vom Typ A unter domain.tld hat.
reject_rhsbl_client domain.tld
Verwirft die Anfrage, wenn der SMTP-Client einen DNS-Record vom Typ A unter domain.tld hat.
warn_if_reject
Schreibt ein WARN ins Logfile und stellt die Nachricht zu, anstatt die Nachricht zu verwerfen.
check_client_access maptype:mapname
Löst die Client-Namen, Client-Adressen und Parent-Domains auf anhand der in maptype:mapname angegebenen Map.
permit_mynetworks
Gewährt Zugriff, wenn der Client in $mynetworks zu finden ist.
smtpd_helo_restrictions
reject_invalid_hostname
Verwirft den im HELO/EHLO angegebenen Hostnamen, falls dieser eine falsche Syntax hat. Wenn man in einem Netzwerk ist und man will, dass die Maschinen, die auch im Netzwerk sind, Emails über unseren MTA verschicken wollen, dann ist es sinnvoll, diese Beschränkung erst nach permit_mynetworks anzugeben (wie ich schon gesagt habe, die Reihenfolge ist sehr wichtig), sonst wird er vom MTA verworfen oder zurückgewiesen.
