Anti-Spam

Schon von Haus aus bietet Postfix zahlreiche Methoden gegen unerwünschte Mail, von einfachen, fest eingebauten Restriktionen (»smtpd_*_restrictions« ) und Inhaltsüberprüfungen (»header_checks« , »body_checks« , »mime_header_checks« und so weiter) bis hin zur Delegierung der Mail an externe Programme (»content_filter« und so fort), siehe Abbildung 1.

Abbildung 1: Die verschiedenen Bereiche einer Mail, auf die sich die Postfix-Überprüfungen beziehen.

Die Standardeinstellungen für die Restriktionen von Postfix zeigt auf Wunsch das Postconf-Kommando:

$ postconf -d smtpd_recipient_restrictions
smtpd_recipient_restrictions = permit_↩
mynetworks, reject_unauth_destination

Die Restriktionen in »smtpd_recipient_restrictions« (und auch den anderen »smtpd_*_restrictions« ) arbeitet Postfix der Reihe nach ab. Sie liefern üblicherweise »OK« (Mail wird angenommen), »REJECT« (Mail wird abgewiesen) oder »DUNNO« (mit nächster Restriktion weitermachen) zurück. Die Standardeinstellung verhindert bereits unerwünschtes Relaying, also dass Fremde den eigenen Server zum Versenden von Mail benutzen. Diese »smtpd_recipient_restrictions« lassen sich schrittweise ergänzen, um den Schutz gegen Spam zu verbessern.

Interne Restriktionen

Listing 1 gibt ein Beispiel für die Verwendung der von Postfix verstandenen Restriktionen.

smtpd_recipient_restrictions =
   reject_non_fqdn_sender,
   permit_mynetworks,
   reject_unauth_destination,
   reject_unknown_sender_domain,
   reject_unlisted_recipient,
   check_helo_access        pcre:/etc/postfix/helo_checks.pcre,
   check_recipient_access   hash:/etc/postfix/roleaccount_exceptions,
   reject_invalid_helo_hostname
   reject_non_fqdn_helo_hostname
   check_policy_service     inet:127.0.0.1:12525
   reject_rhsbl_sender      dsn.rfc-ignorant.org
   reject_unverified_sender

Die Bedeutung der einzelnen Parameter fasst Tabelle 1 zusammen.

Der Inhalt von »/etc/postfix/helo_checks« sieht wie folgt aus:

localhost  550 Meine Domain? (localhost)
charite.de     550 Meine Domain?
160.45.207.131  550 Meine IP?
mail.charite.de  550 Mein Hostname?

Dies weist »HELO/EHLO« -Argumente ab, die »localhost« , »charite.de« , »160.45.207.131« , »mail.charite.de« , oder generell eine IP in eckigen Klammern. Sie müssen natürlich hier ihre eigenen Host-, Domainnamen und IP-Adressen verwenden.

Die Datei »roleaccount_exceptions« definiert Ausnahmen für Role Accounts, die es erlauben, diese E-Mailadresse auch zu erreichen, wenn eine der noch folgenden Restriktionen die Mail eigentlich blocken würde. Die Verwendung der Datei durch Postfix setzt wiederum das Hash-Map-Format voraus, das Sie mit »postmap hash:/etc/postfix/roleaccount_exceptions « erzeugen. Die Datei sieht zum Beispiel so aus:

postmaster@charite.de OK
abuse@charite.de      OK

So können die Adressen »postmaster@charite.de« und »abuse@charite.de« immer erreicht werden, vorausgesetzt keine der vorangegangenen Restriktionen hat die Mail bereits abgeweisen.

Die Anweisung »check_policy_service« ist schon ein Ausblick auf die Delegierung von Entscheidungen an externe Programme. Sie weist Postfix an, über das Policy-Delegation-Protokoll Kontakt mit einem Server aufzunehmen, der über die weitere Verfahrensweise entscheidet (siehe [3]). Ein Satz von Metainformationen zu der Mail (Absender, Empfänger, HELO, Client IP, Verschlüsselung und so weiter, quasi alles außer dem Inhalt der Mail selbst) wird an diesen externen Server geschickt, der dann mit eine Rückgabecode aus »access(5)« antwortet und somit über Gedeih oder Verderb der Mail bestimmt. In diesem speziellen Fall lauscht dort der »policyd-weight« (siehe [4]).

Im Gegensatz zu Spamassassin, der alle Überprüfungen erst nach Einlieferung der Mail in die Queue vornimmt, weist »policyd-weight« die Mail bereits im SMTP-Dialog zurück, nachdem DNS-Blocklisten, »HELO« , »MAIL FROM« sowie die Client IP-Adresse in eine gewichtete Bewertung eingeflossen sind. Dabei spielt allerdings der Inhalt der Mail keine Rolle.

Die Restriktion »reject_rhsbl_sender« prüft, ob sich die Envelope-Sender-Adresse in der RHSBL (Right Hand Side Black List) von http://dsn.rfc-ignorant.org befindet. Diese RHSBL listet Domains auf, die keine Bounces (Nichtzustellbarkeitsmeldungen) annehmen. Sollte eine Mail auf dem eigenen Server nicht zustellbar sein, so ist es Postfixs Pflicht, den Absender mit einem Bounce darüber zu informieren. Den Bounce versendet es mit dem leeren Envelope Sender (»MAIL FROM:<>« ) versandt.

Leider blocken einige Server solche Mails, weshalb dann deren Benutzer nichts über Probleme bei der Zustellung ihrer Mails auf anderen Systemen erfahren. Diese Regel sorgt dafür, das von solchen Parteien keine Mail angenommen wird, weil ihr Verhalten den automatisierten Regelkreis von E-Mail zerstört.

Die Anweisung »reject_unverified_sender« ist eine der "teuersten" Restriktionen, verbraucht also relativ viele Ressourcen. Postfix prüft dabei, ob der Envelope Sender existiert, indem er eine SMTP-Sitzung mit den MX-Hosts für die Absender-Domain aufbaut und eine Zustellung an diese Adresse ausprobiert (siehe auch [5]). Die Resultate dieser Überprüfungen sollte man cachen, indem man noch zusätzlich den Parameter:

address_verify_map = btree:/etc/postfix/verify

definiert. So werden in einer Berkeley-DB vom Typ btree die positiven und negativen Testergebnisse gespeichert, somuss Postfix nicht immer wieder dieselben, häufig genutzten Adressen auf Gültigkeit prüfen muss.

Generell ist aber »reject_unverified_sender« mit Vorsicht zu genießen: Wenn Mails mit gefälschtem Absender bis zur Anweisung »reject_unverified_sender« "durchkommen", unternimmt Postfix zum Test Zustellversuche an diese gefälschten Adressen. Sperrt nun der Zielserver Clients (in diesem Fall also den eigenen Server), die zuviele Zustellversuche an falsche Emailadressen versuchen, so wird unterm Strich eine Denial-Of-Service-Attacke daraus, die einen selbst trifft. Daher kann es sinnvoll sein, »reject_unverified_sender« nur selektiv einzusetzen wie zum Beispiel auf [6] beschrieben.