Architektur
Einführung
- Dieses Dokument gibt einen Überblick über die Postfix-Architektur, und bietet Verweise auf Beschreibungen aller Postfix-Befehle oder Serverprogramm.
- Der Text gibt den allgemeinen Kontext an, in dem jeder Befehl oder jedes Serverprogramm wird verwendet und liefert Zeiger darauf Dokumente mit konkreten Anwendungsbeispielen und Hintergrundinformationen.
- Modulare Postfix Architektur
- Daemon
Gelbe Ellipsen:
- Sie stehen für je einen Daemon, welchem genau eine Aufgabe zugeordnet wurde.
- Aus dieser Modularität heraus erklärt sich die große Sicherheit und Stabilität, die Postfix auszeichnet.
- Lookup tables
Blaue Kästen:
- Die blauen Kästen stehen für sogenannte Lookup tables (postfix maps).
- Sie enthalten in zwei Spalten Informationen, die zur Weiterverarbeitung von E-Mails herangezogen werden können.
- Dies kann eine Zugriffsliste (engl. access) sein, die darüber bestimmt, ob die E-Mail angenommen wird oder nicht, zum Umschreiben des Adressaten bzw. Senders oder auch der weitere Weg (engl. transport), den eine E-Mail nehmen soll.
- queues
Orangene Kästen:
- Die orangenen Kästen stehen zum einen für sogenannte Warteschlangen (engl. queues),
- bei der E-Mails physisch auf dem Datenträger (zumeist Festplatte oder einem NFS Laufwerk) abgelegt werden, oder aber für Endzustellung,
- zum Beispiel eine Mailbox eines Benutzers (Beispiel: /var/mail/benutzername).
- Eingänge/Ausgänge
Weiße Wolken:
- Sie stehen für den möglichen Eintritt oder auch das Verlassen des Postfix Systems.
- Als Beispiel auf der linken Seiten den SMTPD Daemon, welcher für die Annahme von E-Mails über den TCP Port 25 zuständig ist (soweit nicht anders konfiguriert).
- Auf der rechten Seite dagegen gibt es den SMTP Daemon, der für das Weitergeben von E-Mails an andere SMTP zuständig ist.
Alle Daemonen (gelbe Ellipsen) werden vom Postfix Master Prozess bei Bedarf gestartet und auch überwacht.
Postfix Architektur
Wie Postfix Mail empfängt
Wenn eine Nachricht in das Postfix-Mailsystem eingeht, ist die erste Station Auf der Innenseite befindet sich die Eingangswarteschlange . Die folgende Abbildung zeigt die Hauptprozesse, die mit neuer E-Mail verbunden sind. Namen gefolgt von eine Nummer sind Postfix-Befehle oder Serverprogramme, während sie nicht nummeriert sind Namen in schattierten Bereichen stehen für Postfix-Warteschlangen.
- Netzwerk-Mail gelangt über smtpd(8) oder qmqpd(8) Server. Diese Server entfernen die SMTP- oder QMQP-Protokollkapselung, Führen Sie einige Plausibilitätsprüfungen durch, um Postfix zu schützen, und geben Sie dem Absender, Empfänger und Nachrichteninhalt an den Cleanup(8) -Server. Das Der smtpd(8) -Server kann so konfiguriert werden, dass er unerwünschte E-Mails blockiert, wie z im SMTPD_ACCESS_README .
- Lokale Einreichungen werden mit dem Postfix sendmail(1) Kompatibilitätsbefehl und werden Maildrop-Warteschlange von den privilegierten postdrop(1) -Befehl. Diese Anordnung funktioniert sogar während das Mailsystem Postfix nicht läuft. Die Abholung vor Ort(8) Der Server nimmt lokale Übermittlungen auf und führt einige Plausibilitätsprüfungen durch schützt Postfix und gibt Absender, Empfänger und Nachricht an Inhalt auf den Cleanup(8) -Server.
- Mail aus internen Quellen wird direkt an die weitergeleitet cleanup(8) -Server. Diese Quellen sind in der Figur nicht gezeigt, und umfassen: Post, die vom lokalen(8) Zustellagenten weitergeleitet wird (siehe nächsten Abschnitt), Nachrichten, die von der an den Absender zurückgesendet werden Bounce(8) -Server (siehe vornächster Abschnitt) und Postmaster Benachrichtigungen über Probleme mit Postfix.
- Der cleanup(8) -Server implementiert die endgültige Verarbeitung Phase, bevor E-Mails in die Warteschlange gestellt werden. Es fügt fehlendes From: und andere Nachrichten hinzu Header und transformiert Adressen wie in beschrieben ADDRESS_REWRITING_README dokumentieren. Optional kann der cleanup(8) -Server so konfiguriert werden Führen Sie eine leichte Inhaltsprüfung mit regulären Ausdrücken durch im BUILTIN_FILTER_README . Die Reinigung(8) Server stellt das Ergebnis als einzelne Datei in die Eingangswarteschlange , und benachrichtigt den Warteschlangenmanager (siehe nächster Abschnitt) über die Ankunft von neuer Post.
- Der trivial-rewrite(8) -Server schreibt Adressen in die um Standardformular "user@fully.qualified.domain", wie in beschrieben ADDRESS_REWRITING_README- Dokument. Postfix derzeit nicht Implementieren Sie eine Umschreibesprache, aber vieles kann über Tabellen erledigt werden Lookups und ggf. reguläre Ausdrücke.
Wie Postfix E-Mails zustellt
Sobald eine Nachricht die Eingangswarteschlange der nächste Schritt um es zu liefern. Die Abbildung zeigt die Hauptkomponenten von Postfix Geräte zur Postzustellung. Namen gefolgt von einer Nummer sind Postfix Befehle oder Serverprogramme, während nicht nummerierte Namen innen schattiert sind Bereiche stellen Postfix-Warteschlangen dar.
- Der Warteschlangenmanager (der Serverprozess qmgr(8) in der Abbildung) ist das Herzstück der Mail-Zustellung von Postfix. Es kontaktiert die smtp(8) , lmtp(8) , local(8) , virtual(8) , pipe(8) , discard(8) or error(8) Zusteller und sendet eine Zustellanforderung für einen oder mehr Empfängeradressen. Die Discard(8)- und Error(8) -Zustellung Agenten sind etwas Besonderes: Sie verwerfen oder senden alle E-Mails zurück und sind es nicht in der Abbildung oben gezeigt.
Der Warteschlangenmanager verwaltet eine kleine aktive Warteschlange mit der Nachrichten, die für die Zustellung geöffnet wurden. Die aktive Warteschlange fungiert als ein begrenztes Fenster für potenziell große eingehende oder zurückgestellte Warteschlangen . Die eingeschränkte aktive Warteschlange verhindert die Ausführung des Warteschlangenmanagers aus Speicher unter hoher Last.
Der Warteschlangenmanager verwaltet eine separate zurückgestellte Warteschlange für Mail die nicht zugestellt werden können, so dass ein großer Mail-Rückstau nicht auftritt normale Warteschlangenzugriffe verlangsamen. Die Strategie des Warteschlangenmanagers für verzögerte E-Mail-Zustellversuche sind in QSHAPE_README und TUNING_README- Dokumente.
- Der trivial-rewrite(8) -Server löst jeden Empfänger auf Adresse gemäß ihrer lokalen oder entfernten Adressklasse, wie definiert im ADDRESS_CLASS_README . Zusätzliche Routing-Informationen kann mit der optionalen transport(5) Tabelle Das trivial-rewrite(8) -Server fragt optional die relocated(5) -Tabelle ab für Empfänger, deren Adresse sich geändert hat; Mail für solche Empfänger ist mit einer Erklärung an den Absender zurückgeschickt.
- Der smtp(8) -Client sucht nach einer Liste von Mail-Exchangern dem Zielhost, sortiert die Liste nach Präferenz und versucht es mit jedem Server der Reihe nach, bis er einen Server findet, der antwortet. Es dann kapselt den Absender, den Empfänger und den Nachrichteninhalt nach Bedarf durch das SMTP-Protokoll; dies beinhaltet die Umwandlung von 8-Bit-MIME in 7-Bit-Codierung.
- Der lmtp(8) -Client spricht ein dem SMTP ähnliches Protokoll ist für die Zustellung an Postfachserver wie Cyrus optimiert. Das Vorteil dieser Einrichtung ist, dass eine Postfix-Maschine mehrere füttern kann Postfachserver über LMTP. Das Gegenteil gilt auch: Eins Mailbox-Server kann über LMTP von mehreren Postfix-Rechnern gespeist werden.
- Der local(8) Zustellungsagent qmail-kompatible maildir-Dateien, systemweite Aliase im Sendmail-Stil(5) Datenbanken und benutzerspezifische .forward-Dateien im Sendmail-Stil. Mehrere lokale Delivery Agents können parallel betrieben werden, aber Parallel Delivery auf denselben Benutzer beschränkt ist.
Der örtliche (8) Lieferdienst hat Haken für alternative Formen von lokale Zustellung: Sie können es so konfigurieren, dass es an Postfachdateien zugestellt wird in Benutzerstammverzeichnissen können Sie es so konfigurieren, dass es das Postfach delegiert Übermittlung an einen externen Befehl wie procmail, oder Sie können delegieren Zustellung an einen anderen Postfix-Zusteller.
- Der virtual(8) -Zustellungsagent ist eine Bare-Bones-Zustellung Agent, der an eine Mailbox im UNIX-Stil oder ein maildir im Stil von qmail liefert nur Dateien. Dieser Zustellagent kann Post für mehrere zustellen Domains, was es besonders geeignet macht, viele zu hosten kleine Domänen auf einer einzelnen Maschine. Dies ist in der beschrieben VIRTUAL_README- Dokument.
- Der Pipe(8) -Mailer ist die ausgehende Schnittstelle zu anderer Mail Verarbeitungssysteme (der Postfix- sendmail(1) Befehl eingehende Schnittstelle). Die Schnittstelle ist UNIX-kompatibel: Sie bietet Informationen auf der Kommandozeile und im Standard-Eingabestrom, und erwartet einen Prozess-Exit-Statuscode wie in <sysexits.h> definiert. Beispiele für die Zustellung über den Pipe(8) -Mailer finden Sie in der MAILDROP_README und UUCP_README- Dokumente.
Postfix hinter den Kulissen
Die vorherigen Abschnitte gaben einen Überblick darüber, wie Postfix-Server verarbeitet das Senden und Empfangen von E-Mails. Diese Serverprozesse verlassen sich auf andere Serverprozesse, die Dinge hinter den Kulissen tun. Der Text Im Folgenden wird versucht, jeden Dienst in seinem eigenen Kontext zu visualisieren. Wie Davor sind Namen gefolgt von einer Zahl Postfix-Befehle oder Server Programme, während nicht nummerierte Namen innerhalb schattierter Bereiche darstellen Postfix-Warteschlangen. * Der residente Master(8) -Server ist der Supervisor, der behält ein Auge auf das Wohlergehen des Mailsystems Postfix. Es ist typisch beim Systemstart mit dem Befehl "postfix start" gestartet und läuft weiter, bis das System ausfällt. Der Master(8) -Server ist verantwortlich für das Starten von Postfix-Serverprozessen zum Empfangen und E-Mail-Zustellung und für den Neustart von Servern, die vorzeitig beendet werden wegen irgendwelchen problemen. Der Master(8) -Server ist ebenfalls verantwortlich zum Durchsetzen der Serverprozess-Zählerlimits, wie in der angegeben master.cf Konfigurationsdatei Das Bild unten gibt die Programmhierarchie beim Start von Postfix. Nur ein Teil der Post Verarbeitung von Daemon-Prozessen werden angezeigt.
- Der anvil(8) -Server implementiert die Client-Verbindung und Anforderungsrate Begrenzung für alle smtpd(8) -Server. Das TUNING_README Dokument bietet Anleitungen zum Umgang mit fehlerhaften SMTP-Clients. Das anvil(8) ist in Postfix Version 2.2 und höher verfügbar.
- Die bounce(8) , defer(8) und trace(8) werden jeweils verwaltet ihre eigenen Warteschlangen-Verzeichnisbäume mit Protokolldateien pro Nachricht. Postfix verwendet diese Informationen beim Senden von „fehlgeschlagen“, „verzögert“ oder „erfolgreich“ Benachrichtigungen über den Zustellstatus an den Absender.
Der Trace(8) -Dienst implementiert auch die Unterstützung für Postfix "Mail senden -bv" und "sendmail -v" Befehle, die Berichte darüber erzeugen, wie Postfix liefert Mail und ist mit Postfix Version 2.1 verfügbar und später. Siehe DEBUG_README zum Beispiel.
- Die flush(8) -Server führen Protokolle pro Ziel und Implementieren Sie sowohl ETRN als auch "sendmail -qRdestination", wie beschrieben im ETRN_README . Dies verschiebt ausgewählte Warteschlangendateien aus die Warteschlange zurück zur eingehenden Warteschlange und fordert deren Lieferung. Der flush(8) -Dienst ist mit der Postfix-Version verfügbar 1.0 und höher.
- Die Proxymap(8) -Server bieten Read-Only und Read-Write Tabellensuche Dienst für Postfix-Prozesse. Dies überwindet Chroot-Einschränkungen, reduziert die Anzahl der offenen Nachschlagetabellen, indem eine geöffnete gemeinsam genutzt wird Tabelle zwischen mehreren Prozessen und implementiert Single-Updater Tische.
- Der scache(8) -Server verwaltet den Verbindungs-Cache für der Postfix smtp(8) -Client. Wenn Verbindungscaching aktiviert ist für ausgewählten Zielen, trennt der SMTP(8) -Client die Verbindung nicht unmittelbar nach einer Mail-Transaktion, sondern gibt die Verbindung zu der Verbindungs-Cache-Server, der die Verbindung offen hält für a begrenzte Zeit. Der smtp(8) -Client fährt mit einigen fort andere E-Mail-Zustellungsanforderung. Inzwischen kann das jeder smtp(8) -Prozess Fragen Sie den scache(8) -Server nach dieser zwischengespeicherten Verbindung und verwenden Sie sie für die Postzustellung. Als Sicherheitsmaßnahme begrenzt Postfix die Anzahl wie oft eine Verbindung wiederverwendet werden kann.
Beim Zustellen von E-Mails an ein Ziel mit mehreren E-Mail-Servern Verbindungs-Caching kann helfen, einen nicht antwortenden Server zu überspringen, und damit die Lieferung drastisch beschleunigen. Zwischenspeichern von SMTP-Verbindungen ist in Postfix-Version 2.2 und höher verfügbar. Mehr Informationen zu dieser Funktion finden Sie im CONNECTION_CACHE_README .
Ein Postfix smtp(8) -Client kann eine TLS-verschlüsselte Verbindung wiederverwenden (mit " smtp_tls_connection_reuse = yes"). Dies kann stark reduzieren den Overhead des Verbindungsaufbaus und verbessert die Nachrichtenübermittlung Preise. Nachdem ein Postfix smtp(8) -Client eine Verbindung zu einem entfernten SMTP herstellt server und sendet Klartext-EHLO- und STARTTLS-Befehle, die smtp(8) Client fügt wie gezeigt einen tlsproxy(8) -Prozess in die Verbindung ein unter.
Nachdem die E-Mail-Transaktion abgeschlossen ist, wird der Postfix- smtp(8) -Client gibt die smtp(8) -to -tlsproxy(8) -Verbindung zum scache(8) Server, der die Verbindung für eine begrenzte Anzahl offen hält Zeit. Der smtp(8) -Client fährt mit einer anderen Mail-Zustellung fort Anfrage. Inzwischen kann jeder Postfix smtp(8) -Client den scache(8) Server für diese zwischengespeicherte Verbindung und verwenden Sie sie für die E-Mail-Zustellung erneut.
- Die spawn(8) -Server führen auf Anfrage Nicht-Postfix-Befehle aus, mit dem Client, der über Socket oder FIFO mit dem Befehl verbunden ist Standard-Eingabe-, Ausgabe- und Fehlerströme. Sie finden Beispiele für seine Verwendung im SMTPD_POLICY_README .
- Der tlsmgr(8) -Server wird ausgeführt, wenn TLS (Transport Layer Sicherheit, früher bekannt als SSL) ist in Postfix smtp(8) aktiviert Client oder smtpd(8) -Server. Dieser Prozess hat zwei Aufgaben:
- Pflegen Sie den Pseudo-Zufallszahlengenerator (PRNG). wird verwendet, um die TLS-Engines im Postfix smtp(8) -Client oder smtpd(8) Serverprozesse. Der Zustand dieses PRNG wird periodisch gespeichert eine Datei und wird gelesen, wenn tlsmgr(8) startet.
- Pflegen Sie den optionalen Postfix smtp(8) -Client oder smtpd(8) Server-Caches mit TLS-Sitzungsschlüsseln. Gespeicherte Schlüssel können sich verbessern Leistung durch Reduzierung der Berechnungsmenge zu Beginn von eine TLS-Sitzung.
TLS-Unterstützung ist in Postfix Version 2.2 und höher verfügbar. Informationen zur Postfix-TLS-Implementierung finden Sie in TLS_README dokumentieren.
Netzwerk ->
|
smtpd(8)
|
<---Samen--- <-Sitzung->
|
tlsmgr(8)
|
---Samen---> <-Sitzung->
|
SMTP(8)
|
-> Netzwerk
|
|
|
| |
|
|
|
|
|
smtpd Sitzung Zwischenspeicher
|
|
PRNG Zustand Datei
|
|
smtp Sitzung Zwischenspeicher
|
|
|
- Der verify(8) -Server überprüft, ob es sich um einen Absender oder Empfänger handelt Adresse zustellbar ist, bevor der smtpd(8) -Server sie akzeptiert. Das Der verify(8) -Server fragt einen Cache mit den Ergebnissen der Adressüberprüfung ab. Wenn kein Ergebnis gefunden wird, fügt der verify(8) -Server eine Sonde ein Nachricht in die Postfix-Queue und verarbeitet die Statusaktualisierung ab ein Zustellungsagent oder Warteschlangenmanager. Dieser Vorgang ist in der ADDRESS_VERIFICATION_README dokumentieren. Der Verify(8) -Dienst ist mit der Postfix-Version verfügbar 2.1 und höher.
|
->
|
Sonde Botschaft
|
->
|
Postfix Post Warteschlange
|
|
|
|
|
Netzwerk
|
->
|
smtpd(8)
|
<->
|
verifizieren(8)
|
|
|
|
| in
|
|
|
<-
|
Sonde Status
|
<-
|
Postfix Lieferung Agenten
|
-> Lokal -> Netzwerk
|
|
|
^ | in
|
|
|
|
|
|
Adresse Überprüfung Zwischenspeicher
|
|
- Der postscreen(8) -Server kann Postfix "vor" gestellt werden smtpd(8) -Prozesse. Sein Zweck ist es, Verbindungen von der zu akzeptieren Netzwerk und um zu entscheiden, mit welchen SMTP-Clients kommuniziert werden darf Postfix. Laut dem Jahresbericht 2008 von MessageLabs sind 81 % der alle E-Mails waren Spam und 90 % davon wurden von Botnets gesendet; bis 2010, diese Zahlen waren 92 % bzw. 95 %. Während Postscreen(8) hält die Zombies fern, es bleiben mehr smtpd(8) -Prozesse verfügbar für seriöse Kunden.
postscreen(8) verwaltet eine temporäre Zulassungsliste für Clients, die seine Tests bestehen; indem zugelassenen Clients erlaubt wird, Tests zu überspringen, postscreen(8) minimiert seine Auswirkungen auf den legitimen E-Mail-Verkehr.
Der postscreen(8) -Server ist mit Postfix 2.8 und verfügbar später. Um die Implementierung einfach zu halten, postscreen(8) -Delegates DNS Allow/Denylist-Lookups für dnsblog(8)-Serverprozesse und delegiert die TLS-Verschlüsselung/Entschlüsselung an tlsproxy(8)-Serverprozesse . Diese Delegierung ist für den Remote-SMTP-Client unsichtbar.
- Der postlogd(8) -Server bietet eine Alternative zu Syslog Protokollierung, die die Standardeinstellung bleibt. Diese Funktion ist verfügbar mit Postfix Version 3.4 oder höher und unterstützt die folgenden Modi:
- Protokollierung in Datei, die ein Usability-Problem mit adressiert MacOS und eliminiert Informationsverluste, die durch systemd-Ratenbegrenzungen verursacht werden.
- Protokollierung auf stdout, wodurch eine Syslog-Abhängigkeit beseitigt wird wenn Postfix in einem Container läuft.
Befehle oder Dämonen
|
|
stdout geerbt von "postfix start-fg"
|
->
|
postlogd(8)
|
->
|
|
Siehe MAILLOG_README für Details und Einschränkungen.