Postfix UCE-HOWTO
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.
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.
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:
