14.7. Konfiguration des Mailservers#

14.7.1. Konfiguration eines Relay-Hosts für den Mailversand#

Standardmäßig stellt Postfix eine direkte SMTP-Verbindung zu dem für die Domain zuständigen Mailserver her, wenn es eine E-Mail an eine nicht lokale Adresse sendet. Postfix ermittelt diesen Server durch Abfrage des MX-Eintrags im DNS.

Alternativ dazu kann Postfix einen Mail-Relay Server verwenden. Dabei handelt es sich um einen Server, der E-Mails empfängt und deren Transport übernimmt. Administratoren können diese Art von Mail-Relay Servern verwenden, z. B. solche, die von der Firmenzentrale oder dem Internet-Provider bereitgestellt werden. Um einen Relayhost einzurichten, geben Sie ihn als vollständig qualifizierten Domänennamen (FQDN) in der Univention Configuration Registry Variable mail/relayhost an.

Wenn für das Senden eine Authentifizierung auf dem Relayhost erforderlich ist, setzen Sie die Univention Configuration Registry Variable mail/relayauth auf yes und bearbeiten Sie die Datei /etc/postfix/smtp_auth. Geben Sie in dieser Datei den Relayhost, den Benutzernamen und das Passwort in einer Zeile in folgendem Format ein: FQDN-Relayhost Benutzername:Passwort

Um die Änderungen in Postfix zu übernehmen, führen Sie die folgenden Befehle aus:

  1. Aktualisieren Sie die Authentifizierungszuordnung:

    $ postmap /etc/postfix/smtp_auth
    
  2. Wenn Sie mail/relayauth geändert haben, müssen Sie die Datei für die TLS-Richtlinien aktualisieren:

    $ postmap /etc/postfix/tls_policy
    
  3. Wenn Sie mail/relayhost geändert haben, müssen Sie dem Mailserver sagen, dass er die Konfiguration neu laden soll:

    $ service postfix reload
    

Bemerkung

Um eine verschlüsselte Verbindung bei Verwendung eines Relay-Hosts zu gewährleisten, müssen Sie die Postfix-Konfigurationsoption smtp_tls_security_level auf encrypt setzen.

Univention Corporate Server setzt diese Option automatisch, wenn die Univention Configuration Registry Variablen mail/relayhost und mail/relayauth den Wert yes haben und wenn mail/postfix/tls/client/level nicht den Wert none hat.

14.7.2. Konfiguration der maximalen E-Mailgröße#

Mit der Univention Configuration Registry Variable mail/messagesizelimit kann die maximale Größe in Byte für ein- und ausgehende E-Mails festgelegt werden. Die voreingestellte Maximalgröße beträgt 10240000 Byte. Nach Änderung der Einstellung muss Postfix neu gestartet werden. Wird 0 als Wert konfiguriert, so wird die Begrenzung aufgehoben. Es ist zu beachten, dass Emailanhänge durch die base64-Kodierung um ca. ein Drittel vergrössert werden.

14.7.3. Konfiguration einer Blindkopie zur Anbindung von E-Mail-Archivierungslösungen#

Wird die Univention Configuration Registry Variable mail/archivefolder auf eine E-Mail-Adresse gesetzt, sendet Postfix eine Blindkopie aller ein- und ausgehenden E-Mails an diese Adresse. So kann eine Archivierung aller E-Mails erreicht werden. Die E-Mail-Adresse muss bereits existieren. Sie kann entweder eine in Univention Corporate Server registrierte E-Mail-Adresse eines Benutzers sein, oder von einem externen Dienst bereitgestellt werden. Standardmäßig ist die Variable nicht gesetzt.

Anschließend muss Postfix neu gestartet werden.

14.7.4. Konfiguration von Softbounces#

Bei einer Reihe von Fehlersituationen (z.B. bei nicht vorhandenen Benutzern) kann es zu einem Bounce der betroffenen Mail kommen, d.h. die Mail wird an den Absender zurückgesendet. Mit dem Setzen der Univention Configuration Registry Variable mail/postfix/softbounce auf yes werden Mails nie mit einem Bounce zurückgesendet, sondern immer weiterhin in der Queue vorgehalten. Diese Einstellung ist insbesondere für Konfigurationsarbeiten am Mailserver sehr nützlich.

14.7.5. Konfiguration der SMTP Ports#

Auf einem Univention Corporate Server Mailserver ist Postfix so konfiguriert, dass es auf Verbindungen an drei Ports lauscht:

Port 25 - SMTP

Port 25 (SMTP) sollte nur von anderen Mailservern verwendet werden. Standardmäßig ist die Authentifikation an diesem Port deaktiviert. Wenn das Einliefern von E-Mails an Port 25 erlaubt werden soll, kann die Univention Configuration Registry Variable mail/postfix/mastercf/options/smtp/smtpd_sasl_auth_enable auf yes gesetzt werden.

Port 465 - SMTPS

Port 465 (SMTPS) erlaubt die Authentifikation gegenüber dem Mailserver und das Einliefern von E-Mails über eine mit SSL verschlüsselte Verbindung. SMTPS wurde zugunsten von Port 587 als veraltet erklärt, wird jedoch für Altsysteme aktiviert gelassen.

Port 587 - Submission

Port 587 (Submission) erlaubt die Authentifikation gegenüber dem Mailserver und das Einliefern von E-Mails über eine TLS-verschlüsselte Verbindung. Die Verwendung von STARTTLS wird erzwungen.

Der Submission-Port sollte von E-Mail-Clients bevorzugt verwendet werden. Die Verwendung der Ports 25 und 465 zur Einlieferung von E-Mails ist überholt.

14.7.6. Konfiguration zusätzlicher Prüfungen#

Bei der Verwendung eines Mailservers, der direkt vom Internet aus erreichbar ist, besteht immer die Gefahr, dass Versender von Spam oder defekte Mailserver kontinuierlich versuchen, auf dem UCS-System ungewollte Mails (z.B. Spam) abzuliefern.

Um die Last des Mailservers für solche Fälle zu reduzieren, bringt Postfix einen eigenen Dienst mit dem Namen postscreen mit, der Postfix vorgeschaltet wird und die eingehenden SMTP-Verbindungen annimmt. Mit diesen Verbindungen werden zunächst einige leichtgewichtige Tests durchgeführt. Ist das Ergebnis positiv, wird die Verbindung an Postfix durchgereicht. Im negativen Fall wird die SMTP-Verbindung beendet und somit die eingehende Mail abgelehnt, bevor sie im Verantwortungsbereich des UCS Mailservers angekommen ist.

In der Standardeinstellung ist postscreen nicht aktiv. Durch das Setzen der Univention Configuration Registry Variable mail/postfix/postscreen/enabled auf den Wert yes kann postscreen aktiviert werden.

Über diverse UCR-Variablen mit dem Präfix mail/postfix/postscreen/ können weitere Einstellungen vorgenommen werden. Eine Liste der UCR-Variablen nebst Beschreibungen können z.B. auf der Kommandozeile über folgenden Befehl abgerufen werden:

$ ucr search --verbose mail/postfix/postscreen/

Bemerkung

Nach jeder Änderung einer UCR-Variable für postscreen sollte die Konfiguration von Postfix und postscreen neu geladen werden, was über den Befehl systemctl reload postfix ausgelöst werden kann.

14.7.7. Eigene Anpassung der Postfix Konfiguration#

Die Konfiguration von Postfix, welche sich in der Datei /etc/postfix/main.cf befindet, wird über Univention Configuration Registry-Variablen definiert. Eine Erweiterung der Konfiguration, die über die vorhandenen Univention Configuration Registry-Variablen hinaus geht, ist ebenso möglich.

Existiert die Datei /etc/postfix/main.cf.local, so wird ihr Inhalt an die Datei main.cf angehängt. Damit Änderungen an main.cf.local nach main.cf übernommen werden, muss der folgende Befehl ausgeführt werden:

$ ucr commit /etc/postfix/main.cf

Zum Übernehmen der Änderungen durch den Postfix Dienst muss dieser neu geladen werden:

$ systemctl reload postfix

Wird in der Datei main.cf.local eine Postfix Variable gesetzt, die zuvor auch in main.cf gesetzt wurde, so schreibt Postfix eine Warnung in die Logdatei /var/log/mail.log.

Bemerkung

Wenn das Verhalten des E-Mail-Servers nicht der Erwartung entspricht, sollten zuerst die Einstellungen, die durch main.cf.local aktiviert wurden, rückgängig gemacht werden. Dazu muss die Datei umbenannt oder ihr Inhalt auskommentiert werden. Im Anschluss müssen die beiden oben genannten Kommandos ausgeführt werden. Die Konfiguration entspricht dann wieder der Standardkonfiguration von UCS.

14.7.8. Konfiguration des Alias Expansion Limits#

Werden E-Mails an einer Gruppe gesendet, die wiederum andere Gruppen enthält, kann es passieren, dass diese E-Mails nicht akzeptiert werden. Das liegt daran, dass Postfix durch eine Virtual Alias Expansion versucht, die Anzahl der ursprünglichen Empfänger entsprechend zu erweitern. Diese Anzahl wird standardmäßig auf 1000 Nutzer begrenzt und kann daher zu gering sein.

Um den Wert auf beispielsweise 5000 Nutzer zu erhöhen, muss die folgende Zeile in /etc/postfix/main.cf.local hinzugefügt oder angepasst werden:

virtual_alias_expansion_limit = 5000

Danach muss Postfix neugestartet werden:

$ systemctl restart postfix

14.7.9. Handhabung der Postfächer bei Änderung der E-Mail-Adresse und Löschung von Benutzerkonten#

Das Postfach eines Benutzers ist mit der primären E-Mail-Adresse verknüpft und nicht mit dem Benutzernamen. Mit der Univention Configuration Registry Variable mail/dovecot/mailbox/rename kann das Verhalten bei der Änderung der primären E-Mail-Adresse konfiguriert werden:

  • Ist die Variable auf yes gesetzt, wird das IMAP-Postfach des Benutzers umbenannt. Dies ist seit UCS 3.0 die Standardeinstellung.

  • Bei der Einstellung no, sind nach dem Ändern der primären E-Mail-Adresse eines Benutzers seine bisherigen E-Mails nicht mehr erreichbar! Wird einem anderen Benutzer eine ehemals vergebene primäre E-Mail-Adresse zugewiesen, bekommt dieser Zugriff auf die alte IMAP-Struktur dieses Postfachs.

Mit der Univention Configuration Registry Variable mail/dovecot/mailbox/delete kann konfiguriert werden, ob IMAP-Postfächer automatisch gelöscht werden sollen. Der Wert yes aktiviert die Löschung des betroffenen IMAP-Postfachs bei folgenden Aktionen:

  • dem Löschen des Benutzerkontos

  • dem Entfernen der primären Mailadresse von einem Benutzerkonto

  • dem Ändern des Mail Home Servers auf ein anderes System

In der Grundeinstellung (no) bleiben die Postfächer bei diesen Aktionen erhalten, wenn eine der obigen Aktionen durchgeführt wird.

Aus der Kombination der beiden Variablen ergeben sich folgende vier Fälle, wenn E-Mail-Adressen geändert werden:

Tab. 14.5 Umbenennung von E-Mail-Adressen#

mail/dovecot/mailbox/…

Bedeutung

rename=yes und delete=no (Standard)

Die bestehende Mailbox wird umbenannt. E-Mails bleiben erhalten und sind unter dem neuen Namen erreichbar.

rename=yes und delete=yes

Die bestehende Mailbox wird umbenannt. E-Mails bleiben erhalten und sind unter dem neuen Namen erreichbar.

rename=no und delete=no

Eine neue, leere Mailbox wird erzeugt. Die alte bleibt unter dem alten Namen auf der Festplatte erhalten und ist damit vorerst für Benutzer nicht zu erreichen.

rename=no und delete=yes

Eine neue, leere Mailbox wird erzeugt. Die alte Mailbox wird inklusive aller enthaltenen Mails von der Festplatte gelöscht.

14.7.10. Verteilung einer Installation auf mehrere Mailserver#

Das UCS-Mailsystem bietet die Möglichkeit die Benutzer auf mehrere Mailserver zu verteilen. Dazu wird jedem Benutzer ein sogenannter Mail Home Server zugewiesen, auf dem die Maildaten des Benutzers abgelegt werden. Beim Zustellen einer E-Mail wird der zuständige Home Server automatisch aus dem LDAP-Verzeichnis ermittelt.

Es ist zu beachten, dass globale IMAP-Ordner (siehe Verwaltung von globalen IMAP-Ordnern) einem Mail Home Server zugeordnet sind.

Beim Ändern des Mail Home Servers eines Benutzers werden dessen E-Mails nicht automatisch auf den neuen Server verschoben.

14.7.11. Mailserver-Speicher auf NFS#

Dovecot unterstützt das Speichern von E-Mails und Index-Dateien auf Cluster-Dateisystemen und NFS. Einige Einstellungen sind jedoch nötig, um Datenverluste in bestimmten Situationen zu vermeiden.

Die folgenden Einstellungen gehen davon aus, dass auf Mailboxen nicht gleichzeitig von mehreren Servern aus zugegriffen wird. Das ist der Fall, wenn jedem Benutzer ein Mail Home Server zugeordnet ist.

Um eine bessere Performance zu erreichen, können Index-Dateien statt zusammen mit den Nachrichten im NFS auch auf der lokalen Festplatte gespeichert werden. Sie sind dann unter /var/lib/dovecot/index/ zu finden. Setzen Sie dafür die Univention Configuration Registry Variable mail/dovecot/location/separate_index=yes.

Mit diesen Einstellungen sollte normalerweise alles problemlos funktionieren. Die im Einsatz befindlichen Server- und Client-Systeme sind jedoch so vielfältig, dass hier noch ein paar Hinweise folgen, wie bei Schwierigkeiten weiter vorgegangen werden kann:

  • Wenn NFSv2 im Einsatz ist (nicht der Fall, wenn der NFS-Server ein Univention Corporate Server ist), setzen Sie bitte mail/dovecot/process/dotlock_use_excl=no.

  • Falls kein lockd eingesetzt wird (nicht der Fall auf Univention Corporate Server-Systemen) oder falls trotz des Einsatzes von lockd Locking-Fehler auftreten, setzen Sie mail/dovecot/process/lock_method=dotlock. Dies verringert die Performance, aber behebt die meisten Locking-bezogenen Probleme.

  • Dovecot kann mit mail/dovecot/process/mail_nfs_storage=yes angewiesen werden, wenn nötig, den NFS Cache zu leeren. Dies funktioniert jedoch nicht immer, daher kann es zu sporadischen Fehlern kommen. Das gleiche gilt für das Leeren des NFS-Cache nach dem Schreiben von Index-Dateien: mail/dovecot/process/mail_nfs_index=yes.

Siehe auch

Mail Location Settings in der Dovecot Dokumentation

für weitere Informationen über Mailbox Orte.

Shared mailboxes in der Dovecot Dokumentation

für weitere Informationen über das Teilen von Mailboxen.

NFS in der Dovecot Dokumentation

für weitere Informationen über die Verwendung von Dovecot mit NFS.

14.7.12. Beschränkung der Verbindungsanzahl#

In der Standardeinstellung in UCS wird Dovecot für jeweils maximal 400 gleichzeitige Verbindungen per IMAP und POP3 ausgeliefert. Diese reichen sicher aus, um 100 gleichzeitig eingeloggte IMAP-Benutzer zu bedienen, unter Umständen deutlich mehr.

Wie viele IMAP-Verbindungen Benutzer gleichzeitig geöffnet haben, hängt von den eingesetzten Clients ab:

  • Webmail öffnet nur einzelne, kurzlebige Verbindungen.

  • Desktop E-Mail-Programme halten über lange Zeit mehrere Verbindungen offen.

  • Mobile Clients halten über lange Zeit wenige Verbindungen offen, aber beenden diese oft nicht von sich aus, so dass sie unnötig lang Ressourcen belegen.

Die Beschränkungen dienen primär dazu, einem Denial-of-Service Angriff durch sehr viele geöffnete Prozesse und Netzwerkverbindungen zu widerstehen.

Um die in diesem Augenblick offenen Verbindungen zu sehen, kann folgender Befehl ausgeführt werden:

$ doveadm who

Um die Gesamtanzahl auszugeben:

$ doveadm who -1 | wc -l

Um die Beschränkungen zu verändern, können die Univention Configuration Registry Variablen mail/dovecot/limits/* angepasst werden. Der Vorgang ist auf Grund des komplexen Zusammenspiels dieser Variablen nur halb automatisch. Die Bedeutung aller Variablen kann in Dovecot Dokumentation: Service configuration nachgelesen werden.

Da bei Dovecot verschiedene Prozesse für Login und Zugriff auf die E-Mail-Dateien zuständig sind, können diese getrennt konfiguriert werden. Zusätzlich wird getrennt konfiguriert, wie viele Verbindungen zu einem Dienst erlaubt sind und wie viele Prozesse für einen Dienst gestartet werden. Durch das Setzen von mail/dovecot/limits/default_client_limit=3000 würde die Beschränkung für die Anzahl an Verbindungen zu den POP3- und IMAP-Diensten verändert, nicht jedoch für die erlaubte Anzahl an Prozessen. In der Univention Corporate Server Standardeinstellung läuft Dovecot im High-security mode: Jede Verbindung wird von einem separaten Login-Prozess betreut. Da standardmäßig nur 400 Prozesse erlaubt sind, können auch nicht mehr Verbindungen geöffnet werden.

Um 3000 Verbindungen von Benutzern zu ihren E-Mails zu erlauben, muss daher eine weitere Univention Configuration Registry Variable gesetzt werden:

$ ucr set mail/dovecot/limits/default_client_limit=3000
$ ucr set mail/dovecot/limits/default_process_limit=3000
$ doveadm reload

Ein Blick in /var/log/dovecot.info offenbart nun eine Warnung:

config: Warning: service auth { client_limit=2000 } is lower than required under max. load (15000)
config: Warning: service anvil { client_limit=1603 } is lower than required under max. load (12003)

Die Dienste auth (Zuständig für Login und SSL-Verbindungen) sowie anvil (Zuständig für Statistiken) haben noch das Standardlimit. Es werden zwar je 3000 POP3- und IMAP-Verbindungen und -Prozesse erlaubt, aber die Anzahl der Prozesse für Login und SSL ist nun zu niedrig um sie alle zu bedienen. Dies wird dazu führen, dass Logins fehlschlagen.

Die hohen Werte kommen dadurch zustande, dass mit default_client_limit und default_process_limit nicht nur die Beschränkungen von IMAP und POP3 erhöht werden, sondern auch einiger weiterer Dienste wie lmtp und managesieve-login. Diese Dienste können nun mehr zu überwachende Prozesse starten und theoretisch mehr Authentifizierungen durchführen, wodurch sich die maximale Anzahl gleichzeitiger Verbindungen zu den Diensten auth und anvil erhöht.

Die Werte für die Dienste müssen nun der Fehlermeldung entsprechend angepasst werden:

$ ucr set mail/dovecot/limits/auth/client_limit=15000
$ ucr set mail/dovecot/limits/anvil/client_limit=12003
$ doveadm reload

Ein Blick in /var/log/dovecot.info offenbart nun noch eine letzte Warnung:

master: Warning: fd limit (ulimit -n) is lower than required under max. load (2000 < 15000),…
 because of service auth { client_limit }

Das vom Linux-Kernel kontrolliere ulimit (die erlaubte Anzahl gleichzeitig geöffneter Dateien/Verbindungen pro Prozess) wird nur bei einem Neustart des Dovecot-Dienstes verändert, daher:

$ systemctl restart dovecot

Nun erscheint keine Fehlermeldung mehr, und IMAP- und POP3-Server akzeptieren nun beide je 3000 Verbindungen.

Univention Corporate Server konfiguriert Dovecot so, dass es standardmäßig im High-security mode läuft. In Installationen mit zehntausenden Benutzern kann Dovecot im High-performance mode betrieben werden. Der Performance-Leitfaden beschreibt, wie dieser konfiguriert werden kann, siehe UCS performance guide [5].