Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2014/03/25 20:14]
flacco [Postfix, Amavis & Dovecot]
+++ kb [2014/03/28 14:06]
flacco [Letzte Etappe - Dovecot]
@@ Zeile 350: / Zeile 350: @@
 Größte Schwierigkeit hierbei ist ein sauberes Mailrouting durch alle Komponenten. Dies beginnt bereits beim Fetchmail-Daemon. Zunächst ein schematischer Überblick über die Wege einer eingehenden Email:
+//**Hinweis:** Die Grafik ist nicht aktuell, der Dovecot Delivery Agent fällt jetzt weg, die Einlieferung erfolgt direkt via LMTP.//
 {{:invis-postfix_dovecot.png|Überblick}}
@@ Zeile 504: / Zeile 506: @@
 //**Achtung:** In einigen der jüngeren invis-Releases (7.0/7.1) habe ich darüber hinaus die Option "-o local_header_rewrite_clients=" gesetzt. Dies wird auch an anderer Stelle so angegeben. Diese Option sorgt allerdings dafür, dass das zuvor vorgenommene Address-Rewriting (aus lokaler Mail-Adresse mache externe Adresse) beim Rückliefern der Mail wieder rückgängig gemacht wird. Bedeutet die Empfänger einer solchen Mail sehen als Absende-Adresse die lokale Email-Adresse des Absender, die aber im Internet-Mailverkehr keine Gültigkeit hat.//
-Postfix ist zwar durchaus in der Lage Mails direkt in sogenannte "Maildirs" einzuliefern, allerdings ist dieser direkte Weg mit allerlei Nachteilen verbunden, da dadurch einige Stärken von Dovecot ungenutzt bleiben. Besser ist es die Verteilung der Mails in die jeweiligen Postfächer Dovecots eigenem MDA //**deliver**// zu übertragen.
+Postfix ist zwar durchaus in der Lage Mails direkt in sogenannte "Maildirs" einzuliefern, allerdings ist dieser direkte Weg mit allerlei Nachteilen verbunden, da dadurch einige Stärken von Dovecot ungenutzt bleiben. Besser ist es die Verteilung der Mails in die jeweiligen Postfächer Dovecots zu überlassen und die Übergabe an Dovecot via LMTP (Local Mail Transfer Protocol) zu erledigen.
 Üblicherweise sind Maildirs in den Home-Verzeichnissen der Benutzer zu finden. Dies birgt einige Nachteile und Gefahren in sich. Die größte Gefahr dabei, geht wohl von den Nutzern selbst aus, die in der Lage sind diese Verzeichnisse einfach zu löschen. Dass ein Benutzer im "Aufräumrausch" einfach mal Verzeichnisse löscht, mit denen er nichts anfangen kann, dürfte wohl keine Seltenheit sein.
@@ Zeile 525: / Zeile 527: @@
 </code>
-Damit Postfix weiß, auf welchem Weg es Mails lokal zuzustellen hat, muss dies in Abhängigkeit zur Empfänger-Domain bekannt gemacht werden. Genutzt werden für diesen Zweck entsprechende Lookup-Tables. Hintergrund ist hier, dass Postfix über die Empfänger keine Kenntnis hat oder braucht. Es bekommt einfach nur gesagt, welche Domains lokal "relayed" werden und wer sich um die Zustellung kümmert. Für beide Zwecke gibt es mit //relay_domains// und //transport_maps// eigene Lookup-Tables. Da in unserem Fall beide Tables den gleichen Inhalt haben, werden Sie an die selbe Datenquelle gebunden. Vorgenommen wird diese Konfiguration wieder in der Datei: <file>/etc/postfix/main.cf</file>
+Damit Postfix weiß, auf welchem Weg es Mails lokal zuzustellen hat, muss dies in Abhängigkeit zur Empfänger-Domain bekannt gemacht werden. Genutzt werden für diesen Zweck entsprechende Lookup-Tables. Hintergrund ist hier, dass Postfix über die Empfänger keine Kenntnis hat oder braucht. Es bekommt einfach nur gesagt, welche Domains lokal "relayed" werden und wer sich um die Zustellung kümmert. Für beide Zwecke gibt es mit //relay_domains// und //transport_maps// eigene Lookup-Tables. Da in unserem Fall beide die Relay-Domains Table den gleichen Aufbau hat wie die normale Transport-Table, wird Sie an als zusätzliche Transport-Table eingebunden. Vorgenommen wird diese Konfiguration wieder in der Datei: <file>/etc/postfix/main.cf</file>
 <code>
 # Relay Domains und Transportwege-Regelungs Tabelle bekannt machen
-relay_domains = hash:/etc/postfix/relay
+relay_domains = hash:/etc/postfix/relay_domains
-transport_maps = hash:/etc/postfix/relay
+transport_maps = hash:/etc/postfix/transport, $relay_domains
 </code>
-Die in der Konfiguration benannte Datei muss manuell angelegt und mit folgendem Inhalt versehen werden:
+Die in der Konfiguration benannte Datei "relay_domains" muss manuell angelegt und mit folgendem Inhalt versehen werden:
 <code>
 # for relaying domain
 # domain.de OK
-invis-net.loc   dovecot:
+invis-net.loc   lmtp:unix:private/dovecot-lmpt
 </code>
-Darin enthält Spalte 1 die Domain und Spalte 2 den zugehörigen Transportweg. Letzterer muss natürlich in der Datei <file>/etc/postfix/master.cf</file> noch angelegt werden:
+Darin enthält Spalte 1 die Domain und Spalte 2 den zugehörigen Transportweg.
+Das Beispiel zeigt eine LMTP-Anbindung via UNIX-Socket. Die entsprechende Socket-Datei muss von Dovecot bereit gestellt werden. Alternativ wäre auch ein TCP/IP-Socket über die Localhost-Schnittstelle möglich.
 <code>
-## Dovecot Transport -- invis-server.org -- Stefan Schaefer
+# for relaying domain
-dovecot   unix  -       n       n       -       -       pipe
+# domain.de OK
-    flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver
+invis-net.loc   lmtp:[127.0.0.1]
-    -f $sender -d $recipient
 </code>
-Benannt werden hier vor allem der Benutzer unter dessen Kennung der MDA (deliver) ausgeführt wird, der zu verwendende Delivery-Agent selbst, Absender- und Empfängeradresse sowie ein paar Flags, die das Verhalten des Delivery-Agents beeinflussen.
+Die TCP/IP Methode ist etwas einfacher in der Konfiguration, da seitens Dovecot kein Socket definiert werden muss. UNIX-Sockets sind allerdings etwas performanter, da die übertragene Datenmenge durch Wegfall des TCP/IP bedingten Overheads geringer ist.
 ==== Letzte Etappe - Dovecot ====
-Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1 zum Einsatz. Erwähnenswert ist das, da sich an dessen Konfiguration mit Einführung von V. 2.x einiges geändert hat. Einerseits betrifft dies Namen von Konfigurationsoptionen und andererseits den Aufbau der Konfiguration an sich. Unter openSUSE wurde die Konfiguration der Übersicht halber in mehrere Dateien gesplittet. Im Verzeichnis "/etc/dovecot" ist nach wie vor eine (wenn auch stark geschrumpfte) Datei "dovecot.conf" zu finden. Sie dient quasi als Hauptkonfigurationsdatei in die alle weiteren Dateien inkludiert werden. Ähnlich wie das bereits beim Apache-Webserver der Fall ist.
+Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1, inzwischen schon Version 2.2 zum Einsatz. Erwähnenswert ist das, da sich an dessen Konfiguration mit Einführung von V. 2.x einiges geändert hat. Einerseits betrifft dies Namen von Konfigurationsoptionen und andererseits den Aufbau der Konfiguration an sich. Unter openSUSE wurde die Konfiguration der Übersicht halber in mehrere Dateien gesplittet. Im Verzeichnis "/etc/dovecot" ist nach wie vor eine (wenn auch stark geschrumpfte) Datei "dovecot.conf" zu finden. Sie dient quasi als Hauptkonfigurationsdatei in die alle weiteren Dateien inkludiert werden. Ähnlich wie das bereits beim Apache-Webserver der Fall ist.
 Alle weiteren Dateien sind logisch unterteilt im Verzeichnis "/etc/dovecot/conf.d" zu finden.
+Bei aller Freude über Peer Heinleins neues Dovecot Buch, ist doch festzustellen, dass die Aufgabenstellung die sich für die Dovecot-Konfiguration auf einem invis-Server stellt, mit dem Buch allein nicht zu bewältigen ist. Peer trennt im Prinzip zwischen einer Installation mit lokalen Benutzern und einer Hosting-Situation mit virtuellen Benutzern. Auf einem invis-Server haben wir es zwar mit lokalen Benutzern zu tun, aufgrund der Vorzüge, die das mit sich bringt, möchte ich sie aber lieber wie virtuelle Benutzer behandeln, da dies einige Vorteile mit sich bringt.
+**Definieren wir zunächst die Ziele:**
+  * Zugriff auf die LDAP-Benutzerkonten via PAM
+  * Ordner-Freigaben über IMAP-ACLs
+  * Sieve Filter und sei es nur für Abwesenheitsbenachrichtigungen
+  * Quotas, wenn auch nur zum Warnen
+  * Lokale Email-Zustellung via LMTP
+  * SASL-Auth Schnittstelle für Postfix (wird im nächsten Abschnitt beschrieben)
+==== Mailversand - SMTP-Auth mit Dovecot-SASL ====
 ===== ISC DHCP LDAP Schema nach Samba 4 LDAP überführen =====