Postfix-Mailserver

Postfix ist ein effizienter und funktionsreicher Mailserver, der von Wietse Venema am IBM T.J. Watson-Forschungszentrum. Es sollte das beliebte sendmail ersetzen. Während Sendmail viele Jahre lang der beliebteste Mailserver war, ist die Popularität von Postfix aufgrund seiner einfachen Konfiguration, historisch sicheren Implementierung und Hochleistungsarchitektur wahrscheinlich über die von Sendmail hinaus gewachsen. Da Postfix außerdem so konzipiert ist, dass es sich äußerlich wie sendmail verhält, ist es meist ein Drop-in-Ersatz für den älteren, größeren und langsameren Mailserver. Es fehlen einige der obskuren Features von sendmail, aber die fehlenden Features werden von der überwiegenden Mehrheit der Benutzer selten verwendet, sodass sie nicht oft übersehen werden. Und er hat einige zusätzliche eigene Funktionen, die in anderen Mailservern nicht zu finden sind.

Postfix-Mailserver

Das Postfix-Projekt, das ursprünglich VMailer hieß (zum Glück für alle wurde der Name vor der Veröffentlichung aufgrund rechtlicher Verstrickungen des VMailer-Namens geändert), ist als eine Gruppe verwandter, aber getrennt ausführbarer Komponenten konzipiert, die Sicherheit durch Segmentierung bietet. Kleinere Teile sind auch einfacher zu debuggen. Die Internet-Homepage von Postfix ist www.postfix.org. Postfix ist eine ideale Mailserver-Wahl für neue Mail-Administratoren, und selbst erfahrene Sendmail-Administratoren könnten seine Einfachheit ansprechend finden. Weil es ein ziemlich kompatibles Sendmail-artiges Äußeres bietet und Programme mit denselben Namen bereitstellt (wie sendmail zum Versenden von E-Mails mailq für die Verwaltung der Warteschlange usw.) und die gleiche Art von Aliasen und Weiterleitungsdateien verwenden kann, die Sendmail verwendet, ist es möglich, Sendmail zu ersetzen, ohne vorhandene E-Mail-bezogene Tools neu zu konfigurieren oder lokale Skripte neu zu schreiben. Nach einem solchen Wechsel bemerken lokale Benutzer möglicherweise nicht einmal den Unterschied.

Inhalt

Allgemeine Optionen

Die Allgemeinen Optionen konfiguriert eine Reihe von Optionen bezüglich des allgemeinen Verhaltens von Postfix. Insbesondere werden hier die meisten Konfigurationsoptionen konfiguriert, die sich auf alle Benutzer und alle Nachrichten auswirken. Postfix, getreu seiner Philosophie der Einfachheit, erfordert normalerweise nur wenige Änderungen an der Konfigurationsdatei, um einen Mailserver effizient und sicher zum Laufen zu bringen.

Die Allgemeinen Optionen Seite ist in zwei Teile geteilt. Der obere Abschnitt trägt die Bezeichnung Nützlichste allgemeine Optionen und den unteren Abschnitt Andere allgemeine Optionen . In vielen Standardinstallationen kann es möglich sein, eine Postfix-Installation nur mit der Konfiguration einer oder mehrerer der drei Direktiven im oberen Abschnitt zu starten. Sofern nicht anders angegeben, entsprechen alle Optionen auf dieser Seite den Anweisungen in der main.cf Datei im Postfix-Konfigurationsverzeichnis.

Nützlichste allgemeine Optionen

Die drei Optionen in diesem Abschnitt sind bei manchen Installationen die einzigen Optionen, die geändert werden müssen, damit Postfix sowohl zum Senden als auch zum Empfangen von E-Mails läuft.

Nützlichste allgemeine Optionen

Welche Domäne für ausgehende E-Mails verwendet werden soll

Hier können Sie den Domänen- oder Hostnamen angeben, der verwendet wird, um die Quelle ausgehender E-Mails zu identifizieren. Postfix verwendet standardmäßig den Hostnamen des Servers, aber Sie möchten höchstwahrscheinlich, dass E-Mails stattdessen als von Ihrem Domänennamen stammend identifiziert werden. Wenn Ihr Mailserver E-Mails für eine große Anzahl von Benutzern unter einem einzigen Domänennamen akzeptiert, werden Sie höchstwahrscheinlich den Domänennamen hier konfigurieren und eine domänenweite Alias-Datenbank erstellen, um Benutzernamen ihren jeweiligen lokalen Mailservern zuzuordnen. Diese Option korreliert mit myorigin Postfix-Anweisung.

Für welche Domain E-Mails empfangen werden sollen

Diese Option akzeptiert eine Liste von Domains und Adressen zum Empfangen von E-Mails als Endziel. Mit anderen Worten, wenn E-Mails den Server erreichen, der für Adressen in diesem Feld bestimmt ist, wird die E-Mail an einen lokalen Benutzer zugestellt, anstatt sie an einen anderen E-Mail-Server weiterzuleiten. Standardmäßig sind dies alle konfigurierten Adressen auf dem Rechner sowie localhost innerhalb der lokalen Domäne. Sie können eine beliebige Anzahl von Domänen oder Hostnamen durch Kommas getrennt angeben, oder Sie können einen vollständigen Pfad zu einer Datei angeben, die ähnliche Einträge enthält. Die Variablen $myhostname und $mydomain kann verwendet werden, um diese Konzepte automatisch für Postfix darzustellen. Die Fähigkeit von Postfix, solche Variablen in seinen Konfigurationsdateien zu verwenden, macht es einfacher, eine Reihe von Postfix-Servern mit sehr ähnlichen Konfigurationen zu verwalten. Diese Option korreliert mit mydestination Richtlinie.

Welche Probleme dem Postmeister zu melden sind

Postfix bietet die Möglichkeit auszuwählen, welche Arten von Fehlermeldungen an den designierten Postmaster gesendet werden des Mailservers. Angenommen, Sie haben einen postmaster eingerichtet Alias, der E-Mails an eine reale Person weiterleitet, sendet Postfix Berichte über alle hier bezeichneten Arten von Problemen. Die verfügbaren Klassen sind:

bounce: Wenn diese Option ausgewählt ist, wird immer dann, wenn eine Nachricht unzustellbar ist, eine Bounce-Nachricht (sogenannte einzelne Bounce-Nachricht wird an den Absender der Nachricht und den örtlichen Postmeister gesendet. Aus Datenschutzgründen werden nur die Kopfzeilen in der Nachricht an den Postmaster gesendet. Wenn der erste Bounce an den Absender als unzustellbar zurückgesendet wird, eine Doppelbounce-Nachricht wird mit dem gesamten Inhalt der ersten einzelnen Bounce-Nachricht an den Postmaster gesendet.
2bounce: Bewirkt, dass doppelte Bounce-Nachrichten an den Postmaster gesendet werden.
delay: Wenn sich die Zustellung einer Nachricht verzögert, erhält der Postmaster eine Benachrichtigung zusammen mit den Kopfzeilen der verspäteten Nachricht.
policy: Benachrichtigt den Postmaster über Nachrichten, die aufgrund einer Richtlinieneinschränkung für unerwünschte kommerzielle E-Mails abgelehnt wurden. Das vollständige Protokoll der SMTP-Sitzung wird gesendet.
protocol: Benachrichtigt den Postmaster über Protokollfehler oder Clientanfragen, die nicht implementierte Befehle enthielten. Die vollständige Abschrift der SMTP-Sitzung ist in der Nachricht enthalten.
resource: Informiert den Postmaster über nicht zugestellte E-Mails aufgrund von Ressourcenproblemen, wie z. B. einem Schreibfehler einer Warteschlangendatei.
software: Benachrichtigt den Postmeister über Post, die aufgrund von Softwarefehlern nicht zugestellt wurde.

Diese Option korreliert mit notify_classes Direktive und meldet standardmäßig nur Probleme, die normalerweise auf eine Fehlkonfiguration oder ein schwerwiegendes Problem hinweisen (insbesondere resource und software ). In einigen Umgebungen mit hoher Auslastung könnte die Änderung dieser Einstellung, um Bounce-Benachrichtigungen einzubeziehen, zu einer großen Anzahl von Benachrichtigungen führen. Diese Option muss nur selten geändert werden, außer zur Fehlerbehebung..

Andere allgemeine Optionen

Der untere Abschnitt dieser Seite ist globalen Optionen gewidmet, die mit geringerer Wahrscheinlichkeit geändert werden müssen. In vielen Installationen bleiben diese Optionen auf ihren Standardwerten.

Andere allgemeine Optionen

Ausgehende Mail senden per: Diese Option konfiguriert, ob ausgehende E-Mails direkt an den Mailserver des Empfängers zugestellt werden sollen oder ob ein übergeordnetes Mail-Gateway als Vermittler verwendet werden soll. Wenn sich der Server hinter einer Firewall, hinter einem Router/Gateway, der die Netzwerkadresse übersetzt, oder ähnlichem befindet, kann es erforderlich sein, einen zwischengeschalteten Server zu verwenden, um einen zuverlässigen Dienst zu erreichen. Viele Mailserver im Internet akzeptieren keine E-Mails von einem Server, der keinen funktionierenden DNS-Eintrag und keine routingfähige IP-Adresse hat, um Spam von gefälschten Adressen zu verhindern. Außerdem kann die Verwendungsrichtlinie für lokale Netzwerke die Verwendung eines Vermittlers für die Protokollierung, Virenprüfung oder andere Zwecke erfordern, die eine Aggregation des ausgehenden E-Mail-Verkehrs auf einem zentralen Server erfordern. Diese Option entspricht dem relayhost Direktive und sendet E-Mails standardmäßig direkt an den E-Mail-Server, der durch den MX-Eintrag (Mail Exchanger) für die Zieldomäne angegeben ist.
Adresse, die bcc jeder Nachricht empfängt: Mit dieser Option kann optional eine E-Mail-Adresse angegeben werden, die eine Kopie jeder Nachricht erhält, die in das Postfix-System eingeht, ausgenommen lokal generierte Bounce-Nachrichten. Dies kann unter vielen Umständen eine Verletzung der Privatsphäre darstellen und kann in einigen Ländern illegal sein. Es ist ratsam, bei der Verwendung dieser Option besonders vorsichtig zu sein. Es kann jedoch in einigen Umgebungen nützlich sein, in denen eine zentrale Archivierung von E-Mails aus rechtlichen oder technischen Gründen sinnvoll ist. Diese Option korreliert mit always_bcc Direktive und standardmäßig auf none.
Zeitüberschreitung bei der Bearbeitung von Anfragen: Diese Option legt fest, wie lange ein Postfix-Daemon auf den Abschluss einer Anfrage wartet, bevor er davon ausgeht, dass der Daemon abgestürzt ist, woraufhin der Daemon beendet wird. Diese Option entspricht dem daemon_timeout Direktive und ist standardmäßig auf 18000 Sekunden eingestellt.
Standarddatenbanktyp: Diese Option bestimmt den Datenbanktyp, der in postalias verwendet werden soll und postmap Befehle. Diese Option entspricht dem default_database_type Direktive und die Standardeinstellung hängt vom Betriebssystem und den installierten Systembibliotheken zum Zeitpunkt der Erstellung von Postfix ab. Normalerweise ist dies auf UNIX-Systemen hash oder dbm .
Standardtransport für Nachrichtenübermittlung: Der Begriff Liefertransport bezieht sich auf das Protokoll oder die Sprache, die verwendet wird, um die Nachricht von einem Mailserver an einen anderen zu übermitteln. Der Transport auf modernen Systemen ist fast immer smtp , und dies ist die Standardeinstellung in Postfix, aber es gibt noch ein paar veraltete uucp Systeme im Einsatz. Diese Option ist lediglich die Standardauswahl, wenn für das Ziel in der optionalen Transporttabelle kein Transport explizit ausgewählt ist. Diese Option entspricht dem default_transport Richtlinie.
Absenderadresse für Bounce-Mail: Für den Fall, dass eine Nachricht doppelt zurückgesendet wird oder zuerst vom Empfänger und dann vom Absender zurückgeschickt wird, wenn die erste Unzustellbarkeitsbenachrichtigung gesendet wird, wird die Nachricht an diese Adresse gesendet. Alle Nachrichten an diese Adresse werden stillschweigend verworfen. Auf diese Weise können Bounce-Loops vermieden werden. Diese Option entspricht dem double_bounce_sender Direktive und ist standardmäßig double-bounce . Der Name kann beliebig sein, muss aber eindeutig sein.
Anzahl der Unterverzeichnisebenen unterhalb des Warteschlangenverzeichnisses: Diese Option konfiguriert die Anzahl der Unterverzeichnisebenen unterhalb der konfigurierten Warteschlangenverzeichnisse, die von Postfix für die Mailspeicherung verwendet werden. Aufgrund des Designs des traditionellen UNIX-Dateisystems, das UFS enthält, das von einigen älteren BSD- und einigen anderen älteren UNIX-Dateisystemen verwendet wird, wird die Leistung messbar langsamer, wenn eine extrem große Anzahl von Dateien in einem einzigen Verzeichnis gespeichert wird. Daher bieten Programme, die eine große Anzahl von Dateien generieren, häufig die Möglichkeit, Dateien auf eine Reihe von Unterverzeichnissen aufzuteilen, um die Suche schnell zu halten. Diese Option korreliert mit hash_queue_depth Direktive und ist standardmäßig auf 2 eingestellt, was für die meisten moderaten und sogar relativ großen Installationen geeignet ist. Da die Anzahl der verwendeten Verzeichnisse die Suchzeit für Objektsuchen erhöht, kann die Verwendung eines zu hohen Werts hier die Leistung beeinträchtigen. Diese und die nächste Option wurden durch moderne Dateisystemdesigns, die viele Millionen Dateien ohne signifikante Leistungseinbußen verarbeiten, weitgehend irrelevant gemacht.
Name der auf Unterverzeichnisse aufgeteilten Warteschlangenverzeichnisse: Postfix verwendet eine Reihe von Warteschlangen, um Nachrichten mit unterschiedlichen Zuständen und Zielen zu organisieren. Jede dieser Warteschlangen kann so konfiguriert werden, dass sie gehashte Unterverzeichnisse verwendet oder nicht. Wenn hier eine Warteschlange ausgewählt wird, wird sie in einem gehashten Unterverzeichnis gespeichert. In einigen Fällen darf eine Warteschlange hier nicht aufgeführt werden, da die Leistung stark beeinträchtigt wird, insbesondere das für alle Benutzer beschreibbare Mail-Drop-Verzeichnis. Das Verzeichnis der Defer-Protokolldatei hingegen muss in gehashten Verzeichnissen gespeichert werden, da sonst die Leistung leidet. Diese Option entspricht den hash_queue_names Direktive und ist standardmäßig incoming,active,deferred,bounce,defer,flush und es ist selten notwendig oder vorteilhaft, diese Konfiguration auf modernen Systemen zu ändern.
Maximale Anzahl von Received: Kopfzeilen: Eine Nachricht, die mehr Received: enthält Kopfzeilen, als dies abprallen wird. Eine extrem große Anzahl dieses Headers kann auf eine Mail-Schleife oder einen falsch konfigurierten Mail-Server irgendwo im Pfad dieser Nachricht hindeuten. Diese Option korreliert mit dem hopcount_limit Direktive und ist standardmäßig auf 50 eingestellt. Dieser Wert muss selten von seinem Standardwert geändert werden.
Zeit in Stunden, bevor eine Warnung wegen Nichtlieferung gesendet wird: Wenn eine Nachricht nicht sofort zugestellt werden kann, wird sie für eine spätere Zustellung in die Warteschlange gestellt. Wenn die Nachricht nach dieser Anzahl von Stunden immer noch nicht zugestellt werden kann, wird eine Warnung an den Absender gesendet, die ihn darüber informiert, dass der Server die Nachricht für eine bestimmte Zeit nicht senden konnte. Dies entspricht der delay_warning_time Direktive und sendet standardmäßig keine Warnung.
Netzwerkschnittstellen zum Empfangen von E-Mails: Diese Option konfiguriert die Netzwerkadressen, auf denen Postfix E-Mail-Zustellungen akzeptiert. Standardmäßig akzeptiert Postfix E-Mails auf jeder aktiven Schnittstelle. Hier akzeptiert Postfix die zuvor besprochenen Variablen. Diese Option konfiguriert die inet_interfaces Richtlinie.
Leerlaufzeit, nachdem der interne IPC-Client die Verbindung getrennt hat: Diese Option legt die Zeit in Sekunden fest, nach der ein interner IPC-Client die Verbindung trennt. Dadurch können Server freiwillig beendet werden. Diese Funktion wird von den Adressauflösungs- und Umschreibungsclients verwendet. Diese Option korreliert mit der idle_time Direktive und ist standardmäßig 100s. Diese Option sollte unter normalen Umständen wahrscheinlich nie geändert werden müssen.
Timeout für E/A auf internen Kommunikationskanälen: Diese Option bestimmt die Zeit in Sekunden, die der Server auf I/O auf internen Kommunikationskanälen wartet, bevor er unterbrochen wird. Wird das Timeout überschritten, bricht der Server mit einem fatalen Fehler ab. Diese Direktive entspricht dem ipc_timeout Direktive und ist standardmäßig auf 3600 Sekunden oder 60 Minuten eingestellt.
Mailsystemname: Diese Option identifiziert das verwendete Mailserver-System für verbindende Benutzer. Es wird im smtpd_banner verwendet die in Received: gesendet wird Kopfzeilen, das SMTP-Begrüßungsbanner und in unzustellbaren E-Mails. Einige Sicherheitsexperten, die Sicherheit durch Unklarheit fördern, schlagen vor, die gesamte Serversoftware zu anonymisieren, um zu verhindern, dass potenzielle Cracker die auf dem Server verwendete Software identifizieren können. In den meisten Umgebungen ist dies jedoch wahrscheinlich nicht die beste Nutzung der Zeit oder des Aufwands eines Administrators, und viele andere Sicherheitstaktiken sind effektiver, ohne die Fähigkeit zur Verfolgung von Softwareproblemen negativ zu beeinflussen. Diese Option korreliert mit dem mail_name Direktive und ist standardmäßig Postfix .
E-Mail-Besitzer: Diese Option gibt den Eigentümer der Postfix-Mailwarteschlange und der meisten Postfix-Daemon-Prozesse an. Dieser Benutzer sollte auf dem System eindeutig sein und keine Gruppen mit anderen Konten teilen oder andere Dateien oder Prozesse auf dem System besitzen. Nach dem Binden an den SMTP-Port (25) kann Postfix dann Root-Privilegien fallen lassen und für alle neuen Daemon-Prozesse der hier angegebene Benutzer werden. Wenn der Postfix-Daemon jemals kompromittiert wird, hat der Angreifer daher nur Zugriff auf E-Mails und einige andere Dateien. Natürlich ist es gut, auch dies zu vermeiden, aber es ist sicherlich besser als ein Root-Exploit, der es dem Exploiter ermöglichen würde, auf alles im System zuzugreifen und es zu ändern. Diese Option korreliert mit mail_owner Direktive und ist standardmäßig postfix .
Offizielle Version des Mailsystems: Dieser Parameter konfiguriert unter anderem die Versionsnummer, die von Postfix im SMTP-Begrüßungsbanner gemeldet wird. Dies entspricht der mail_version Direktive und verwendet standardmäßig die Version von Postfix, die installiert ist. Auch hier kann die Sicherheit durch Verschleierungspromotoren die Verschleierung dieses Wertes fördern.
Zeit zum Warten auf die nächste Serviceanfrage: Ein Postfix-Daemon-Prozess wird nach der hier angegebenen Zeit beendet, wenn er während dieser Zeit keine neue Dienstanfrage erhält. Diese Option entspricht dem max_idle Direktive und ist standardmäßig 100s . Diese Anweisung wirkt sich nicht auf den Daemon-Prozess des Warteschlangenmanagers aus.
Max. bearbeitete Serviceanfragen vor dem Beenden: Diese Option konfiguriert die maximale Anzahl von Anfragen, die ein einzelner Postfix-Daemon-Prozess beantwortet, bevor er beendet wird. Diese Option konfiguriert max_use Direktive und ist standardmäßig 100 .
Internet-Hostname dieses Mailsystems: Diese Option gibt den Internet-Hostnamen des Mailservers an. Standardmäßig wird dieser Wert auf den vollständig qualifizierten Hostnamen des Servers gesetzt, wie er durch einen Aufruf von gethostname() bestimmt wird . Diese Option legt den $myhostname fest Variable, die in den Standardeinstellungen für viele andere Optionen verwendet wird. Diese Option korreliert mit myhostname Richtlinie.
Lokaler Internetdomänenname: Diese Option entspricht mydomain Direktive und verwendet standardmäßig den Inhalt von $myhostname Variable abzüglich der ersten Komponente. Diese Option definiert den $mydomain Variable und wird in einer Reihe anderer Standardwerte für Konfigurationsoptionen verwendet.
Lokale Netzwerke: Postfix bietet einen flexiblen Satz von Optionen, um UCE oder andere nicht autorisierte Verwendungen des Mailservers zu verhindern. Diese Option definiert, welche Netzwerke von Postfix als lokal betrachtet werden. Der Wert wird verwendet, um zu bestimmen, ob ein Client ein lokaler Client oder ein Remote-Client ist. Die Richtlinien können für lokale Kunden entspannter sein. Diese Option konfiguriert mynetworks Direktive und zeigt standardmäßig eine Liste aller mit dem Server verbundenen Netzwerke an. Wenn der Server beispielsweise eine IP-Adresse von 192.168.1.48 und eine Netzmaske von 255.255.255.0 hat, wird das gesamte 192.168.1.0-Netzwerk als lokal betrachtet. Wenn Sie eine strengere Kontrolle oder die Möglichkeit wünschen, andere Netzwerkblöcke als lokale Clients zu behandeln, können Sie diese hier in Form von Netzwerk-/Maskenpaaren angeben (d. h. 172.16.0.0/16 . Netz/Masken-Paare können auf Wunsch aus einer separaten Datei eingefügt werden, indem hier der absolute Pfad zur Datei angegeben wird.
Postmaster-Benachrichtigung über Unzustellbarkeit senden an...: Diese Option konfiguriert den Benutzernamen oder die E-Mail-Adresse, an die Bounce-Benachrichtigungen gesendet werden. Diese Option korreliert mit dem bounce_notice_recipient Direktive und ist auf postmaster gesetzt standardmäßig.
Postmaster-Benachrichtigung auf 2bounce senden an...: Diese Option konfiguriert den Benutzernamen oder die E-Mail-Adresse, an die zweite Bounce-Nachrichten gesendet werden. Dies ermöglicht es einem Administrator, Warnungen vor zweiten Bounces genauer zu beobachten als Nachrichten bei ersten Bounces, da erste Bounces viel häufiger auftreten und weniger wahrscheinlich auf ernsthafte Probleme hinweisen. Die Option konfiguriert den 2bounce_notice_recipient Direktive und ist standardmäßig postmaster .
Verspätungsbenachrichtigung des Postmeisters an...: Diese Option konfiguriert, wohin Verzögerungswarnungen gesendet werden. Diese Option entspricht dem delay_notice_recipient Direktive und ist standardmäßig postmaster .
Postmaster-Benachrichtigung bei Fehler senden an...: Gibt an, wohin Fehlerwarnungen gesendet werden. Diese Option korreliert mit dem error_notice_recipient Direktive und ist standardmäßig postmaster .
Verzeichnis der E-Mail-Warteschlange: Dies gibt das Verzeichnis an, in dem Postfix in der Warteschlange befindliche E-Mails speichert. Dies wird auch das Root-Verzeichnis für Postfix-Daemons sein, die in einer Chroot-Umgebung laufen. In der Warteschlange werden Nachrichten gespeichert, die auf die Zustellung warten, daher sollte in diesem Verzeichnis genügend Platz vorhanden sein, um die E-Mail-Last Ihrer Benutzer aufzunehmen. Diese Option korreliert mit dem queue_directory Direktive und ist normalerweise standardmäßig an einem vernünftigen Ort für Ihr Betriebssystem. Viele Linux-Systeme haben die Mail-Warteschlange in /var/spool/mail oder /var/spool/postfix .
Dateiverzeichnis sperren, relativ zum Warteschlangenverzeichnis: Diese Option konfiguriert den Speicherort des Postfix-Sperrverzeichnisses. Es sollte relativ zum Warteschlangenverzeichnis angegeben werden und ist im Allgemeinen einfach ein Unterverzeichnis des Warteschlangenverzeichnisses. Diese Option konfiguriert das process_id_directory Direktive und ist standardmäßig pid .
Trennzeichen zwischen Benutzernamen und Adresserweiterungen: Diese Option gibt das Trennzeichen zwischen Benutzernamen und Adresserweiterungen an. Diese Option korreliert mit dem recipient_delimiter Direktive und verwendet standardmäßig kein Trennzeichen. Diese Option wirkt sich auf die kanonische Zuordnung aus , Verlagerte Zuordnung und Virtuelle Domains .
Verzeichnis für Postfix-Unterstützungsprogramme und -Daemons: Diese Option gibt das Verzeichnis an, in dem Postfix nach seinen verschiedenen Hilfsprogrammen und Daemons sucht. Das Verzeichnis sollte root gehören . Diese Option korreliert mit dem program_directory Direktive und Standardeinstellungen variieren je nach Installationsmethode und Betriebssystemvariante. Auf vielen Linux-Systemen ist dies /usr/libexec/postfix .
Mapping-Lookup-Tabellen verschoben: Postfix kann als Antwort auf Nachrichten, die an Benutzer gesendet werden, die keine E-Mails mehr von diesem Server erhalten, eine Umzugsbenachrichtigung bereitstellen. Wenn diese Option aktiviert ist, gibt sie den Speicherort der Datei an, die eine Tabelle mit Kontaktinformationen für Benutzer enthält, die nicht mehr auf diesem System vorhanden sind. Standardmäßig ist diese Funktion deaktiviert. Diese Option korreliert mit den relocated_maps Richtlinie. Wenn diese Option aktiviert ist, könnte eine vernünftige Wahl für diese Option /etc/postfix/relocated sein .
Kernel-Dateisperre für Postfächer deaktivieren: Auf Sun-Workstations können Kernel-Dateisperren Probleme verursachen, da das mailtool Programm hält eine exklusive Sperre, wenn sein Fenster geöffnet ist. Benutzer anderer OS-Varianten oder Sun-Systeme, auf denen keine Sun-Mail-Software verwendet wird, können diese Option ignorieren. Diese Option korreliert mit sun_mailtool_compatibility Direktive und ist standardmäßig No .
Maximale Zeit zum Senden eines Triggers an einen Daemon: Diese Option gibt die maximal zulässige Zeitspanne an, um einen Trigger an einen Postfix-Daemon zu senden. Diese Begrenzung hilft zu verhindern, dass Programme hängen bleiben, wenn das E-Mail-System extrem stark ausgelastet ist. Diese Option korreliert mit dem opts_trigger_timeout Direktive und ist standardmäßig 10s .

Umschreiben und Maskieren von Adressen

Postfix bietet ein relativ einfach zu verwendendes und flexibles System zum Umschreiben von Adressen, das es ermöglicht, als Mail-Gateway für ein großes Netzwerk oder als Gateway zwischen Legacy-Mail-Systemen und dem Internet insgesamt zu fungieren.

Umschreiben und Maskieren von Adressen

Hinweis:

Die Optionen auf dieser Seite werden auch auf der Seite Postfix Configuration - Address Rewriting auf der Postfix-Homepage besprochen. Es lohnt sich, es zu lesen, wenn in Ihrem Mailsystem eine erweiterte Adressumschreibung erforderlich ist.

Schreiben Sie "user%domain" in "user@domain" um: Diese Option ist nützlich für einige Altsysteme, die seltsame Adresstricks verwenden, wie zum Beispiel user%domain@otherdomain . Es ist in modernen Umgebungen im Allgemeinen nicht nützlich, aber es ist nicht schädlich, daher ist die Standardeinstellung normalerweise Yes . Diese Option entspricht dem allow_percent_hack Richtlinie.
Schreiben Sie "user" in "user@$mydomain" um: Diese Option konfiguriert, wie Postfix mit einer Adresse umgeht, die keinen Domänennamen im Ziel hat. Wenn aktiviert, wird der Wert von $mydomain angehängt an die Adresse. Diese Option entspricht dem append_at_myorigin Direktive und ist standardmäßig Yes . Weil die meisten Postfix-Komponenten erwarten, dass Adressen die Form user@domain haben Es ist wahrscheinlich nie angebracht, diese Funktion zu deaktivieren.
Schreiben Sie „user@host“ in „user@host.$mydomain“ um: Diese Option konfiguriert, ob einfache Hostadressen den Wert $mydomain haben an sie angehängt. Diese Option korreliert mit append_dot_mydomain Direktive und ist standardmäßig Yes . Einige Administratoren stellen möglicherweise fest, dass dieses explizite Umschreiben unerwartete Folgen hat, aber es ist sehr selten ein Problem.
Schreiben Sie "site!user" in "user@site" um: Legacy-UUCP-Netzwerke verwenden ein anderes Adressierungsformat als moderne SMTP-Systeme. Diese Option ermöglicht es Postfix, die Adresse im alten Stil in eine moderne Adresse für die Zustellung über das Standard-SMTP-Protokoll umzuwandeln. Diese Option konfiguriert den swap_bangpath Direktive und ist standardmäßig Yes .
E-Mail mit leerem Empfänger senden an...: Gibt das Ziel von unzustellbarer Post an. In der Regel handelt es sich dabei um Bounce-Benachrichtigungen und andere Fehlermeldungen. Diese Option entspricht dem empty_address_recipient Direktive und ist standardmäßig MAILER-DAEMON , was standardmäßig einfach ein Alias für postmaster ist .
Adressmaskierung: Address Masquerading ist eine Methode, bei der Hosts hinter dem Gateway-Mailserver verborgen werden können und alle E-Mails so erscheinen, als ob sie vom Gateway-Server stammen. Wenn aktiviert, wird der Host- und/oder Subdomain-Teil einer Adresse entfernt und nur die hier angegebene Domain wird in die Adresse aufgenommen. Wenn beispielsweise $mydomain wird hier angegeben, eine ausgehende Mail von [email protected] würde einfach [email protected] werden , vorausgesetzt, die Variable $mydomain enthält swelltech.com . Diese Option korreliert mit masquerade_domains Direktive und ist standardmäßig deaktiviert.
Ausnahmen maskieren: Es ist möglich, die oben definierten Maskerade-Regeln für einige Benutzernamen zu überspringen. Die Namen, die von diesen Regeln ausgenommen werden sollen, können hier eingegeben werden. Diese Option entspricht den masquerade_exceptions Direktive und standardmäßig werden keine Ausnahmen gemacht.

Mail-Aliase

E-Mail-Aliase bieten eine Möglichkeit, E-Mails an lokale Empfänger umzuleiten. Insbesondere ermöglicht es, dass Post, die für eine Anzahl verschiedener Adressen bestimmt ist, an eine einzige Mailbox geliefert wird. Eine übliche Verwendung dafür ist das Direktmailing für Benutzer wie postmaster zu einem echten Menschen. Diese Seite ist in zwei Bereiche unterteilt. Der obere Abschnitt mit der Bezeichnung Alias-Optionen enthält den Speicherort und das Format der Alias-Dateien, die Postfix verwenden sollte, um seine Alias-Datenbanken zu erstellen, und gibt den Typ der zu verwendenden Datenbank an. Der untere Abschnitt enthält eine Liste aller konfigurierten Aliasnamen auf dem System und was der Alias zugeordnet ist.

Aliase-Optionen

Alias-Datenbanken, die vom lokalen Zustellungsagenten verwendet werden: Diese Option legt die Dateinamen fest, die Postfix für die lokale Aliasübersetzung verwendet. An den Dateinamen wird je nach Dateityp ein Suffix angehängt. Diese Option korreliert mit alias_maps Direktive und die Standardeinstellung ist systemabhängig. Einige gängige Standardwerte sind hash:/etc/aliases oder hash:/etc/postfix/aliases . Der erste Teil des Eintrags, der dem Doppelpunkt vorangeht, ist der zu verwendende Datenbanktyp, der hash sein wird für Systeme mit einer modernen Berkeley-DB-Implementierung dbm für ältere Systeme, die nur dbm haben verfügbar oder nis für Systeme, die NIS ausführen. Der Teil nach dem Doppelpunkt des Eintrags ist der Pfad zu dem Dateinamen, von dem der Datenbankname abgeleitet wird. Die Datenbanken werden von Postfix beim Start oder beim Ausführen der newaliases aus den Inhalten der Flatfiles erstellt Befehl.
Von Postfix erstellte Alias-Datenbanken: Diese Option, die eng mit der obigen verwandt ist, gibt die Alias-Datenbankdatei(en) an, die erstellt werden, wenn newaliases oder sendmail -bi Befehle werden ausgeführt. Diese Befehle generieren die Alias-Datenbank aus der Flatfile in der obigen Option, um die von Postfix durchgeführte Alias-Suche zu beschleunigen. Da es auf einem großen Mailserver Tausende von Aliasen geben kann, ist es notwendig, sie in eine Datenbank zu importieren, um die Effizienz aufrechtzuerhalten. Diese Option korreliert mit der alias_database Richtlinie. Die Standardeinstellungen sind systemabhängig, entsprechen jedoch im Allgemeinen der obigen Option, wobei das entsprechende Datenbankdatei-Suffix angehängt wird.

Aliase

Dieser Abschnitt der Seite enthält eine Liste aller konfigurierten Aliase. Um einen Alias zu bearbeiten, klicken Sie auf den Namen des Alias. Um einen Alias zu erstellen, klicken Sie auf Neuen Alias erstellen und füllen Sie den Alias Name aus , und Alias to... Felder. Wenn die Aliase-Dateien geändert wurden, müssen auch die Aliase-Datenbankdateien neu erstellt werden, damit die Änderungen wirksam werden. Bei der Verwendung von Webmin wird dieser Schritt automatisch durchgeführt und es sind keine weiteren Schritte erforderlich.

Hinweis:

Wenn Sie Aliase über die Befehlszeile hinzufügen, ist es möglich, die Aliase-Datenbank mit dem Befehl postalias neu zu generieren . Die Manpage für diesen Befehl ist eine nützliche Ressource, um zu verstehen, wie Aliase-Datenbanken in Postfix gehandhabt werden.

Kanonisches Mapping

Die kanonische Zuordnung in Postfix wird zum Ändern von E-Mails in der Eingangswarteschlange verwendet und ändert sowohl die Nachrichtenkopfzeilen als auch die Nachrichtenumschlaginformationen für lokale oder entfernte E-Mails. Diese Zuordnung kann nützlich sein, um Anmeldenamen durch Vorname.Nachname zu ersetzen Adressen zu formatieren oder ungerade Adressen zu bereinigen, die von Legacy-Mail-Systemen erzeugt wurden.

Kanonische Zuordnungstabellen

Wenn Sie kanonische Mapping-Tabellen verwenden, müssen diese im ersten Abschnitt des Canonical Mapping angegeben werden Modul. Nachdem Sie sie definiert haben, können Sie sie im zweiten Abschnitt des Moduls bearbeiten.

Adresszuordnungs-Nachschlagetabellen: Diese Option gibt den Speicherort der optionalen kanonischen Adresszuordnungstabellendatei an. Diese Zuordnung wird sowohl in Umschlägen als auch in Kopfzeilen sowohl auf Absender- als auch auf Empfängeradressen angewendet. Diese Option konfiguriert die canonical_maps Direktive und ist standardmäßig deaktiviert. Much like the aliases files discussed in the last section, canonical mapping files are specified by a database type and a filename. The accepted database types depend on your operating system, and installed components. Usually hash and dbm are used as the database type. A common choice for this value, then, might be hash:/etc/postfix/canonical .
Tables for RECIPIENT addresses: This parameter configures address mapping only on recipient addresses, and not sender addresses. Mapping is performed on both envelopes and headers. These lookups are performed before the above configured Address mapping lookup tables . This option correlates to the recipient_canonical_maps directive and is disabled by default.
Tables for SENDER addresses: Similar to the previous option, this configures mapping for sender addresses only, and not recipient addresses. Both envelope and header information is modified. This option correlates to the sender_canonical_maps directive and by default is disabled.

Editing Canonical Mappings

Once a filename is selected for any of the canonical mapping tables, it may be edited by clicking the appropriate Edit... buttons. A new page will open, listing any existing mappings and allowing creation of new mappings. The format of mappings in all files is the same.

Canonical mappings may seem, on the surface, to be similar to aliases or virtual domains. However, they are quite distinct and are useful for other purposes. While aliases merely make a decision about which user will receive an email, and virtual domains only impact the envelope address, the canonical mapping alters both the envelope address and the SMTP header address. This change can be used to make mail appear to come from a different user or domain, or direct mail to a different user or domain by changing the address on the message.

For example, if I have a number of local subdomains, but would like all mail to appear to originate from a single domain, it is possible to create a canonical mapping to make the translations. In the Edit a Map page, the Name will be a subdomain that is to be mapped to the domain, such as @lab.swelltech.com . The Mapts to... value will simply be the domain I'd like this subdomain converted to, @swelltech.com . After saving the mapping and applying changes, all outgoing mail from lab.swelltech.com will appear to originate from swelltech.com .

Virtual Domains

Virtual domains functionality in Postfix provides a means to redirect messages to different locations by altering the message envelope address. The header address is not altered by a virtual domain mapping. While some functionality of virtual domains overlaps with features available in aliases, virtual domains can be used for local or non-local addresses, while aliases can only be used for local address.

Domain mapping lookup tables: Much like aliases tables and canonical mapping tables discussed in the previous sections, this is simply the path to a file containing the mapping tables for virtual domains. This is usually something along the lines of hash:/etc/postfix/virtual , and must be converted to a database format for use in Postfix. Webmin will perform the database generation step for you.

Transport Mapping

The term transport refers to the mechanism used to deliver a piece of email. Specifically, SMTP and UUCP are mail transports that are supported by Postfix. Transport mapping can be used for a number of purposes, including SMTP to UUCP gatewaying, operating Postfix on a firewall with forwarding to an internal mail server, etc.

Transport mapping lookup tables: This option configures the path to a file containing one or more transport mappings. These tables are much like the mapping tables discussed already, and are converted to a database and used by Postfix in the same way. This option correlates to the transport_maps directive. This feature is disabled by default. A common value for this option is /etc/postfix/transport .

To create a new mapping, first define the mapping file. Then click Add a mapping . If your goal is to redirect mail to an protected internal host from Postfix running on a firewall, for example, you could enter the outside domain name into the Name field, swelltech.com and then enter into the Maps to... field the address of the internal machine, smtp:privatehost.swelltech.com . To further improve upon this, local delivery on this machine could be disabled, and increased controls over where and to whom mail should be accepted. There are more examples of such a configuration in the tutorial section of this chapter.

Relocated Mapping

Using this option it is possible to notify senders if a local user has moved to another address. For example, if a user leaves an organization but still receives occasional mail at her local address, it may be convenient to notify anyone sending mail to the user of the move and new contact information for that user. Usage is just like the previous types of mappings and so won't be documented specifically here, though and example of a relocated mapping will be given to display the types of information that can be provided by this feature.

As an example, let's say I move from my current company to the far more relaxed atmosphere of the Oval Office. To make sure all of my friends and clients can keep in touch with me, I could provide a relocated mapping with a Name of [email protected] with a Maps to... of [email protected] . While this won't redirect mail to me at my new home, it will notify the people trying to contact me that I've changed email addresses. Hopefully they will all update their address books and resend their mail to my new address.

Local delivery

Local delivery is what Postfix does when it reaches the end of all of its list of mappings and access controls, and still finds that the message is allowed and destined for a user on the local machine (i.e., a mapping could potentially send the message elsewhere for final delivery, so all mappings as well as various access checks are performed before reaching this stage). This page configures a number of options relating to how Postfix handles the delivery of mail for local users.

Local Delivery

Name of the transport for local deliveries: This configures the name of the transport that will be used for delivery to destination that match the $mydestination or $inet_interfaces variables. This can be a simple mailbox drop handled by the Postfix local delivery agent, or any appropriate delivery command. This option correlates to the local_transport directive and defaults to the defined transport type named local .
Shell to use for delivery to external command: If a command shell is required to communicate properly with your chosen local delivery transport, this option selects the shell that will be used. By default no shell is used, and the transport command will be executed directly. However, if the command contains shell meta-characters or shell built-in commands they will be passed to /bin/sh or whatever shell you configure here. A popular choice for this is smrsh , or Sendmail's Restricted Shell , which is included in recent Sendmail distributions. smrsh allows for more precise control over what commands users can execute from their .forward Dateien. This option corresponds to the local_command_shell and defaults to /bin/sh .
Search list for forward: This is a comma-separated list of possible locations for user forward files. Postfix will try each entry in the list until a forward file is found, or until all have been checked and no match is found. The forward file allows users to configure delivery options for themselves, including delivery-time processing by a program like procmail as well as forwarding of messages to a different server. A number of variable expansions are performed on the entries. The expansions are currently:

Forward search path variable expansions

$user: The user name of the recipient.
$shell: The shell of the recipient.
$home: Recipient's home directory.
$recipient: The full recipient address.
$extensions: Recipient address extensions. This is a separate part of the email address, separated by the Separator between user names and address extensions defined on the General Options page.
$domain: The recipient's domain name.
$local: The entire local part of the recipient address.
$recipient_delimiter: The separation delimiter for the recipient.

Valid mail delivery to external commands: This parameter restricts mail delivery to only those commands specified here. The default is to disallow delivery to commands specified in :include: files, and allow execution of commands in alias and forward Dateien. This option correlates to the allow_mail_to_command directive.
Valid mail delivery to external files: This option restricts mail delivery to external files. The default is to disallow delivery to files specified in :include: but to allow delivery to files specified in aliases and forward Dateien. This option correlates to the allow_mail_to_files directive.
Default rights of the local delivery agent: This option configures the privileges that the delivery agent will have for delivery to a file or a command. This option should never be a privileged user or the postfix owner. This option corresponds to the default_privs directive and defaults to nobody .
Pathname of user mailbox file: When delivering mail locally, Postfix will drop mail in the directory configured here, or in its default mail spool directory. If you wish to use the maildir format for mail storage, this value can be appended with a trailing slash. For example, to store mail in the users home directory in the Maildir subdirectory, the value would be Maildir/ . This option correlates to the home_mailbox directive and usually defaults to some location under /var/spool/mail or /var/spool/postfix .
Destination address for unknown recipients: If a message is received for a recipient that does not exist, the message is normally bounced. However, it is possible to instead have the message delivered to an alternate address. This option corresponds to the luser_relay directive. Variable expansions matching those discussed for the Search list for forward are also valid for this directive.
Spool directory: This option specifies the directory where UNIX-style mailboxes are stored. Defaults vary depending on OS variant and version, but a common choice is /var/spool/mail . This option correlates to the mail_spool_directory option.
External command to use instead of mailbox delivery: This option defines a command to use for delivery instead of delivering straight to the users mailbox. The command will be run as the recipient of the message with appropriate HOME , SHELL and LOGNAME environment variables set. This option is commonly used to set up system-wide usage of procmail. Beware that if you use a command to deliver mail to all users, you must configure an alias for root , as the command will be executed with the permissions of the $default_user . This option correlates to the mailbox_command directive and is disabled by default.
Optional actual transport to use: This option configures the message transport to use for all local users, whether they are in the UNIX passwd database or not. If provided, the value will override all other forms of local delivery, including Destination address for unknown recipients . This option corresponds to the mailbox_transport directive and is disabled by default. This option may be useful in some environments, for example, to delegate all delivery to an agent like the cyrus IMAPD.
Optional transport for unknown recipients: If a user cannot be found in the UNIX passwd database, and no alias matches the name, the message will ordinarily be bounced, or handled via the Destination address for unknown recipients Möglichkeit. However, if you would like unknown users to be handled by a separate transport method. This option overrides the Destination address for unknown recipients option above. This option correlates to the fallback_transport directive and is disabled by default.
Max number of parallel deliveries to the same local recipient: This option limits the number of simultaneous deliveries to a single local recipient. If .forward files are allowed for users, a user may run a time-consuming command or shell script, leading to overload caused by several such processes being started up at once. This option correlates to the local_destination_concurrency_limit directive and the default is 2 . A low value is recommended for this option, unless it is certain that no complex .forward files will be in use.
Max number of recipients per local message delivery: This option configures the maximum number of recipients per local message delivery. This option correlates to the local_destination_recipient_limit and is set to the value of Max number of recipients per message delivery by default.
Prepend a Delivered-To: when...; This parameter determines when Postfix should insert a Delivered-to: message header. By default Postfix inserts this header when forwarding mail and when delivering to a file. The defaults are recommended, and it is generally preferable not to disable insertion into forwarded mail. This option corresponds to the prepend_delivered_header directive.

General resource control

This page provides access to the various memory and process limits for the Postfix processes ([ch10.html#figpfgeneralresource Figure 10.6, General resource control]. It is rarely necessary to alter the values on this page, except for highly loaded servers or very low resource machines.

General resource control

Max size of bounced message: This option limits the amount of the original message content in bytes that will be sent in a bounce notification. This option correlates to bounce_size_limit and defaults to 50000.
Max time for delivery to external commands: When delivering mail to an external command (rather than via direct mailbox delivery), Postfix will wait this amount of time for the delivery to complete. If this value is to be set to a high limit (3600s or more) the value of Timeout for I/O on internal comm channels in General Options must also be increased. This option correlates to the command_time_limit directive and defaults to 1000s .
Max number of Postfix child processes: This option limits the number of child processes that Postfix will spawn. On high load servers the default may be too low, and may need to be raised to as much as 500 oder mehr. More likely, for most environments, 50 is more than adequate and may even be overkill. For example on dial-up, or consumer broadband serving one to ten users, a more appropriate limit might be 10 . If in doubt, leave it at its default unless it causes problems. This option correlates to the default_process_limit directive and defaults to 50 .
Max number of addresses remembered by the duplicate filter: While expanding aliases and .forward files Postfix will remember addresses that are being delivered to and attempt to prevent duplicate deliveries to the same address. This option limits the number of recipient addresses that will be remembered. It corresponds to the duplicate_filter_limit directive and defaults to 1000 . There is probably no compelling reason to increase this value.
Max attempts to acquire file lock: This option limits the number of attempts Postfix will make when attempting to obtain an exclusive lock on a mailbox or other file requiring exclusive access. It corresponds to the deliver_lock_attempts directive and defaults to 20 .
Time in seconds between file lock attempts: Postfix will wait a specified time between attempts to lock a given file, after a failed lock attempt. This option configures the deliver_lock_delay directive and defaults to 1s .
Max attempts to fork a process: If Postfix attempts to fork a new process and fails, due to errors or a lack of available resources, it will try again a specified number of times. This option correlates to the fork_attempts directive and defaults to 5 .
Time in seconds between fork attempts: Postfix will try to spawn a new process a specified time after a failed attempt. This option correlates to the fork_delay directive and defaults to 1s .
Max memory used for processing headers: This option limits the amount of memory in bytes that Postfix will use to process message headers. If a message header is too large to fit into the memory specified, the headers that do not fit into memory will be treated as part of the message body. This option correlates to the header_size_limit directive and defaults to 102400 .
Max memory used for handling input lines: This option limits the amount of memory in bytes that Postfix will use to handle input lines. And input line is any line read from an :include: or .forward Datei. In order to prevent the mail server from using excessive amounts of memory, it will break up these files into chunks of this length. This option correlates to the line_length_limit directive and defaults to 2048 .
Max size of a message: This option limits the size in bytes of a message that will be delivered, including the message envelope information. This limit should be set high enough to support any email messages your users will need to be able to send or receive. This option correlates to the message_size_limit directive and defaults to 10240000 .
Max number of messages in the active queue: This option limits the number of messages that can exist in the message queue at any given time. It correlates to the qmgr_message_active_limit directive and defaults to 10000 .
Max number of in-memory recipients: This parameter limits the number of in-memory recipient data structures. This memory contains the short-term dead list , which indicates a destination was unavailable when last contacted, among other things. This option correlates to the qmgr_message_recipient_limit directive and defaults to 1000 .
Min free space in the queue file system: Postfix will refuse mail if the filesystem on which the queue is located has less available space in bytes than the value set in this option. This option correlates to the queue_minfree directive and defaults to 0 .
Max time after which stale lock is released: This option configures how old an external lock file may be before it is forcibly removed. This option correlates to the stale_lock_time and defaults to 500s .
Time in seconds between attempts to contact a broken MDT: This option configures the time in seconds between the queue manager attempts to contact an unresponsive mail delivery transport. This option correlates to the transport_retry_time and defaults to 60s .

SMTP server options

This page configures the majority of the options that directly effect the behavior of the SMTP server portion of Postfix, specifically the portions of Postfix that impact how the server behaves towards an SMTP client that connects to the server.

SMTP greeting banner: When a client connects to an SMTP server a greeting banner will be sent to the client (note the term client in this context is not the end user, but rather the email software program that is being used to make the connection). This option configures the text that will follow the status code in the banner. It is possible to use a number of variable expansions, for example, to display the specific version of the server software, though Postfix does not include the version by default. If configuring this option to be other than the default, you must include $myhostname at the start of this line, as it allows Postfix to report and respond to a mailer loop rather than overloading the system with many multiple deliveries. This option correlates to the smtpd_banner directive and contains $myhostname ESMTP $mail_name by default.

Note:

A proposed federal law in the US would make it illegal to send unsolicited commercial email through a mail server if the server included in its SMTP greeting the words NO UCE. Since spammers are generally of a criminal mindset anyway, it is unlikely that many of them will respect the new law if it is ever passed. Nonetheless, it is worth mentioning in hopes that sometime soon, all Americans will have legal protection against the stolen resources and time that UCE represents.

Max number of recipients accepted for delivery: This option limits the number of recipients that may be specified in a single message header. It is usually rare for legitimate messages to have an extremely large number of recipients specified in a single message header, but it is often done in UCE messages. The legitimate exception is messages to a mailing list (possibly sent by mailing list software like majordomo or mailman . This option correlates to the smtpd_recipient_limit and defaults to 1000 .
Disable SMTP VRFY command: Normally, the SMTP VRFY command is used to verify the existence of a particular user. However, it is also illegitimately used by spammers to harvest live email addresses. Thus it is sometimes useful to disable this command. This option correlates to disable_vrfy_command and defaults to No .
Timeout in seconds for SMTP transactions: This option sets the timeout in seconds for a client to respond to the SMTP servers response with an SMTP request. The connection process involves the client opening a connection to the server, the server replies with a greeting, and then the client makes its request. If the client request does not come within the time specified here, the connection will be closed. This option correlates to the opts_smtpd_timeout directive and defaults to 300s .
Timeout before sending 4xx/5xx error response: When sending an error response to a client, the server will sleep a specified time. The purpose of this feature is to prevent certain buggy clients from hitting the server with repeated requests in rapid succession. This option correlates to the smtpd_error_sleep_time directive and defaults to 5s .
Error count for temporarily ignore a client: This option configures the number of errors that a client may generate before Postfix will stop responding to requests for a specified time. Some buggy mail clients may send a large number of requests, while ignoring or responding incorrectly to, the error messages that result. Postfix attempts to minimize the impact of these buggy clients on normal service. This option correlates to the smtpd_soft_error_limit and defaults to 10 .
Error count for closing connection: If the number exceeds this limit the connection will be closed. This option correlates to the smtpd_hard_error_limit and defaults to 100 .
HELO is required: Enabling this option causes Postfix to require clients to introduce themselves with a HELO header at the beginning of an SMTP session. This may prevent some UCE software packages from connecting, though it may also impact other legitimate clients from connecting. This option correlates to the smtpd_helo_required and defaults to No .
Allow untrusted routing: This option configures whether Postfix will forward messages with sender-specified routing from untrusted clients to destinations within the accepted relay domains. This feature closes a sneaky potential loophole in access controls that would normally prevent the server from being an open relay for spammers. If this behavior is allowed, a malicious user could possibly exploit a backup MX mail host into forwarding junk mail to a primary MX server which believes the mail has originated from a local address, and thus delivers it as the spammer intended. This option correlates to the allow_untrusted_routing and is disabled by default. Enabling this option should only be done with extreme caution and care to prevent turning your Postfix installation into an open relay.
Restrict ETRN command upon...: The SMTP ETRN command is a rather clumsy means for a client that is not always connected to the Internet to retrieve mail from the server. The usage of this command is rather outdated, and rarely used, as POP3 and IMAP are better suited to solve this problem in the general case. This option correlates to the smtpd_etrn_restrictions directive and the default is to allow ETRN from any host. This option accepts the following directives:check_etrn_access maptype:mapname , permit_naked_ip_address , reject_invalid_hostname , check_helo_access maptype:mapname , reject_maps_rbl , reject_unknown_client , permit_mynetworks , check_client_access , permit , reject , warn_if_reject , and reject_unauth_pipelining .

This option, as well as the following three Restrictions... options accept one or all of the following values in the text field. Each is described only once here and the specific entry will include the list of accepted directives for the option. The impact of some of these choices depends on configuration performed elsewhere, and could potentially open security holes if not configured carefully.

permit_mynetworks: Permit the message if the relevant address (sender or recipient depending on the restriction) is within the local network.
reject_unknown_client: The request will be refused is the client IP has no PTR record in the DNS. This means that a client with an IP address that cannot be resolved to a host name cannot send mail to this host.
check_client_access maptype:mapname: This option requires the inclusion of an already configured map, as discussed earlier. This will restrict based on the contents of the map, allowing only clients that are allowed by the map. The map may contain networks, parent domains, or client addresses, and Postfix will strip off unnecessary information to match the client to the level of specificity needed.
check_sender_access maptype:mapname: This will restrict based on the contents of the map, allowing only senders that are allowed by the map. The map may contain networks, parent domains, or localpart@ .
reject_maps_rbl: An RBL is a relay domain black hole list. By testing a reverse domain lookup against a name server that receives a domain black hole list transfer, the server can know if the mail was sent through a known open mail relay. There are a number of free and for-fee services providing black hole data. The largest and longest lasting is the service operated by MAPS, while two new similar services are operated by the Open Relay Database and by Distributed Sender Boycott List. All operated on the principle of allowing administrators to choose to refuse mail sent from open mail relays. If this option is listed, the client will be checked against the available RBL domains, and if any match the mail will be refused.
reject_invalid_hostname: If the client host name is invalid, due to bad syntax, the request will be rejected.
permit_naked_ip_address: If the client HELO or EHLO command contains a naked IP address without the enclosing [] brackets as require by the mail RFC, the message will be rejected. Beware that some popular mail clients send a HELO greeting that is broken this way.
reject_unknown_hostname: Reject the request if the host name in the client HELO command has no A or MX record in the DNS.
reject_non_fqdn_hostname: If the client host name is not in the form of a fully-qualified domain name, as required by the RFC, the message will be rejected.
check_helo_access maptype:mapname: The server will search the named access database map for the HELO host name or parent domains. If the result from the database search is REJECT or a 4xx text or 5xx text error code the message will be refused, while a response of OK or RELAY or an all numerical response the message will be permitted.
permit: This simply permits anything. Generally this will be at the end of a set of restrictions in order to allow anything that has not been explicitly prohibited.
reject: Rejects everything. This can be used at the end of a chain of restrictions to prohibit anything that has not be explicitly permitted.
warn_if_reject: This is a special option that changes the meaning of the following restriction, so that a message that would have been rejected will be logged but still accepted. This can be used for testing new rules on production mail servers without risk of denying mail due to a problem with the rules.
reject_unauth_pipelining: If the client sends commands ahead of time without first confirming that the server support SMTP command pipelining, the message will be rejected. This will prevent mail from some poorly written bulk email software that improperly uses pipelining to speed up mass deliveries.

Restrictions on client hostnames/addresses: This restriction applies to the client host name and/or address. By default, Postfix will allow connections from any host, but you may add additional restrictions using the following:reject_unknown_client , permit_mynetworks , check_client_access maptype:mapname , reject_maps_rbl , maps_rbl_reject_code , permit , reject , warn_if_reject , reject_unauth_pipelining .
Restrictions on sends in HELO commands: This option specifies additional restrictions on what information can be sent by client in the HELO and EHLO Befehle. This option correlates to the smtpd_helo_restrictions directive. By default Postfix accepts anything, and the following restrictions may be added:reject_invalid_hostname , permit_naked_ip_address , reject_unknown_hostname , reject_non_fqdn_hostname , check_helo_access maptype:mapname , reject_maps_rbl , reject_unknown_client , check_client_access maptype:mapname , permit , reject , warn_if_reject , reject_unauth_pipelining .
Restrictions on sender addresses: This option restricts what can be contained in the MAIL FROM command in a message. It may be used to prevent specific email addresses from sending mail, reject clients without a resolvable host name, etc. This option correlates to the smtpd_sender_restrictions directive and may contain any of the following restrictions:permit_mynetworks: , reject_unknown_client , reject_maps_rbl , reject_invalid_hostname , reject_unknown_hostname , reject_unknown_sender_domain , check_sender_access maptype:mapname , check_client_access maptype:mapname , check_helo_access maptype:mapname , reject_non_fqdn_hostname , reject_non_fqdn_sender , reject , permit .
Restrictions on recipient addresses: This parameter places restrictions on the recipients that can be contained in the RCPT TO command of a sent message. It can be used to dictate where email may be sent. This option correlates to the smtpd_recipient_restrictions , and may contain any of the following restrictions:permit_mynetworks , reject_unknown_client , reject_maps_rbl , reject_invalid_hostname , reject_unknown_hostname , reject_unknown_sender_domain , check_relay_domains , permit_auth_destination , reject_unauth_pipelining , permit_mx_backup , reject_unknown_recipient , check_recipient_access , check_client_access , check_helo_access , check_sender_access , reject_non_fqdn_hostname , reject_non_fqdn_sender , reject_non_fqdn_recipient , reject , permit .
DNS domains for blacklist lookups: This option configures the optional blacklist DNS servers that will be used for all RBL checks that have been specified in all access restrictions. It may contain any number of servers in a whitespace separated list. These services can be used to help prevent spam, as discussed earlier in this section, with the Restrict ETRN command upon... Parameter. This option configures the maps_rbl_domains directive and is empty, by default.
Restrict mail relaying: This option specifies from which hosts, networks, domains, etc. Postfix will relay email for. This option correlates to the relay_domains directive, and defaults to $mydestination .
SMTP server response on access map violation, SMTP server response on RBL domains violation, SMTP server response on forbidden relaying, SMTP server response on unknown client reject, SMTP server response on invalid hostname reject, SMTP server response on unknown domain reject, SMTP server response on unknown hostname reject: These options configure the error result code that will be sent to the client when any of the specified restrictions are being applied. These errors have sensible default values and generally should not need to be changed. Consult with RFC 822 if you wish to understand more about the SMTP error codes, or have a reason to change any of these values.

SMTP Client Options

The SMTP client options configures how Postfix will behave when dealing with other mail servers as a client, i.e., when sending mail on behalf of a user. This portion of the configuration primarily dictates how the server will respond to certain error conditions.

Action when listed as best MX server: As discussed in the BIND chapter, a mail server performs a name server query to find the MX, or mail server, record for the destination domain. If this record indicates that the local server is the server to which mail should be sent, it can respond in a couple of ways. The default is to bounce the message with an error indicating a mail loop. If the field is selected and local is entered, the mail will be directed to the local delivery agent instead of bouncing the mail. This option correlates to the best_mx_transport directive.
Hosts/domains to hand off mail to on invalid destination: By default, a mail that cannot be delivered because the destination is invalid will be bounced with an appropriate error message. However, it is possible to configure postfix to hand off email to another server instead. This option correlates to the fallback_relay directive.
Ignore MX lookup error: If a name server query fails to provide an MX record, the server defaults to deferring the mail and trying again later. If Yes is selected instead, an A record query will be done and an attempt will be made to deliver to the resulting address. This option correlates to the ignore_mx_lookup_error directive.
Skip 4xx greeting: If a remote server responds to a connection with a 4XX status code, postfix will, by default, select the next available mail exchanger specified by the MX records. If set to No , mail delivery will be deferred after the first mail delivery attempt and another attempt will be made later. This option correlates to the smtp_skip_4xx_greeting directive.
Skip wait for the QUIT command: This option configures whether Postfix will wait for the receiving mail server to respond to the QUIT Befehl. This option correlates to the smtp_skip_quit_response directive and defaults to no.
Max number of parallel deliveries to the same destination: This option specifies the maximum number of deliveries that Postfix will perform to the same destination simultaneously. This option correlates to the smtp_destination_concurrency_limit directive and defaults to the system-wide limit for parellel deliveries configured in the Delivery Rates page documented in the next section.
Max number of recipients per delivery: Limits the number of recipients per delivery. This option correlates to the smtp_destination_recipient_limit directive and defaults to the system-wide limit for recipients per delivery.
Timeout for completing TCP connections: Specifies the time in seconds that the Postfix delivery agent will wait before timing out a TCP connection. This option correlates to the smtp_connect_timeout directive and defaults to 0, which disables connection timeouts.
Timeout on waiting for the greeting banner: Limits how long Postfix will wait for a greeting banner to be received from the destination server. This option corresponds to the smtp_helo_timeout directive and defaults to 300 seconds.
Timeout on waiting for answer to MAIL FROM: Sets the timeout in seconds for sending the SMTP MAIL FROM command and for receiving the destination servers response. This option correlates to the smtp_mail_timeout , and defaults to 300 seconds.
Timeout on waiting for answer to RCPT TO: Sets the timeout in seconds for sending the SMTP RCPT TO command and for receiving the destination servers response. This option correlates to the smtp_rcpt_timeout directive and defaults to 300 seconds.
Timeout on waiting for answer to DATA: Sets the timeout in seconds sending the SMTP DATA command and for receiving the destination servers response. This option correlates to the smtp_data_init_timeout and defaults to 120 seconds.
Timeout on waiting for answer to transmit of message content: Specifies the SMTP client timeout in seconds for sending the contents of the message. If the connection stalls for longer than this timeout, the delivery agent will terminate to transfer. This option corresponds to the smtp_data_xfer_timeout directive and defaults to 180 seconds.
Timeout on waiting for answer to ending ".": Specifies the SMTP client timeout in seconds for sending the closing SMTP "." and receiving the destination servers reply. This option correlates to the smtp_data_done_timeout directive and defaults to 600 seconds.
Timeout on waiting for answer to QUIT: Sets the timeout in seconds sending the SMTP QUIT command and for receiving the destination servers response. This option correlates to the smtp_quit_timeout and defaults to 300 seconds

Delivery Rates

This page contains the options for setting the default rate and concurrency limits for all Postfix components. These rates can usually be overridden within their respective configuration sections.

Max number of parallel deliveries to the same destination: This option specifies the maximum number of deliveries that Postfix will perform to the same destination simultaneously. This option correlates to the default_destination_concurrency_limit directive and defaults to 10 .
Max number of recipients per message delivery: Limits the number of recipients per delivery. This option correlates to the default_destination_recipient_limit directive and defaults to 50 .
Initial concurrency level for delivery to the same destination: Specifies the initial number of simultaneous deliveries to the same destination. This limit applies to all SMTP, local, and pipe mailer deliveries. A concurrency of less than two could lead to a single problem email backing up delivery of other mail to the same destination. This option configures the initial_destination_concurrency directive and defaults to 5 .
Max time (days) in queue before message is undeliverable: Defines the number of days a message will remain queued for delivery in the event of delivery problems before the message is sent back to the sender as undeliverable. This option configures the maximal_queue_lifetime directive and defaults to 5 days.
Min time (secs) between attempts to deliver a deferred message: In the event of a delivery deferral, Postfix will wait the specified amount of time before reattempting delivery. This value also specifies the time an unreachable destination will remain in the destination status cache. This option correlates to the minimal_backoff_time directive and defaults to 1000 seconds.
Max time (secs) between attempts to deliver a deferred message: Specifies the maximum amount of time between delivery attempts in the event of a deferred delivery. This option configures the maximal_backoff_time directive and defaults to 4000 seconds.
Time (secs) between scanning the deferred queue: Specifies the time in seconds between queue scans by the queue management task. This option correlates to the queue_run_delay and defaults to 1000 seconds.
Transports that should not be delivered: This field specifies which delivery transports, if any, of the transports defined in the Transport Mapping section will not have their messages sent automatically. Instead the messages for these transports will be queued, and can be delivered manually using the sendmail -q Befehl. This option correlates to the defer_transports directive, and contains nothing by default.

Debugging features

Postfix has two levels of logging. The first level is the normal maillog , which reports on all normal mail activities such as received and sent mail, server errors, shutdowns and startups. The second level is more verbose, and can be tuned to log activity relating to specific SMTP clients, host names, or addresses. This page contains the configuration for the second level of logging.

List of domain/network patterns for which verbose log is enabled: This is a list of patterns or addresses that match the clients, hosts, or addresses whose activity you would like to have more verbose logging for. Values here could be an IP address like 192.168.1.1 or a domain name like swelltech.com . This option correlates to the debug_peer_list directive and is empty by default.
Verbose logging level when matching the above list: Specifies the level of verbosity of the logging for the activity that matches the above patterns. This option correlates to the debug_peer_level directive and defaults to 2. The above field must have at least one value for this debug level to have any impact.

Postfix, Unsolicited Commercial Email and Access Controls

Postfix offers an extremely flexible set of access controls, primarily targeted at preventing unsolicited commercial email from being delivered through the server. In order to construct a suitable set of controls it is necessary to understand the order in which rules are checked, and how they interact. By default Postfix will accept mail for delivery from or to any client on your local network and any domains that are hosted by Postfix. So, by default, Postfix is not an open relay. This is a good beginning, and may be all that is needed in many environments. However, because UCE is such a nuisance for users and network administrators, it may be worthwhile to implement more advanced filtering. This section will address the basics of the Postfix UCE control features.

Access Control List Order

Every message that enters the smtpd delivery daemon will be processed by a number of access control lists and checked against a number of rules to insure that the message is one that the administrator actually wants delivered. The goal for most administrators is to prevent unsolicited commercial email from passing through these rules, yet allow every legitimate email to be delivered. This is a lofty goal, and a delicate balance. No perfect solution exists, as long as people are willing to steal the resources of others for their own commercial gain and go to great lengths to overcome the protections in place to prevent such abuse. However, in most environments it is possible to develop a reasonable set of rules that prevents most spam and allows most or all legitimate mail through unharmed.

It is important to understand the order of processing if complex sets or rules are to be used, as attempting to use a particular rule too early in the chain can lead to subtle errors, or strange mail client behavior. Because not all clients react exactly correctly to some types of refusals, and not all clients create correctly formed SMTP requests, it is not unlikely that a misplaced rule will lock out some or all of your clients from sending legitimate mail. It could also just as easily lead to opening a hole in your spam protections early in the rule set, which would allow illicit mail to pass.

The Postfix UCE controls begin with a couple of simple yes or no checks, called smtpd_helo_required and strict_rfc821_envelopes , both configured in the SMTP Server Options Seite. The first, if enabled, requires a connecting mail client to introduce itself fully by sending a HELO command. This can stop some poorly designed bulk email programs. The second option requires for the envelope to fit the SMTP specification precisely, thus enforcing complete headers. Though the envelope and HELO can be forged by a bulk mailer, it may stop the more hastily implemented variants (well, how many good programmers do you know that write tools to help spammers?).

The next stage is the four SMTP restrictions also found on the SMTP Server Options Seite. These further limit from where and to where mail will be delivered. The order of traversal for these four lists of rules is:

Restrictions on client hostnames/addresses or smtpd_client_restrictions
Restrictions on sends in HELO commands or smtpd_helo_restrictions
Restrictions on sender addresses or smtpd_sender_restrictions
Restrictions on recipient addresses or smtpd_recipient_restrictions

Each of these checks can return REJECT , OK , or DUNNO . If REJECT , the message will be refused, and no further rules will be checked. If OK , no further rules in the given restriction will be checked, and the next restriction list will be checked. If DUNNO , the list will continue to process the current restriction until it gets another result (OK or REJECT ) or until the list end is reached, which is an implicit OK . If all lists return OK , the message will be passed to the regular expressions checks, otherwise it will be rejected.

Next come the regular expression-based header_checks and body_checks . These options, if enabled, provide a means to test the actual contents of the headers and the body of the email, respectively. Both operate in the same way, though they should be used somewhat differently. Header checks can be used to prevent well-known spamming domains from sending you email, or for stopping some well-known bulk-mailer software. By entering some signature of the offender, like the domain name, or the X-mailer field identifying the software, the mail can be rejected before the body is even sent. Body checks, though the use the same regular expressions and file format as header checks, should be used more sparingly, as the mail must be accepted before it can be checked. Thus bandwidth is wasted on receipt of the mail, and worse, the server will be occupied for a potentially long while with processing the entire contents of every email. In short, use header checks whenever is convenient, and use body checks only when an effective header check cannot be devised. Only REJECT or OK are permitted for the returned values.

Siehe auch

Postfix Basic Configuration
Postfix Virtual Hosting