Postfix Konfiguration · 12 min read · Nov 14, 2025
Postfix Spamfilter mit Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC und ClamAV - Seite 3
2.3 Postfix Anti-Spam Einstellungen
Vorläufige Hinweise:
Wenn ein Client (ein Computer, der versucht, uns eine E-Mail zu senden) sich mit Postfix verbindet und eine Kommunikationssitzung beginnt, zeichnet Postfix Informationen über diese Sitzung auf. Vor dem Punkt, an dem Postfix E-Mails aus dieser Sitzung zur Zustellung akzeptiert, haben wir die Möglichkeit, die Sitzung zu bewerten und die E-Mail durch Festlegen einiger Einschränkungen in main.cf abzulehnen. Dieser Link veranschaulicht, was während einer typischen SMTP-Sitzung passiert: http://helpdesk.islandnet.com/pep/smtp.php. Die folgenden Einschränkungen helfen, einige Spam-Nachrichten abzuwehren und zu verhindern, dass unser System zu einem offenen Relay wird. Diese Einschränkungen führen dazu, dass einige E-Mails von Postfix direkt an der “Haustür” abgelehnt werden. Dies spart Systemressourcen, da die E-Mail nicht in unser System gelangt und daher nicht von MailScanner (und anschließend von SpamAssassin) gescannt wird. Das ist gut und schlecht. Es spart Systemressourcen, aber es lässt auch nicht zu, dass Sie die abgelehnten E-Mails sehen. Alles, was Sie sehen werden, ist ein oder zwei Protokolleinträge von Postfix, die im Wesentlichen sagen: “Hey, ein Mailserver namens “xxxxxxxx” mit der IP-Adresse X.X.X.X hat versucht, eine E-Mail zu senden, aber es hat die Regel XYZ verletzt, also habe ich sie abgelehnt”. Das könnte Spam gewesen sein (Spam-Versender halten sich oft absichtlich nicht an RFCs, um ihre Ziele zu erreichen), aber wenn es sich um eine “legitime” E-Mail handelt, sagen wir von einem Kunden, dessen IT-Abteilung einfach ihren Mailserver falsch konfiguriert hat (das passiert), könnten Sie einige zerzauste Federn zu bearbeiten haben.
Wenn Sie möchten, dass ALLE an uns adressierten E-Mails durch die Haustür kommen und daher MailScanner/SpamAssassin die gesamte Spam-Kontrolle innerhalb des Systems übernehmen kann, müssten Sie einige der untenstehenden Einstellungen ändern. Ich persönlich finde eine Kombination aus Postfix und SpamAssassin zur Spam-Kontrolle am besten. Mindestens müssen Sie sicherstellen, dass Sie die integrierte Standard-Anti-Relay-Kontrolle in Postfix nicht deaktivieren ( smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination).
Die folgende Konfiguration ist tatsächlich sehr konservativ und erlaubt den meisten E-Mails, durch die Haustür zu kommen, damit MailScanner und SpamAssassin ihre Chance darauf haben. Für mich lehnt sie (sicher) etwa 35 % der E-Mails ab, die für meine Benutzer bestimmt sind, daher denke ich, dass diese Einstellungen ziemlich wertvoll sind. Ich empfehle diesen Ansatz als Ausgangspunkt. Zusätzliche Einschränkungen hinzuzufügen, erhöht die Wahrscheinlichkeit, dass legitime E-Mails von falsch konfigurierten Computern abgelehnt werden. Wenn Sie sich entscheiden, in Zukunft Berechtigungen/Einschränkungen hinzuzufügen/zu entfernen, tun Sie dies jeweils einzeln und geben Sie sich ausreichend Zeit, um die Auswirkungen der Änderung zu bewerten. Ich empfehle dringend, dass Sie ein gutes Verständnis dafür haben, wie diese Einschränkungen funktionieren, bevor Sie Änderungen an den untenstehenden Einträgen vornehmen. Unter anderem könnte es, wenn Sie diese Dinge falsch machen, legitime E-Mails ablehnen und/oder dazu führen, dass wir zu einem offenen Relay werden. Beachten Sie, dass Einschränkungen nicht immer einschränken, einige erlauben auch.
Wenn Sie ein besseres Verständnis für diese Einstellungen gewinnen möchten, sind gute Ressourcen http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, das etwas veraltete (2001) http://www.mengwong.com/misc/postfix-uce-guide.txt und dieses ausgezeichnete Buch. Sie werden feststellen, dass ich nur einige der gleichen Einstellungen wie diese verwende, sodass diese Konfiguration bei weitem nicht so restriktiv ist. Denken Sie daran, dass SpamAssassin und MailScanner gleich ins Spiel kommen werden und uns viel flexiblere und konfigurierbare Optionen bieten, um Spam zu erkennen und zu manipulieren.
2.3.1 smtpd_helo_required
Lassen Sie jeden sich verbindenden Mailserver einen ordnungsgemäßen SMTP-“Handshake” durchführen und seinen Namen ankündigen. Internet-RFCs verlangen dies, also tun wir das auch.
postconf -e "smtpd_helo_required = yes"Präambel: Die Einschränkungsstufen von Postfix sind wie folgt und werden in der folgenden Reihenfolge verarbeitet:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictionsWir werden nur Einträge in den letzten drei Einschränkungsstufen platzieren. Einschränkungsstufen werden in dieser Reihenfolge verarbeitet, unabhängig von der in main.cf aufgeführten Reihenfolge.
2.3.2 smtpd_sender_restrictions
Diese Einschränkungsstufe beschränkt, welche Absenderadressen dieses System in MAIL FROM: Befehlen (dem Absender des Umschlags) akzeptiert. Wir werden drei Tests (Einschränkungen) in dieser Einschränkungsstufe platzieren.
Eine Einschränkungsstufe enthält eine Liste von Einschränkungen (Tests). Typischerweise bewerten Tests entweder DUNNO, REJECT oder OK. DUNNO bedeutet “Ich weiß nicht, was ich tun soll, lass den nächsten Test entscheiden”. REJECT lehnt die E-Mail einfach ab. OK bedeutet, dass keine weiteren Tests in dieser Einschränkungsstufe durchgeführt werden, die Tests setzen sich mit der nächsten Stufe fort (falls vorhanden). Reject*-Tests bewerten typischerweise mit REJECT oder DUNNO. Permit-Tests bewerten typischerweise mit OK oder DUNNO, und check__access-Typ-Tests können eine Vielzahl von Aktionen durchführen. Die Abbildung zeigt die grundlegende Logik.
SMTP-Sitzung
|
V
Einschränkungsstufe-------------
Test ---------------REJECT->
| \
| DUNNO
| \
| V
| nächster Test------REJECT->
| | \
OK OK DUNNO
| | \
| | V
V V
nächste Einschränkungsstufe------->2.3.2.1 check_sender_access
Siehe http://www.postfix.org/access.5.html. Hier bitten wir Postfix, den Absender des Umschlags mit Einträgen in einer /etc/postfix/sender_access-Datenbank zu vergleichen und auf diese Einträge zu reagieren, wenn eine Übereinstimmung gefunden wird. Wir definieren auch, welche Aktion dort (OK, DUNNO, REJECT usw.) auf Absenderbasis ergriffen wird. Wenn der Absender nicht in der Datei aufgeführt ist, bewertet der Test mit DUNNO, und der nächste Test wird durchgeführt. Ich werde später Beispiele bereitstellen. Eine Verwendung dieser Datei besteht darin, eine Liste von Absendern (E-Mail-Adressen, Domains, Netzwerkadressen usw.) zu erstellen, von denen wir keine E-Mails erhalten möchten (schwarze Liste). Wir werden auch die Möglichkeit haben, Absender in MailScanner und SpamAssassin auf die schwarze Liste zu setzen, aber es spart Ressourcen, wenn wir sie hier auf die schwarze Liste setzen. Wir werden diese Datei auch verwenden, um bestimmten Absendern zu erlauben, die nächsten beiden Tests in dieser Einschränkungsstufe zu umgehen. Wenn wir ihnen hier ein OK geben, werden keine weiteren Tests in dieser Einschränkungsstufe durchgeführt, die Tests setzen sich in der nächsten Einschränkungsstufe ( smtpd_recipient_restrictions) fort. Beachten Sie, dass, wenn wir diese Einstellung in der s mtpd_recipient_restrictions-Einschränkungsstufe vor dem reject_unauth_destination-Test platzieren würden und wir jemandem dort ein OK geben würden, der reject_unauth_destination-Test dort umgangen würde. Das wäre schlecht, da jeder, dem wir ein OK gegeben haben, dann unseren Server als offenes Relay verwenden könnte. Zugriffseinschränkungen werden in der gleichen Reihenfolge bewertet, in der wir sie auflisten, und wenn eine Übereinstimmung gefunden wird, beeinflusst dies, wie (ob) weitere Einschränkungen bewertet werden.
2.3.2.2 reject_non_fqdn_sender
Lehnen Sie ab, wenn die E-Mail-Adresse des Absenders des Umschlags nicht im richtigen Format vorliegt. Denken Sie daran, dass der “Absender des Umschlags” das ist, was der sendende Mailserver in der “MAIL FROM:”-Zeile während der SMTP-Sitzung angibt, nicht die “From:”-Zeile im Header. “Joe” darf uns keine E-Mail senden (weil wir nicht auf “Joe” antworten können), aber “[email protected]” ist zumindest eine E-Mail-Adresse. Wenn der Absender an diesem Punkt nicht abgelehnt wird, bewertet dieser Test mit “DUNNO”.
2.3.2.3 reject_unknown_sender_domain
Lehnen Sie ab, wenn der Domainteil der E-Mail-Adresse des Absenders des Umschlags keinen DNS “A”- oder “MX”-Eintrag hat. Diese Einstellung lehnt etwa 35 % der E-Mails ab, die auf meinen Mailserver kommen. Es ist üblich, dass Spammer einen gefälschten Domainnamen verwenden, damit sie sich nicht mit den Folgen abgelehnter E-Mails auseinandersetzen müssen. Es ist auch wichtig für uns, unsere Warteschlange nicht mit Bounce-Benachrichtigungen zu füllen, die aufgrund der Tatsache, dass die Domain des Absenders nicht einmal existiert, niemals zugestellt werden können. Wenn die Domain des Absenders einen “A”- oder “MX”-Eintrag hat, bewertet dieser Test ebenfalls mit “DUNNO”. Gelegentlich werden Sie in einem Bericht sehen, dass jemand, von dem Sie E-Mails erhalten möchten, durch diese Einstellung abgelehnt wurde. Ein möglicher Grund dafür ist, dass legitime Absender absichtlich gefälschte Domainnamen verwenden, damit Sie nicht auf sie antworten. Hier kommt die Absenderzugriffsliste ins Spiel. Sie können ihnen dort ein OK geben, und dieser Test wird umgangen.
Jetzt, um diese drei Einschränkungen zu implementieren:
postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"2.3.3 smtpd_recipient_restrictions
Die Zugriffseinschränkungen, die der Postfix SMTP-Server im Kontext des RCPT TO: Befehls anwendet. Dies bezieht sich auf den “Empfänger des Umschlags”, den der Client in der “RCPT TO:”-Zeile während der SMTP-Sitzung angegeben hat, nicht die “To:”-Zeile im Header. smtpdrecipient_restrictions ist eine weitere Einschränkungsstufe, die eine Liste spezifischer Einschränkungen enthält. Andere Einschränkungsstufen, die vor smtpd_recipient_restrictions bewertet werden, sind smtpd_client_restrictions, smtpd_helo_restrictions und smtpd_sender_restrictions (in dieser Reihenfolge). Einschränkungen, die normalerweise in diesen vorhergehenden Einschränkungsstufen stehen würden, können alternativ in smtpd_recipient_restrictions platziert werden. Daher ziehen es einige Leute vor, alle smtpd*_restrictions, die normalerweise in vorhergehenden Einschränkungsstufen stehen würden, in smtpd_recipient_restrictions (in der richtigen Reihenfolge) zu platzieren und die vorhergehenden Stufen unkonfiguriert (leer) zu lassen. In unserem Fall ist es sicherer, smtpd_sender_restrictions und smtpd_recipient_restrictions zu verwenden. Lassen Sie uns die spezifischen Einschränkungen (Tests) betrachten, die wir in smtpd_recipient_restrictions platzieren:
2.3.3.1 permit_mynetworks
Erlaubt Maschinen, die in “mynetworks” aufgeführt sind, die restlichen Tests in dieser Einschränkungsstufe zu überspringen (permit = OK). Mit anderen Worten, es verlässt diese Stufe und wird in der nächsten Stufe (smtpd_data_restrictions) getestet. Da permit_mynetworks vor reject_unauth_destination platziert ist, bedeutet dies, dass Maschinen in $mynetworks E-Mails an jede Domain weiterleiten dürfen. Ohne dies könnten wir nur E-Mails an unsere eigenen Domain(s) senden. Wenn die IP-Adresse des Absenders nicht in $mynetworks aufgeführt ist, bewertet der Test mit “DUNNO” und fährt mit dem nächsten Test (reject_unauth_destination) fort.
2.3.3.2 reject_unauth_destination
Diese Einstellung wird zusammen mit permit_mynetworks zur Relay-Kontrolle verwendet. Diese Einstellung bedeutet im Wesentlichen, dass E-Mails, die an eine Domain gerichtet sind, für die wir unsere Maschine nicht konfiguriert haben, abgelehnt werden. In unserem Fall wird Postfix die relay_domains-Einstellung (oder Tabelle), die wir zuvor konfiguriert haben, verwenden, um zu bestimmen, welche Domains das sind. Siehe http://www.postfix.org/postconf.5.html#reject_unauth_destination für weitere Details. Wenn die Domain in relay_domains aufgeführt ist, bewertet dieser Test mit “DUNNO” und die Sitzung darf zum nächsten Test (falls vorhanden) fortfahren. Genau wie “mynetworks” ist diese Einstellung äußerst kritisch. Indem wir permit_mynetworks direkt vor reject_unauth_destination platzieren, stellen wir sicher, dass wir E-Mails an Domains außerhalb unserer eigenen senden können, aber wir akzeptieren nur E-Mails, die an uns von Computern außerhalb unseres Netzwerks adressiert sind, sodass permit_mynetworks und reject_unauth_destination als Team arbeiten.
2.3.3.3 reject_unauth_pipelining
Lehnt Massenmailer ab, die versuchen, Pipelining zu verwenden, um die Zustellung zu beschleunigen, ohne vorher zu überprüfen, ob es unterstützt wird (nicht-RFC, häufig bei Spammern).
Jetzt, um diese drei Einschränkungen zu implementieren:
postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"2.3.4 smtpd_data_restrictions
Optionale Zugriffseinschränkungen, die der Postfix SMTP-Server im Kontext des SMTP DATA: Befehls anwendet. Wie smtpd_recipient_restrictions ist dies eine Einschränkungsstufe.
2.3.4.1 reject_unauth_pipelining
Ich wiederhole diese Einstellung in smtpd_data_restrictions, da sie nicht immer effektiv ist, wenn sie in smtpd_recipient_restrictions platziert wird. Ich füge sie in smtpd_recipient_restrictions ein, da ich sie gerne vor allen Richtliniendiensten platziere. Beachten Sie, dass es nur eine Handvoll von Einschränkungen gibt, die die smtpd_data_restrictions gut nutzen.
postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"2.3.5 Postfix-Inhaltsfiltersteuerungsdateien:
http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks und /etc/postfix/body_checks
Diese Dateien listen bestimmte “Strings” von Text auf und sagen Postfix, was mit E-Mails zu tun ist, wenn sie diese Strings in E-Mail-Headern oder im Text der Nachricht begegnen. Beispieldateien wurden bereits für uns erstellt, mit Kommentaren, die erklären, was wir dort einfügen sollen. Sie können sie nach Belieben bearbeiten. Beachten Sie, dass diese Dateien die Verwendung von “regulären Ausdrucksformaten” erfordern. “regexp” ist etwas, das Sie lernen möchten, um in der *nix-Welt zu leben. Besorgen Sie sich ein Buch oder recherchieren Sie es irgendwann im Internet. Für ein Beispiel einer ausgeklügelten header_checks-Datei von jemandem mit einer Einstellung, werfen Sie einen Blick auf http://www.geekounet.org/filters/header_checks. Aber folgen Sie dem nicht blind, es ist nur ein Beispiel! Hier ist ein Beispiel für eine body_checks-Datei: http://www.securitysage.com/files/body_checks. Es wäre lohnenswert, http://www.securitysage.com/guides/postfix_uce.html zu besuchen, wenn Sie einen Moment Zeit haben. Insbesondere http://www.securitysage.com/antispam/hedchek.html und http://www.securitysage.com/antispam/bodchek.html. Ich empfehle, keine große Anzahl von Änderungen an einem Teil von Postfix vorzunehmen, ohne sich ausreichend Zeit zu geben, um die Auswirkungen zu bewerten. Wie eine Schildkröte, gehen Sie langsam, leben Sie lange.
2.3.5.1 header_checks & body_checks
Lassen Sie uns diese beiden in main.cf einfügen. header_checks ist erforderlich, da es uns ermöglicht, alle eingehenden E-Mails zurückzuhalten, damit MailScanner seine Arbeit tun kann:
postconf -e "header_checks = pcre:/etc/postfix/header_checks"
postconf -e "body_checks = pcre:/etc/postfix/body_checks"Bearbeiten Sie header_checks:
vi /etc/postfix/header_checksFügen Sie diese Zeile zur header_checks-Datei hinzu, ohne sie wird MailScanner nicht funktionieren:
/^Received:/ HOLDBeachten Sie, dass wir pcre-Typ-Tabellen nicht postmapen müssen. Sie bleiben im Klartext und Postfix verwendet sie “as is”.
Sie könnten auch mime_header_checks und nested_header_checks zusammen mit header_checks und body_checks konfigurieren. Wenn Sie zu kreativ mit der Inhaltsfilterung in Postfix (unter Verwendung von header_checks und body_checks) werden, kann dies erhebliche Auswirkungen auf die Leistung haben.
2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html
Wir haben diese Datei in smtpd_sender_restrictions erwähnt. Wir verwenden diese Datei, um den Absender direkt an der Haustür zu überprüfen. In dieser Datei werden wir bestimmte Absender/Domains/IP-Adressbereiche für eine spezielle Behandlung auflisten. Unten sind gefälschte Beispiele, erstellen Sie Ihre eigenen, wie Sie es für richtig halten. Bitte lesen Sie /etc/postfix/sender_access für weitere Informationen. Obwohl Sie diese Datei für verschiedene Zwecke verwenden könnten, empfehle ich, sie zu verwenden, um entweder Absender auf die schwarze Liste zu setzen oder bestimmten Absendern zu erlauben, die verbleibenden Tests in smtpd_sender_restrictions zu umgehen.
vi /etc/postfix/sender_access#Beispiel für eine Absenderzugriffsdatei
[email protected] 550 Kein MLM danke
allspam.tld 550 Spam wird hier nicht akzeptiert
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OKDa dies eine Hashtabelle ist, müssen Sie sie wie gewohnt postmapen:
postmap /etc/postfix/sender_access2.3.6 Letzter Blick auf die Postfix-Installation
Überprüfen Sie die Änderungen:
less /etc/postfix/main.cfÜberprüfen Sie den Inhalt der Datei auf Fehler und reparieren Sie sie bei Bedarf. Starten Sie Postfix:
postfix startÜberprüfen Sie, ob Postfix antwortet:
telnet 127.0.0.1 25Sie sollten sehen:
220 [yourFQDNhere] ESMTP Postfix (Ubuntu)Drücken Sie ein paar Mal [enter]; geben Sie dann quit ein, um zu beenden.
Wenn es nicht auf diese Weise antwortet, öffnen Sie ein weiteres Terminalfenster und stoppen Sie Postfix postfix stop. Stellen Sie sicher, dass Sie newaliases und alle oben genannten postmap-Befehle ausgeführt haben. Überprüfen Sie alle Einstellungen in main.cf und master.cf. Es gibt ein schönes Papier zur Fehlersuche bei Postfix unter http://www.postfix-book.com/debugging.html, aber beachten Sie, dass unser System zu diesem Zeitpunkt nicht bereit ist, E-Mails weiterzuleiten (sie landen in der Warteschlange).
Jedes Mal, wenn Sie Änderungen an master.cf oder main.cf oder an Datentabellen vornehmen, ist es in den meisten (nicht allen) Fällen erforderlich, dass Sie Postfix mit:
postfix reloadneu laden.
Jetzt, da wir eine grundlegende Postfix-Konfiguration haben, sind http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall und http://www.postfix.org/BASIC_CONFIGURATION_README.html gute Orte, um ein besseres Verständnis für einige der Einstellungen zu gewinnen, die wir verwendet haben, und zu diesem Zeitpunkt werden diese READMEs mehr Sinn machen.
Standardmäßig läuft unser Postfix chrooted. Wenn Sie nicht wissen, was das bedeutet, wird es zu diesem Zeitpunkt nicht viel ausmachen. Ich überlasse es Ihnen, zu einem späteren Zeitpunkt zu recherchieren, was chroot bedeutet. Einige der Systemdateien, die Postfix benötigt, um ordnungsgemäß zu funktionieren, wurden während der Installation in das chroot-Gefängnis von Postfix (/var/spool/postfix) kopiert. Gelegentlich werden die Originaldateien geändert, und Postfix wird sich beschweren, dass die Kopie, die es hat, nicht mit dem Original übereinstimmt. Wenn dies geschieht, können Sie die Datei(en), über die Postfix sich beschwert hat, manuell in das chroot-Gefängnis kopieren, oder wir können einfach ein Skript ausführen, das mit dem Postfix-Quellcode geliefert wird (genannt LINUX2), das alle Dateien, die Postfix benötigt, wieder dorthin kopiert, wo sie benötigt werden.
cd /usr/local/src/postfix-2.3.3/examples/chroot-setup
postfix start
chmod +x LINUX2
cp LINUX2 /usr/bin
LINUX2
cd
postfix checkDies macht das LINUX2-Skript ausführbar, kopiert es in ein Verzeichnis in unserem Pfad und führt es dann aus. LINUX2 wird normalerweise alle Probleme oder Schwierigkeiten mit Postfix lösen, wenn Sie Fehler in den Protokollen sehen, die mit dem Zugriff auf Konfigurationsdateien oder -verzeichnisse zusammenhängen.
Erhalte neue Beiträge in deinem Posteingang.
Kein Spam. Jederzeit abmelden.