Postfix

zurück zu Meine Bücher || Computer und Internet || Administration und Open Source Software


Buchregalnummer: Lh4B1


postfixUntertitel: Einrichtung, Betrieb und Wartung
Autoren: Ralf Hildebrandt Patrick B. Koetter
Verlag: dpunkt.verlag
ISBN: 3-89864-518-8
2. Auflage 2008

Postfix zeigt Anfängern und Fortgeschrittenen, wie sie Postfix installieren, einrichten und so konfigurieren, dass Sie einen verlässlichen und sicheren E-Mail-Server betreiben können. Die Kapitel sind praxisnah aufgebaut und behandeln typische Szenarien wie beispielsweise Anti-Spam- und Anti-Viren-Schutz, Mailserver für mehrere Domains, SMTP-Authentifizierung und verschlüsselte Kommunikation mit TLS.

Inhaltsverzeichnis zitiert aus Das Postfix-Buch:
„Einführung in Postfix
Das erste Kapitel führt Sie in das Themenfeld Mailserver und speziell Postfix ein. Es zeigt Ihnen, warum wir glauben, dass Postfix heute der beste Mailserver ist, der auf dem freien Markt zu haben ist.

SMTP-Kommunikation im Überblick
Mit wenigen Ausnahmen, und das sind nur unbestätigte Gerüchte, hat keiner die Kommandos des SMTP-Protokolls mit der Muttermilch auf den Weg bekommen. In Kap. 2 legen wir den Grundstein für das Verständnis von Postfix und das erfolgreiche Testen von Konfigurationen.

Systemvorbereitung
Ein Mailserver stellt bestimmte Anforderungen an das Netzwerk, in dem er betrieben wird, und an das Betriebssystem, auf dem er installiert wird. Kap. 3 zeigt Ihnen, welche Anforderungen vorausgesetzt werden und wie Sie diese erfüllen können.

Mailserver für eine Domain einrichten
Jede zuverlässige Postfix-Konfiguration beginnt mit dem Einrichten einer »Single-Domain«-Konfiguration. Die in Kap. 4 beschriebene Vorgehensweise zeigt Ihnen, wie Sie dieses Ziel erreichen und sicherstellen können, damit Sie von dort aus auch komplexere Vorhaben realisieren können.

Mailserver als Einwahlserver einrichten
Vom »Single-Domain«-Server zum kostensparenden Einwahlserver ist es nur ein Katzensprung. Kap. 5 zeigt die wenigen und doch wichtigen Veränderungen, die dieses Szenario erfordert.

Aufbau und Architektur von Postfix
Wietse Venema sagt: »In Wirklichkeit ist Postfix ein Router«, einer der ganze Nachrichten anstatt einzelner IP-Pakete routet. In Kap. 6 setzen wir uns detailliert mit dieser Systemmetapher auseinander und zeigen Ihnen, wie das Zusammenspiel der einzelnen Bestandteile von Postfix funktioniert.

Das Postmaster-E-Mail-Einmaleins
Inhaltskontrolle setzt Wissen über die SMTP-Kommunikation und den möglichen Inhalt einer E-Mail voraus. Nur wenn Sie wissen, was in einer E-Mail enthalten sein muss, soll oder darf, können Sie Kriterien festlegen, die darüber befinden werden, ob eine Nachricht versendet oder empfangen wird. In Kap. 7 werden wir uns diesem Thema ausführlich widmen.

Wie interne Message Transfer Restrictions funktionieren
Die Gruppe der restrictions-Parameter kontrolliert die SMTP-Kommunikation. In Kap. 8 werden wir uns damit befassen, wie restrictions funktionieren. Nehmen Sie sich beim Lesen Zeit und lassen Sie das Gelesene eine Weile wirken; das Implementieren von restrictions wird Ihnen danach viel leichter fallen.

Interne Message Transfer Restrictions anwenden
In Kap. 9 zeigen wir, wie Sie restrictions implementieren. Alle Beispiele können Sie im Alltag anwenden.

Externe Message Transfer Restrictions
In Kap. 10 zeigen wir Ihnen, wie Postfix Entscheidungen auf Basis der SMTP-Kommunikation über eine neue Plug-in-Schnittstelle namens Policy an externe Programme übergeben kann.

Wie interne Content-Filter funktionieren
Die Gruppe der checks-Parameter funktioniert durch Analyse des Inhalts einer Nachricht. Analysieren? Nachrichteninhalt? Kap. 11 geht detailliert auf die Funktionsweise von checks ein und beschäftigt sich mit der Theorie von checks.

Interne Content-Filter anwenden
Kap. 12 zeigt anhand ausgewählter Beispiele, wie Sie checks in der Praxis anwenden.

Wie externe Content-Filter funktionieren
Externe Content-Filter delegieren die Kontrolle der SMTP-Kommunikation und des Nachrichteninhalts an externe Applikationen. Kap. 13 stellt das Postfix-Konzept der externen Content-Filter vor und zeigt beispielhaft, wie E-Mails bei Verwendung von Content-Filtern Postfix verlassen und wie diese nach Verarbeitung durch ein externes Programm wieder in Postfix zurückgelangen.

Externe Content-Filter anwenden
In Kap. 14 zeigen wir anhand populärer Beispiele, wie Sie externe Content-Filter in der Praxis einsetzen können.

Milter anwenden
Postfix unterstützt das Sendmail-Milter-Protokoll. In Kapitel 15 zeigen wir Ihnen, wie Sie damit Header und Body auf einmal bearbeiten können.

Mail-Gateways
Kapitel 16 zeigen wir Ihnen anhand des Musterbeispiels DKIM, wie Postfix mit Sendmail-Milter umgehen kann.

Mailserver für mehrere Domains
Kap. 17 beschreibt die zwei Arten, auf die Postfix Mail für mehrere Domänen auf demselben Server bearbeiten kann. Zusätzlich erfahren Sie, wie man Postfix SQL-Server statt statischer Maps abfragen lässt.

SMTP-AUTH-Einmaleins
SMTP-Authentifizierung ist eine Methode, die den Clients eine Authentifizierung innerhalb der SMTP-Sitzung erlaubt. Auf Basis dieser Authentifizierung können dann Entscheidungen wie „Relaying oder nicht“ gefällt werden. Da die SMTP-AUTH-Funktionalität in Postfix auf Cyrus SASL basiert, beschäftigt sich Kap. 18 mit der Konfiguration von Cyrus SASL, bevor es durch Postfix genutzt werden kann.

SMTP-Authentifizierung
Kap. 19 setzt das SMTP-AUTH-Thema fort, indem beschrieben wird, wie man Postfix für server- oder clientseitige Authentifizierung konfiguriert.

TLS verstehen
Transport Layer Security (TLS) verschlüsselt und/oder authentifiziert die Kommunikation zwischen Postfix und anderen Maschinen. Postfix erfordert den Einsatz von OpenSSL, und Kap. 20 beschäftigt sich nicht nur mit den Möglichkeiten von TLS, sondern beschreibt auch das Erstellen der notwendigen Zertifikate.

TLS einsetzen
Kapitel 21 beschreibt sowohl das serverseitige Anbieten als auch die clientseitige Verwendung von TLS; ebenso wird zertifikatsbasiertes Relaying demonstriert.

Firmenserver
Kap. 22 beschreibt, wie man Postfix mit einem LDAP-Verzeichnisdienst integriert. Dazu wird die lokale Zustellung an einen LDAP-fähigen MDA delegiert und der Courier-IMAP/POP-Server aufgesetzt. Am Ende haben wir ein Mailsystem gebaut, dessen gesamte Userdaten aus einem LDAP-Server kommen.

Postfix chrooted betreiben
Kap. 23 zeigt, wie man Postfix in einem chroot betreibt. Hier wird beschrieben, warum einige Dämonen nicht chrooted laufen können und wie man chroot und SMTP AUTH erfolgreich miteinander verheiratet.

Rate Limiting
Kap. 24 erläutert, wie man die Rate von Clientanfragen limitieren kann. Dies ist eine Gegenmaßnahme für Clients, die Postfix´ smtpd mit zu vielen (parallelen) Anfragen pro Zeitintervall überfluten wollen.

Performance-Tuning
Postfix ist schnell, aber es gibt fast immer noch Optimierungen. In Kap. 25 werden verschiedene Maßnahmen beschrieben, die Postfix noch schneller machen können.“

Über meine Erfahrungen und Spielereien mit Postfix schreibe ich ein paar Zeilen im Kommentarbereich.

Weblinks zum Thema:
The Postfix Home Page
Email Server

(83)

Ein Gedanke zu „Postfix“

  1. War recht nützlich beim Einrichten von Postfix und Dovecot mit Roundcube, MySQL, AmaViS, Clam Antivirus und SpamAssassin auf Ubuntu, wobei TLS (für die Verschlüsselung) und SASL (für die Authentifizierung) benutzt wird.
    Anmerkungen zur Installation und Einrichtung:
    Mit „man dig“ erhält man die nötige Information dazu. Wer die Info der man pages aufbereitet im Internet finden will, geht zu Beispiel auf dig https://wiki.ubuntuusers.de/dig oder DiG HOWTO https://www.madboa.com/geek/dig/

    „apt-get install postfix postfix-doc postfix-mysql“. Wenn Sie bei den Fragen der Eingabeaufforderung unsicher waren, können Sie die Konfiguration mit „dpkg-reconfigure postfix“ wiederholen und folgendes eingeben:
    Internetseite
    mail.example.com
    Benutzername oder root
    mail.example.com, localhost.localdomain, localhost
    Nein
    127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/24
    0
    +
    Alle

    „Postfix Configuration Parameters“ für die main.cf hier: http://www.postfix.org/postconf.5.html
    Hostname“ konfigurieren

    Um den MX-Eintrag haben wir uns ja bereits gekümmert, nun wollen wir „myhostname“ und „mydomain“ betrachten und richtig setzen. Dazu starten wir in einem zweiten Terminal (remote) telnet mit „telnet mail.beispiel.com 25“
    „220 mail.example.com ESMTP Ubuntu“ ist uns recht und wir beendendie Session mit „QUIT“.

    Damit könnte man zufrieden sein, aber wir setzen jedenfalls „myhostname = mail.example.com“ und fragen den Postfix mit „postconf mydomain“.
    „mydomain = localdomain“ ist uns nicht recht, daher setzen wir in der main.ct „mydomain = exempel.com“ und nach jedem Speicher, klicken wir in Webmin auf „reload configuration“.

    Die „Final Destination“ konfigurieren
    Damit ist gemeint, dass dieser Postfix-Server der endgültige Bestimmungsort ist. Postfix wird Nachrichten, für die er die „final destination“ ist, lokal weiter leiten. Was in $mydomain steht, weiß Postfix schon, also können wir schreiben „mydestination = $mydomain. In die main.cf chreiben wir „mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost“ oder
    „mydestination =
    $myhostname
    $mydomain
    localhost.$mydomain
    localhost“
    Denn Postfix liest jede Zeile die nikcht mit dem Kommentarzeichen #, aber mit Leerzeichen beginnt, als Fortsetzung der vorherigen Zeile. Natürlich können Sie statt „$mydomain“ auch „beispiel.com“ schreiben, Postfix ist das egal.
    Alias setzten
    Mit hash:/etc/aliases oder hash:/etc/postfix/aliases legen wir das Verzeichnis für die aliases fest.
    Wir editieren die aliases und schreiben zum Beispiel:
    root: irgendwer
    Also key: Wert (Unix-Benutzer, Emailadresse, Liste von Benutzernamen).
    Um die Emails an „root“ nach „irgenwer“ umzuleiten. Dabei ist der „:“ wichtig. Weitere alias einrichten, wie für Erika Musterman z.B:
    erika: musterman
    erika.musterman: musterman
    #groups
    irgendeine: irgendwer, musterman, nochwer
    Damit gehen für der Benuter „musterman“ auch die Emails erika@beispiel.com, erika.musterman@beispiel.com an Musterman und es wird eine Kopie an die Gruppe „irgendeine“ und zwar an „irgendwer“ und „nochwer“ geschickt.
    Danach muss man die Map wieder indizieren mit „hash:/etc/aliases „ damit die Aliases auch gefunden werden.
    Allgemeine Netzwerkeinstellungen
    IPv4 wird ohnehin schon immer unterstützt, aber seit Postfix 2.2 wird auch IPv6 unterstützt. Momentan, also am 19. Sept. 2015, ist übrigens die Version 3.0.1 aktuell.
    Standardeinstellung in der master.ct ist übrigens „inet_protocols = IPv4“, aber mit inet_protocols = all“ werden beide Protokolle verwendet. Für die Netzwerkschnittstellen ist der Standardwert „inet_interfaces = all“ und damit lauscht der Postfix an allen Netzwerkschinttstellen.
    Am besten bindet man den Postfix-smtp-Client mit „smtp_bind_address = xx.xx.xx.xx“ an die IP, für die der MX-Eintrag besteht, damit sich andere Mailserver nicht beschweren und uns abweisen. Für v6 verwendet man „smtp_bind_address6 = xxxx:xxx:x:x:x:x:x:x“
    Mailserver, die Mailclients von allen IP-Adressen gestatten Mails zu versenden, werden auch Open Relay genannt, weil ein unbekannter Mailclient E-Mails an Empfänger, die nicht am eigenen Mailserver angemeldet sind, verenden dürfen. Spam und Viren sind die Folge. Die Standardeinstellung von Postfix verhindert aber schon den Missbrauch als Open Relay, denn Postfix vertraut nur den IP-Adressen seiner Netzwerkschinttstellen.
    Für einige statische IP-Adressen kann man Postfix mittels „mynetworks_styls“ (für ganze IP-Klassen, subnets oder host) oder „mynetworks“ (für individuelle IPs) festlegen, wer Emails versenden darf. Für dynamische IPs ist aber eine SMTP-Authentifizierung erforderlich. Standardmäßig ist Postfix mit „mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128“ für den localhost eingestestellt. Hier sei angemerkt, dass es oft sinnvoll ist den eigenen Serviceprovider als Relay-Host zu definieren, da viele Mailserver mit Unbekannten nicht kommunizieren. Dazu benötigt man die Ip des Mialservers und legt dann fest „relayhost = [relayhost.isp.example.com]. Möglich wäre hier auch:
    relayhost = $mydomain
    relayhost = [gateway.example.com]
    relayhost = uucphost
    relayhost = [an.ip.add.ress]

    Open Relay
    Als offenes Relay wird ein Mailserver bezeichnet, der Mails weiterleitet, obwohl weder Absender noch Empfänger von ihm selbst gehostet werden.
    Beispiel: Der Mailserver „mail.grossefirma.de“ soll Mails für die Domäne „grossefirma.de“ verarbeiten.
    Erlaubt sollten sein:
    Mails an z.B. „info@grossefirma.de“
    Mails von z.B. „info@grossefirma.de“
    aber nicht:
    Mails von „kaufmich@werbefritze-xyz.de“ an „user@irgendwo-anders.de“
    Mails mit gefälschten Absenderadressen aus der Domain „grossefirma.de“, die über diesen Server verschickt werden
    Diese falsch konfigurierten Mailserver werden meist nach wenigen Minuten Onlinezeit automatisiert gefunden und dann von Spammern für den Versand ihrer Massenmails verwendet.
    Abgesehen von der Belästigung der Empfänger dieser Werbebotschaften können für den Betreiber des offenen Relays extreme Kosten durch den generierten Traffic entstehen. Zudem wird das offene Relay schnell in sogenannten Blacklists eingetragen, was dazu führt, dass normale Mails von diesem Server ebenfalls bei vielen Empfängern nicht mehr akzeptiert werden.
    Wie kann ich bei meinem Mailserver ein offenes Relay verhindern?
    Bei eigentlich jeder Mailserversoftware sind Regelmechanismen vorhanden, die ein unautorisiertes Versenden von Mails verhindern können.
    Grundsätzlich:
    Mailversand ohne Authentifizierung wenn überhaupt nur von firmeninternen IP-Adressen zulassen
    Authentifizierungstechniken wie SMTP-Auth (zur Not auch POP-before-SMTP) beim Versand von Mails erzwingen
    Annahme von Mails ohne Authentifizierung nur für eigene Domains erlauben

    Testen
    Jetzt werden wir die Basiskonfiguration eimal kurz testen, bevor wir uns Dovecot zuwenden.
    Wir verwenden dazu telnet, verbinden uns mit Postfix und verschicken eine E-Mail.
    $ telnet mail.beispiel.com 25
    Trying xx.xx.xx.xx…
    Connected to mail.beispiel.com.
    Escape character is ‚^]‘.
    220 mail.beispiel.com ESMTP Postfix (Ubuntu)
    HELO client.beispiel.com
    250 mail.example.com
    MAIL FROM:
    250 2.1.0 Ok
    RCPT TO:
    454 4.7.1
    : Relay access denied
    RCPT TO:
    250 2.1.5 Ok
    DATA
    Subject: Sending an email using telnet
    354 End data with .
    Hallo anderer client oder root,
    blablabla
    Tschüß
    .
    250 2.0.0 Ok: queued as 06473162319
    QUIT
    221.2.0.0 Bye
    Die Verbindung hat funktioniert und mit „ESMTP Postfix (Ubuntu)“ hat er uns gesagt, dass er auch ESMTP kann. Die Ausgabe entspicht der Zeile „smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)“ in der main.cf und kann natürlich abgeändert werden.
    Mit dem MAIL FROM: war Postfix einverstanden, aber er wollte mich von einer unbekannten Adresse aus, nicht an einen fremden Server senden lassen, sondern nur lokal, was nach der zweiten Eingabe von RCPT TO: auch gelang. Nach Data kann man die Daten einfügen einen Betreff kann man wir mit SUBJECT: noch einbauen und um die Eingabe zu beenden, schreiben wir einen Punkt in eine neue Zeile. Das war’s noch nicht ganz, denn jetzt sollten sie den Postfix stoppen, oder dafür sorgen, dass er nicht als open relay läuft!
    Testen Sie das auf http://www.mailradar.com/openrelay/ oder http://die-ip-adresse.de/open-relay-test.php bzw. den Email-Server auf http://mxtoolbox.com/SuperTool.aspx
    Ich wollte mir jetzt kein weiteres „550 relay not permitted“ holen und weder das RFC 2822 https://www.ietf.org/rfc/rfc2822.txt noch das RFC 3463 https://tools.ietf.org/html/rfc3463 genauer ansehen, obwohl Postfix ESMTP beherrscht, sondern ich sehe mir jetzt Dovecot näher an, da sowieso Dovecot die Authentifizierung übernehmen soll.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.