Von Istvan Sebestyen

1. 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.

2. 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!

3. 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.

4. 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.

5. 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.

5.1. 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.

5.2. 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

5.3. 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.

5.4. 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.

5.5. 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.

6. 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.

7. 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.

reject_unknown_hostname

Verwirft den im HELO/EHLO angegebenen Hostnamen, welcher keinen DNS Rekord vom Typ A oder MX hat. Hier ist es auch sinnvoll permit_mynetworks zuerst anzugeben, wenn man ein Relay-MTA für das innere Netzwerk ist.

reject_non_fqdn_hostname

Verwirft den im HELO/EHLO angegebenen Hostnamen, wenn dieser nicht in FQDN-Form ist. Was bedeutet FQDN? Full Qualified Domain Name. Dafür ein Beispiel: www.chains.ch ist ein FQDN.

warn_if_reject

Schreibt ein WARN ins Logfile und stellt die Nachricht zu, anstatt die Nachricht zu verwerfen.

check_helo_access

Löst den im HELO/EHLO angegebenen Hostnamen oder die Parent-Domain auf.

permit_mynetworks

Gewährt Zugriff, wenn der Client in der Liste von $mynetworks ist.

8. smtpd_sender_restrictions

reject_unknown_sender_domain

Verwirft die Sender-Domain, wenn diese keinen DNS-Record vom Typ A oder MX hat.

reject_non_fqdn_sender

Verwirft die Sender-Domain, wenn diese nicht in FQDN-Form ist.

reject_rhsbl_sender domain.tld

Verwirft die Anfrage, wenn der Sender einen DNS-Record vom Typ A unter domain.tld hat.

reject_sender_login_mismatch

Verwirft, wenn $smtpd_sender_login_maps für eine MAIL FROM- Adresse einen Besitzer spezifiziert, aber der sich nicht mit SASL authentifiziert hat; verwirft, wenn der Sender sich authentifiziert hat, aber die MAIL FROM-Adresse nicht mit dem Sender übereinstimmt.

warn_if_reject

Schreibt ein WARN ins Logfile und stellt die Nachricht zu, anstatt die Nachricht zu verwerfen.

check_sender_access maptype:mapname

Löst die Sender-Adresse, Parent-Domain oder localpart@ auf.

check_sender_mx_access maptype:mapname

Löst den DNS-Record vom Typ MX des Senders auf.

permit_mynetworks

Gewährt Zugriff, wenn der Client in der Liste von $mynetworks ist.

9. smtpd_recipient_restrictions

reject_unknown_recipient_domain

Verwirft die Anfrage, wenn im RCPT TO die Domain des Empfängers keinen DNS-Record vom Typ A oder MX hat.

reject_non_fqdn_recipient

Verwirft die Anfrage, wenn im RCPT TO die Domain des Empfängers nicht in FQDN-Form ist.

reject_rhsbl_recipient domain.tld

Verwirft die Anfrage, wenn der Empfänger einen DNS-Record vom Typ A unter domain.tld hat.

reject_unauth_pipelining

Verwirft die Anfrage, wenn man nicht korrekte Pipelines macht.

reject_unauth_destination

Verwirft das Absenden von Emails:

• zu Zielmaschinen, die nicht unter $inet_interfaces, $mydestination, $virtual_alias_domains der $virtual_mailbox_domains zu finden sind.
• zu Zielmaschinen, die nicht unter $relay_domains oder in deren Subdomains zu finden sind (ausser Sender-spezifisches Routing).

warn_if_reject

Schreibt ein WARN ins Logfile und stellt die Nachricht zu, anstatt die Nachricht zu verwerfen.

check_recipient_access maptype:mapname

Löst die Empfänger-Adresse, Parent-Domain oder localpart@ auf.

check_recipient_mx_access maptype:mapname

Löst den DNS-Record vom Typ MX des Empfängers auf.

permit_auth_destination

Erlaubt das Absenden von Emails:

• zu Zielmaschinen, die unter $inet_interfaces, $mydestination, $virtual_alias_domains der $virtual_mailbox_domains zu finden sind.
• zu Zielmaschinen, die unter $relay_domains oder in deren Subdomains zu finden sind (außer Sender-spezifisches Routing).

permit_mx_backup

Erlaubt das Empfangen von Emails für Seiten, die mich als MX Host auflisten.

permit_mynetworks

Gewährt Zugriff, wenn der Client in der Liste von $mynetworks ist.

10. smtpd_data_restrictions

reject_unauth_pipelining

Verwirft die Anfrage, wenn man nicht korrekte Pipelines macht.

11. Beispiel

Die folgende Konfiguration werden wir zu einem kleinen Test verwenden:

smtpd_helo_required = yes
smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_rbl_client relays.ordb.org,
reject_rbl_client proxies.relays.monkeys.c,
reject_rbl_client proxies.blackholes.easynet.nl,
reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client cbl.abuseat.org,

Wie funktionieren denn genau die Beschränkungen unter Postfix? Mit was arbeitet es und woher weiss es, welche Beschränkung wann dran ist? Schauen wir uns doch mal ein kleines Beispiel mit der oben stehenden Konfiguration an.

Der SMTP-Client sendet, sagen wir mal, solch einen Header: MAIL FROM:<user@gibtsnicht.de>

Und gehen wir davon aus, dass die Domain gibtsnicht.de auch wirklich nicht existiert. Postfix wird die Beschränkungen in der oben stehenden Reihenfolge anschauen.

Das Beispiel:

Der Client verbindet sich, gibt ein EHLO an den Server. Es gibt mehrere Beschränkungen, die der Server sich anschauen muss, dies macht er in der korrekten Reihenfolge:

Der TCP/IP-Client ist nicht in $mynetworks drin, somit geht Postfix zur nächsten Beschränkung.

Der Hostname im EHLO wird geprüft von reject_invalid_hostname, ob dieser eine richtige Syntax hat. Da die richtig ist, gibt es ein DUNNO als Antwort.

Was bedeutet denn dieses DUNNO?

Das ist auf englisch "Don't know". Postfix weiss zu diesem Zeitpunkt noch nicht, was weiter passiert, deshalb übergibt er's der nächsten Beschränkung, mit dem Grund "Ich weiss es nicht, jemand anders soll es entscheiden".

Aber wieso gibt es DUNNO zurück? Der Hostname ist gut, er sollte ein OK bekommen.

Gute Frage. Der Hostname ist wirklich in Ordnung, aber da es weitere Beschränkungen gibt, kann er jetzt noch nicht sagen, ob er die akzeptiert oder ablehnt, daher setzt er ein DUNNO und gibt es weiter an die nächste Beschränkung.

Es trifft auf reject_unauth_pipelining nicht zu, daher wird es weitergegeben.

Da user@gibtsnicht.de in FQDN-Form ist, trifft reject_non_fqdn_sender nicht zu.

Die nächste Beschränkung, reject_unknown_sender_domain sieht sich MAIL FROM an und löst den Domain-Namen der angegebenen Email-Adresse auf. Da es keine solche Domain gibt, antwortet Postfix hier mit REJECT. Die Antwort des SMTP-Servers:

450 <user@gibtsnicht.de>: Sender address rejected: Domain not found

Danach kommen reject_unknown_recipient_domain und noch weitere Beschränkungen, aber diese sind nicht interessant, weil die Verbindung schon zurückgewiesen wurde. Alle weiteren Beschränkungen werden nicht angeschaut.

Noch etwas Wichtiges: Bei den verschiedenen Beschränkungsphasen gibt es im Normalfall immer eine Beschränkung, bei der man als Parameter maptype:mapname angeben muss. Wenn wir verschiedene Regeln auflisten, dann können diese folgende Ergebnisse haben: OK, DUNNO oder REJECT. Wenn nun eine Regel stimmt und das Target DUNNO ist, dann bedeutet das soviel, dass Postfix nicht entscheiden kann, was passiert, deshalb beendet es die Analyse und springt zur nächsten Beschränkung.

Schauen wir ein Beispiel an. Sagen wir, dass bei den Beschränkungen folgende Beschränkung zu finden ist:

check_sender_access pcre:/etc/postfix/sender_check

Der Inhalt dieser Datei:

/domain\.de$/                DUNNO
/^mail\.domain\.de$/         DUNNO
/^spammer\.de$/              REJECT

Wenn eine Email kommt von mail.domain.de, dann matcht diese sowohl mit der ersten als auch mit der zweiten Regel. Die zweite Regel wird aber von Postfix nicht angeschaut, weil bei der ersten schon ein DUNNO zurückgegeben wurde. Somit hat Postfix aufgehört, die Datei zu parsen, und springt zur nächsten Beschränkung. Es ist immer sinnvoll, bei Regular Expressions mit einem "^" und einem "$" den Ausdruck zu begrenzen, damit nicht unvorhergesehene Fehler auftreten. In diesem Fall könnte ja foodomain.de und bardomain.de auch mit /domain\.de$/ übereinstimmen. Das oben angegebene Beispiel dient hiermit nur als Vorstellung für dieses Problem und sollte nicht verwendet werden (jedenfalls nicht ohne "^" und "$").

Sehen wir mal das Ganze im SMTP-Protokoll an. Die Parameter:

SMTP Client:
Address: 111.111.111.111
Hostname: gibtsnicht.de
Prefix: >>

SMTP Server:
Address: 222.222.222.222
Hostname: domain.tld
Prefix: <<

Nun die Verbindung selber:

<< 220 mail.domain.tld ESMTP
>> EHLO localhost                   -----

<< 250-domain.tld                        |
<< 250-PIPELINING                        | -> smtpd_delay_reject=yes
<< 250-SIZE 10240000                     |
<< 250-ETRN                              | Hier werden die definierten
<< 250 8BITMIME                          | Beschränkungen noch nicht
>> MAIL FROM:<user@gibtsnicht.de>        | angeschaut.

<< 250 Ok                                |
>> RCPT TO:<user@domain.tld>        -----  -> Hier wird alles gecheckt.
	 |
 permit_mynetworks             -> DUNNO
	 |
       [...]
	 |
 reject_non_fqdn_sender        -> DUNNO
 reject_unknown_sender_domain  -> REJECT
	 |
    -----
<< 450 <user@gibtsnicht.de>: Sender address rejected: Domain not found

>> DATA
<< 554 Error: no valid recipients
>> QUIT
<< 221 Bye

Wenn ihr dieses Beispiel nicht versteht, schaut mal im RFC 821 nach (RFC=Request for Comments). Dort wird erläutert, wie eine SMTP-Verbindung ausschauen sollte.

Was man noch wissen sollte... Wenn die Email durch alle Beschränkungen durch ist, gibt es noch ein permit am Schluss. Dies ist Standard. Das heisst, dass, wenn es bei den Beschränkungen überall ein DUNNO als Antwort bekommt, Postfix am Schluss Postfix noch ein permit anhängt, somit bekommt die Email ein OK und die Email kann zugestellt werden. Wenn man nicht will, dass die Email nach den Beschränkungen ein OK bekommt, kann man in der Konfigurationsdatei noch ein reject an den Schluss anhängen. Dies ist natürlich ein bißchen gefährlich und man sollte wissen, was man tut.

Bisher haben wir nur die Befehle HELO/EHLO, MAIL FROM und RCPT TO von der SMTP-Verbindung angeschaut. Diesen folgt jetzt DATA.

12. Andere Beschränkungen

Was ist, wenn eine Spam-Mail dennoch alle Checks bis hierhin überstanden hat, wird sie dann einfach ausgeliefert? Nein. Dafür gibt es eben noch weitere Beschränkungen, die sich mit dem Inhalt des DATA Befehls auseinandersetzen, wie z.B. header_checks, mime_header_checks und body_checks. Dies sind die »letzten« Beschränkungsmöglichkeiten, die Postfix vor der Zustellung der Email noch machen kann. Wenn die Email diese Beschränkung auch passiert, dann wird sie zugestellt, wenn man keinerlei Content Filter im Einsatz hat.

Die header_checks, mime_header_checks und body_checks kommen nach dem DATA Befehl der SMTP Verbindung, wenn Postfix den "." am Schluss bekommen hat. header_checks, mime_header_checks und body_checks gehören nicht zu smtpd_*_restrictions, sondern sind selber Beschränkungsphasen. Man verwendet dazu meistens zwei Maptypen: pcre und regexp.

13. Header-, MIME- und Body-Checks

header_checks braucht noch Parameter, die so aussehen: maptype:mapname. Ein Beispiel:

header_checks pcre:/etc/postfix/maps/header_checks.pcre

In der Datei header_checks.pcre könnte eine Zeile so aussehen:

/^<HEADER>:.*inhalt/            VORGEHEN

In der Praxis:

/^From:.*abuser@domain.tld$/          REJECT

Welche Header es gibt, kann man in der Source einer Email nachschauen, dort findet man sicher genügend Header. Es gibt einige Methoden für das VORGEHEN, die sind definiert:

REJECT: Dies ist das gewöhnliche Vorgehen, das am meisten verwendet wird. Die Email wird zurückgewiesen. Man kann nach REJECT noch einen Text angeben, der in den Logs zu sehen ist, was auch der Absender bekommt. Beispiel:

/^Subject:.*gratis/    REJECT Ich zahl' lieber.

Alle Emails, die im Subject »gratis« enthalten, werden gefiltert und zurückgewiesen mit »Ich zahl' lieber«.

IGNORE: Dieses Vorgehen nimmt den Header aus der Email raus, weist diese aber nicht zurück. Beispiel:

/^X-Mailer:/           IGNORE

Wir nehmen alle Header mit "X-Mailer" raus, weil wir evtl. nicht wissen wollen, mit welchem MUA (=Mail User Agent) die Email geschickt wurde.

WARN: Dieses Vorgehen ist sehr nützlich, wenn wir neue header_checks ausprobieren wollen. Es gibt lediglich einen Eintrag in die Logdatei. Die Mails werden weiterhin zugestellt. Beispiel:

/^Subject:.*geld/      WARN

Wir schauen an, ob diese Filterregel nützlich ist, dafür müssen wir die Logdatei öffnen.

HOLD: Hält die Emails in der Queue, bis der Admin sagt, was mit ihnen passiert. Dies könnte nützlich sein, wenn wir die Nachrichten nicht zurückweisen wollen, aber auch nicht, dass der Benutzer diese sofort bekommt. Beispiel:

/^Subject:.*Kündigung/   HOLD

Jede Nachricht, deren Subject "Kündigung" enthält, wird auf HOLD gesetzt und bleibt in der Queue, bis der Admin entscheidet, ob diese zugestellt oder gelöscht wird.

DISCARD: Dieses Vorgehen simuliert die Zustellung einer Nachricht, obwohl diese in Wirklichkeit gelöscht wird. Dies ist sinnvoll, wenn man nicht will, dass der betroffene Absender oder Server weiss, was mit der Nachricht wirklich passiert. Beispiel:

/^Subject:.*Rechnung/    DISCARD

Löscht die Nachrichten, die im Subject "Rechnung" enthalten.

FILTER: Erlaubt, dass man einen anderen Server oder Filter angibt wie im Fall von transport Map. Dies ist nützlich, wenn wir nur Nachrichten mit bestimmtem Header filtern wollen. Beispiel:

/^Subject:.*Virus/     FILTER smtp:10025

Übergibt die Nachrichten, welche im Subject "Virus" enthalten, dem SMTP (Server) auf Port 10025. In den meisten Fällen ist amavis auf diesem Port zu finden.

Der Parameter zu header_checks:

header_checks = pcre:/etc/postfix/maps/header_check.pcre

Schauen wir mal den Inhalt dieser Datei an:

/^Subject:.*100\% Free/         REJECT Woah! Free?
/^From:.*spammer@domain.de/     REJECT Geh weg, Spammer.
/^X-Mailer:.*Microsoft/         REJECT Get a _real_ MUA.

Wichtig: Die oben stehenden Beispiele sind nicht unbedingt nützlich für den Einsatz, sie stehen lediglich als Beispiele da. Verwendet die nur, wenn ihr versteht, was ihr macht. Sonst verwendet doch bitte WARN anstatt REJECT.

Postfix hat in den Versionen 2.x eine neue Beschränkungsphase, nämlich mime_header_checks. Dies macht eigentlich genau das gleiche wie header_checks, nur für die Attachments. Die Parameter für mime_header_checks:

mime_header_checks pcre:/etc/postfix/maps/mime_header_check.pcre

Der Inhalt dieser Datei:

/name=[^>]*\.exe/                     REJECT Keine .exe Files bitte.
/name=[^>]*\.bat/                     REJECT Keine .bat Files bitte.
/name=[^>](screensaver|movie)\.zip/   REJECT Sobig Virus gefunden.

Und body_checks funktioniert auch etwa in dieser Art, nur muss man am Anfang nichts angeben. Die Parameter zu body_checks:

body_checks = pcre:/etc/postfix/maps/body_check.pcre

Der Inhalt dieser Datei:

/See the attached file for details/   REJECT Sobig Virus gefunden.
/Get your free/                       REJECT Free? No, thanks.

Auch die header_checks, mime_header_checks und body_checks gehen in Reihenfolge vor. Ein Beispiel:

Nehmen wir an, wir haben in der Datei header_checks.pcre folgende Zeilen:

/^Subject:.*Hallo/                     REJECT Bye-bye.
/^From:.*chef@domain.de/               OK

Und sehen wir uns mal an, was passiert, wenn unser Chef uns eine Nachricht mit dem Subject "Hallo" schreibt:

<< 220 mail.domain.de ESMTP

>> EHLO host.domain.de
<< 250-mail.domain.de
<< 250-PIPELINING
<< 250-SIZE 10240000
<< 250-ETRN
<< 250 8BITMIME
>> MAIL FROM:<chef@domain.de>
<< 250 Ok

>> RCPT TO:<user@domain.de>
<< 250 Ok
>> DATA
<< 354 End data with <CR><LF>.<CR><LF>
>> To:chef@domain.de

>> Subject:Hallo
>> Tach auch
>> .                                -----
	 | Nur nach dem Schluss"." prüft
	 | Postfix die Header und Body.
	 |
	 | -> header_checks
	 | -> mime_header_checks
	 | -> body_checks
	 |
    -----
<< 550 Error: Bye-bye.
>> QUIT
<< 221 Bye

Also, wie wir sehen, ist die Nachricht nicht angekommen, sondern wurde verworfen. Wir haben vergeblich in unserer Datei header_check.pcre angegeben, dass chef@domain.de Emails verschicken kann, weil davor die Nachricht ein REJECT erhält. Die Error-Meldung ist: Bye-bye. Wie wir auch angegeben haben.

Tipp: OK vor REJECT oder am besten zuerst WARN.

14. Freemail

Es gibt sehr viele Freemail-Provider, die gratis eine Email-Dienstleistung anbieten. Viele Spammer profitieren leider von diesem "Angebot" (einige dieser Provider: hotmail, yahoo, gmx, bigfoot, etc...). Die meisten Spammer benützen eine ungültige Freemail-Adresse, damit sie Ihre Werbung verschicken können. Kann man eigentlich gegen diese Art von Spams etwas unternehmen? Natürlich! Der Trick ist der folgende:

Da die meisten Spammer wahrscheinlich ein Skript für das Verschicken von mehreren tausend Emails brauchen, benützen sie wahrscheinlich nicht die Freemail-Server, um von denen aus die Mails zu verschicken, sondern entweder einen Open-Relay SMTP-Server, oder einen, von dem aus sie die Berechtigung haben, Emails zu verschicken (meistens sind es aber Open-Relay SMTP-Server).

Wenn man z.B. von Hotmail aus eine Email schickt, dann verbindet sich einer der Hotmail-Server mit unserem Postfix SMTP-Server und schickt die Email ab. Wir können daher nachvollziehen (in unseren Logdateien), welche Domain oder welcher Hostname die Verbindung zu unserem SMTP-Server aufgebaut hat. Es ist im Fall von Hotmail ein Server in der hotmail.com Domain (hostname.hotmail.com). Die meisten Spammer würden also einen Absender mit einem Account von hotmail.com vortäuschen, aber in den Logdateien könnten wir nachschauen und feststellen, dass die SMTP-Verbindung nicht von einem hotmail.com-Server stammt. Wir können deshalb diese gefälschten Nacrhichten filtern, indem wir eine eigene restriction class dafür definieren:

smtpd_restriction_classes =
    freemail_hotmail
    freemail_msn
    freemail_yahoo

Dann müssen wir noch angeben, was diese Klassen machen müssen:

freemail_hotmail =
    check_client_access pcre:/etc/postfix/maps/freemail_hotmail

freemail_msn =
    check_client_access pcre:/etc/postfix/maps/freemail_msn

freemail_yahoo =
    check_client_access pcre:/etc/postfix/maps/freemail_yahoo

Wir müssen noch eine Datei erstellen, in dem wir die Domain-Namen von diesen Freemail-Sites angeben. Die Datei können wir mit dem Namen /etc/postfix/maps/freemail_check anlegen. Der Inhalt dieser Datei:

hotmail.com        freemail_hotmail
msn.com            freemail_msn
yahoo.com          freemail_yahoo

Und noch in der Beschränkungsphase smtpd_recipient_restrictions dies auch angeben:

smtpd_recipient_restrictions =
    [..]
    check_sender_access hash:/etc/postfix/maps/freemail_check,
    [..]

Nun haben wir alles angepasst, werfen wir doch einen Blick auf den Inhalt der freemail_(provider) Dateien, wie es aussehen sollte:

/(^|\.)provider\.tld$/  DUNNO
/./                     REJECT You claim to be from provider.tld \
            but your mail didn't come from a provider.tld server.

Wenn also der Absender eine Email-Adresse von provider.tld benutzt, schaut Postfix nach, ob der Client auch von einem provider.tld-Server kommt. Wenn ja, hört er auf, die Datei zu parsen (wegen dem DUNNO) und schaut sich die nächsten Beschränkungen an. Wenn der Client nicht von provider.tld stammt und der erste Regular Expression nicht übereinstimmt, dann geht Postfix zum nächsten. Weil die zweite Linie auf alles matcht, verwirft Postfix die Nachricht mit dem oben liegenden Text.

Schauen wir doch am besten ein Beispiel an. Nehmen wir an, dass sich jemand bei uns mit einer yahoo.com Email-Adresse ausgibt. Die Datei freemail_yahoo sieht also so aus:

/(^|\.)yahoo\.com$/   DUNNO
/./                   REJECT You claim to be from yahoo.com \
            but your mail didn't come from a yahoo.com server.

Die Parameter für die SMTP-Verbindung:

SMTP-Client:

• Adresse: 111.111.111.111
• Hostname: host.domain.de
• Prefix: >>

SMTP-Server:

• Adresse: 222.222.222.222
• Hostname: mail.domain.de
• Prefix: <<

Die Verbindung würde so ausschauen:

<< 220 mail.domain.de ESMTP
>> EHLO host.domain.de
<< 250-domain.de
<< 250-PIPELINING

<< 250-SIZE 10240000
<< 250-ETRN
<< 250 8BITMIME
>> MAIL FROM:<123456@yahoo.com>
<< 250 Ok
>> RCPT TO:<user@domain.de>
<< 554 <host.domain.de[111.111.111.111]>: Client host rejected: ...

>> DATA
<< 554 Error: no valid recipients
>> QUIT
<< 221 Bye

Bevor man andere Freemail-Server definiert, sollte man sich vergewissern, ob die wirklich auch über deren eigene Domain die Emails verschicken. Meistens ist das der Fall, aber man soll ja schliesslich nichts dem Zufall überlassen.

15. Links

http://www.securitysage.com/guides/postfix_uce.html
http://www.mengwong.com/misc/postfix-uce-guide.txt
http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
http://www.arschkrebs.de/postfix/
http://www.postfix.org/uce.html
http://www.postfix.org/docs.html

16. Copyright/Lizenz

Copyright (c) 2003 Istvan Sebestyen. All rights reserved.

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Author.

17. Thanks

Special thanks to Gergely Nagy on the #linux channel of the hungarian SIRC network.

Thanks to Fabio Robbiani who helped me with some grammatical issues ;-)