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.

Listing 1

Anti-Spam-Config

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.

Tabelle 1

Restriktionen

Direktive

Bedeutung

reject_non_fqdn_sender

Weist Absender der Form » Absender « und » Absender@Host « (also ohne oder mit nicht voll-qualifiziertem Domainenanteil) ab.

permit_mynetworks

Erlaubt Mailversand/Relaying aus dem eigenen Netz »mynetworks« .

reject_unauth_destination

Unterbindet das Senden an nicht-autorisierte Ziele, also Ziele für die Postfix nicht selber zuständig ist. Diese Regel verhindert 3rd-Party-Relaying.

reject_unknown_sender_domain

Weist Mail von Absendern ab, deren Domainanteil weder einen A- noch MX-Eintrag hat.

reject_unlisted_recipient

An dieser Stelle wird auf einen gültigen Empfänger auf dem eigenen Mailserver geprüft. Dieser Test würde sonst erst implizit am Ende der Restriktionen erfolgen.

check_helo_access hash:/etc/postfix/helo_check

Postfix prüft, ob das durch den Client benutzte HELO/EHLO Argument auf eines der Muster in »/etc/postfix/helo_checks« passt.

check_recipient_access hash:/etc/postfix/roleaccount_exceptions

Postfix prüft, ob die durch den Client benutzte Empfängeradresse in »/etc/postfix/roleaccount_exceptions« steht. »hash:« gibt dabei an, dass es sich um eine Map im Berkeley-DB-Hash-Format handelt.

reject_invalid_helo_hostname

Weist ein syntaktisch ungültiges HELO/EHLO ab.

reject_non_fqdn_helo_hostname

Lehnt ein nicht voll-qualifiziertes HELO/EHLO ab.

check_policy_service inet:127.0.0.1:12525

Diese Restriktion weist Postfix an, über TCP mit Port 12525 auf localhost mit einem Server zu reden, der das Policy-Delegation-Protokoll spricht

reject_rhsbl_sender dsn.rfc-ignorant.org

 Prüft, ob sich die Envelope-Sender-Adresse in der Black List von http://dsn.rfc-ignorant.org befindet.

reject_unverified_sender

Postfix prüft durch eine echte SMTP-Verbindung, ob der Envelope Sender existiert.

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.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023