ITzoo.de - Admin-FAQ

Written by: Istvan Sebestyen <istvan at swissdent dot hu>
Last Modified: Fri Jul 22 13:53:04 CEST 2005

Übersicht

1. Einleitung

1.2 Wichtig

1.3 Was ist Postfix?

1.4 Was ist UCE?

2. Konfiguration

2.1 smtpd_client_restrictions

2.2 smtpd_helo_restrictions

2.3 smtpd_sender_restrictions

2.4 smtpd_recipient_restrictions

2.5 smtpd_data_restrictions

2.6 Beispiel

3. Andere Beschränkungen

4. Header-, MIME- und Body-Checks

4.1 Definition

4.2 Header-Checks

4.3 MIME-Checks

4.4 Body-Checks

4.5 Beispiel

5. Freemail

6. Links

7. Copyright / License

8. Thanks

---

 

1. Einleitung

1.1 Voraussetzung

Dieses HOWTO basiert auf Postfix snapshot 20031026. Die 1.x Versionen von Postfix sind so gesagt "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ässig keine anti-UCE Einstellungen, diese sollten vom Admin nach der Konfiguration zu den passenden Verhältnissen gemacht werden. Dieses HOWTO befasst sich nicht mit der Installation, somit geh ich davon aus, dass jeder eine funktionierende Postfix MTA auf dem Computer/Server hat.

1.2 Wichtig

Im folgenden Text werd' 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!

1.3 Was ist Postfix?

Postfix ist ein MTA (Mail Transfer Agent), das 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 aussen so aus wie sendmail, ist aber im Innern ganz etwas anderes.

1.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 etwas unternehmen? Ja! Das bedeutet nicht, dass Postfix alle Spam Emails filtern kann, aber den grössten Teil kann man schon bei der SMTP Verbindung filtern, demnach folgen dann weitere Filter (z.B. Spamassassin). Diese nennt man content-filter und 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.

2. 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 angepasst, seine eigenen anti-UCE Regeln zu definieren.

In Postfix gibt es drei verschiedene Stufen:

• 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 würde diese kurz erklären:

smtpd_client_restricions

Die MTA's "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 von der Adresse oder dem Hostname des SMTP Clients. Der Client bedeutet hier den zum Server verbundenen TCP/IP Client.

smtpd_helo_restrictions

In der Regel schicken die SMTP Clients zum Server ein HELO/EHLO zur Begrüssung, in welchem sie ihren eigenen Hostnamen bekanntgeben. In dieser Beschränkungsphase können wir bestimmen, welche hostname 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 "RCPT TO:" Befehl 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 vom DATA Befehl gefiltert, sondern der Befehl selber. Dies filtert den SMTP Client, welcher die SMTP Regeln nicht 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ässig erst nach dem "RCPT TO:" Befehl 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. ein 3MB grosses File 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 schliesslich doch die Daten sendet. Darum ist in Postfix smtpd_delay_reject auf "yes" gesetzt.

Es ist wichtig, dass wir die Beschränkungen in richtiger Reihenfolge angeben, weil diese dann von Postfix so verarbeitet werden. So entscheidet er, ob er die Nachricht weitergeben soll oder stoppt.

Nachdem wir jetzt die Beschränkungsphasen angeschaut haben, werfen wir einen Blick auf die Beschränkungen:

2.1 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) oder wenn Reverse und Forward Lookups nicht übereinstimmen.

reject_rbl_client domain.tld

Verwirft die Anfrage, wenn der SMTP Client einen DNS Rekord vom Typ A unter domain.tld hat. Ein RBL ist eine Real-time Blacklist (IP basiert).

reject_rhsbl_client domain.tld

Verwirft die Anfrage, wenn der SMTP Client einen DNS Rekord vom Typ A unter domain.tld hat. Ein RHSBL ist eine Real-time Blacklist (Domain basiert).

warn_if_reject

Wandelt jedes REJECT einer direkt nachfolgenden Restriction in eine Warnung um.

check_client_access maptype:mapname

Sieht bei Client-Namen, Client-Adressen und Parent Domains anhand von dem in maptype:mapname angegebenen Map nach.

permit_mynetworks

Gewährt Zugriff, wenn der Client in $mynetworks zu finden ist.

2.2 smtpd_helo_restrictions

reject_invalid_hostname

Verwirft im HELO/EHLO angegebenen Hostname, 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/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. Für das ein Bespiel: www.chains.ch ist ein FQDN.

warn_if_reject

Wandelt jedes REJECT einer direkt nachfolgenden Restriction in eine Warnung um.

check_helo_access

Sieht im HELO/EHLO angegebenen Hostnamen oder Parent Domain nach.

permit_mynetworks

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

2.3 smtpd_sender_restrictions

reject_unknown_sender_domain

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

reject_non_fqdn_sender

Verwirft den Absender, wenn diese nicht in FQDN Form ist (sender@domain.de).

reject_rhsbl_sender domain.tld

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

reject_sender_login_mismatch

Verwirft, wenn $smtpd_sender_login_maps eine MAIL FROM Adresse den 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

Wandelt jedes REJECT einer direkt nachfolgenden Restriction in eine Warnung um.

check_sender_access maptype:mapname

Sieht die Sender Adresse, Parent Domain oder localpart@ nach.

check_sender_mx_access maptype:mapname

Verwirft die Anfrage, wenn Pipelining benutzt wird, bevor Postfix seine Fähigkeit dies zu beherrschen angekündigt hat.

permit_mynetworks

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

2.5 smtpd_recipient_restrictions

reject_unknown_recipient_domain

Verwirft die Anfrage, wenn im RCPT TO die Domain des Empfängers keinen DNS Rekord 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 Rekord vom Typ A unter domain.tld hat.

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

Wandelt jedes REJECT einer direkt nachfolgenden Restriction in eine Warnung um.

check_recipient_access maptype:mapname

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

check_recipient_mx_access maptype:mapname

Der MX Record der Empfängerdomain wird bestimmt und das Ergebnis wird zur Suche in maptype:mapname verwendet.

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

2.5 smtpd_data_restrictions

reject_unauth_pipelining

Verwirft die Anfrage, wenn man nicht korrekte Pipelines macht.

2.6 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 cbl.abuseat.org,

Wie funktionieren denn genau die Beschränkungen unter Postfix? Mit was arbeitet er und woher weiss er 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 Envelope: 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:

Beschränkung	Antwort
permit_mynetworks	DUNNO
reject_unauth_destination	DUNNO
reject_invalid_hostname	DUNNO
reject_non_fqdn_sender	DUNNO
reject_unknown_sender_domain	REJECT
reject_non_fqdn_recipient
[..]

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, gibts 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 uebergibt 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

Nach dem 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 gibts im Normalfall immer eine Beschränkung, bei der man als Parameter maptype:mapname angeben muss. Wenn wir verschieden Regeln auflisten, dann können diese folgende Ergebnisse haben: OK, DUNNO, REJECT oder sowas wie "554 Geh weg." (3 stelliger Code und Antwort). Wenn nun eine Regel stimmt und das Target DUNNO ist, dann bedeutet das soviel, dass Postfix nicht entscheiden kann was passiert, deshalb beendet er 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 dieses Files:

/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 und somit hat Postfix aufgehört das File zu parsen und springt zur nächsten Beschränkung. Es ist immer sinnvoll bei Regular Expressions mit einem "^" und einem "$" den Ausdruck zu begrenzen, nicht dass ungewollte 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, gibts noch ein permit am Schluss. Dies ist Standard. Das heisst, dass es bei den Beschränkungen überall ein DUNNO als Antwort bekommt, am Schluss hängt Postfix noch ein permit, 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 bisschen gefährlich und man sollte wissen, was man tut.

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

3. Andere Beschränkungen

Was ist wenn ein Spam-Mail dennoch alle Checks bis hierhin überstanden hat, wird es 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 Maptype's: pcre und regexp.

4. Header-, MIME- und Body-Checks

Um diese Checks durchführen zu können, braucht man entweder die maptype regexp oder pcre. Die folgenden Beispiele basieren auf pcre, deshalb ist es zu empfehlen Postfix mit pcre Unterstützung zu kompilieren, oder dann ein Binary Paket zu installieren, das pcre unterstützt. Wenn man Regular Expressions nicht versteht, sollte man sich diese aneignen. Es gibt viele gute HOWTO's auf dem Web, wo mann dies erlernen kann.

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

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

Im header_checks.pcre file könnte eine Zeile so aussehen:

/^<HEADER>:.*inhalt/                    VORGEHEN

In der Praxis:

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

4.1 Definition

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, das in den Logs zu sehen ist, was auch der
Absender bekommt.
Bsp:     /^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.
Bsp:     /^X-Mailer:/                   IGNORE
Wir nehmen alle Header mit "X-Mailer" raus, weil wir evt. 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 nur einen Eintrag ins
Logfile, die Mails werden weiterhin zugestellt.
Bsp:     /^Subject:.*geld/              WARN
Wir schauen an, ob diese Filterregel nützlich ist, dafür
müssen wir die Logfiles öffnen.
HOLD:    Hält die Emails in der Queue, bis der Admin sagt, was mit
denen passiert. Dies könnte nützlich sein, wenn wir die
Nachrichten nicht zurückweisen wollen, aber auch nicht, dass
der Benutzer diese sofort bekommt.
Bsp:     /^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.
Bsp:     /^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 bestimmten Header filtern wollen.
Bsp:     /^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.

4.2 Header-Checks

Der Parameter zu header_checks:
header_checks = pcre:/etc/postfix/maps/header_check.pcre

Schauen wir mal den Inhalt dieses Files 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, die stehen lediglich als Beispiele. Verwendet die nur, wenn Ihr versteht, was Ihr macht. Sonst verwendet doch bitte WARN anstatt REJECT.

4.3 MIME-Checks

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 dieses Files:

/name=\"?(.*)\.(exe|bat)\"?$/		REJECT Unwanted attachment/Unerwuenschter Anhang $1.$2
/name=[^>](screensaver|movie)\.zip/   REJECT Sobig Virus gefunden.

4.4 Body-Checks

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 dieses Files:

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

4.5 Beispiel

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

Nehmen wir an wir haben im header_checks.pcre File 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:user@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 unserem header_check.pcre File, 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.

5. 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 Script 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 Logfiles) 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 Logfiles 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 ein File machen, in dem wir die Domain Namen von diesen Freemail Sites angeben. Das File können wir unter /etc/postfix/maps/freemail_check anlegen. Der Inhalt dieses Files:

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) Files, 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 das File 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. Das File 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: You claim to be from yahoo.com but your mail didn't come from a yahoo.com server.
>> 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. Aber spätestens dann, wenn diese Freemail Server POP3/IMAP Dienstleistung (gratis) anbieten, sollte man diese Option lieber weglassen (es sei denn, dass auch ein SMTP Dienst angeboten wird, weil dann die Emails doch vom Freemail Server kommen).

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

7. Copyright / License

Copyright (c) 2003 Istvan Sebestyen <istvan at swissdent dot hu> 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.

8. Thanks

Special thanks to Gergely Nagy <algernon at bonehunter dot rulez dot org> on the #linux channel of the hungarian SIRC network.
Thanks to Fabio Robbiani <fabio at tuners dot ch> who helped me with some grammatical issues ;-)
Thanks to Ralf Hildebrandt for some technical help.

Quelle: http://www.chains.ch/docs/postfix-UCE-HOWTO-de.html