Der Mailserver sollte eine eigene VM oder Hardwaremaschine sein.
Die Funktionen des Mailservers sind EIGENTLICH nur die Mails loszuschicken und für Clients bereitzuhalten. Jedoch hat die TUM auf dem Mailserver Features, die weitere Annehmlichkeiten bieten:
Unterstützung für drei Domains ist aktuell implementiert:
mail.fs.ei.tum.de mail.fsei.de mail.beste-fachschaft.de
Was man täglich brauchen kann:
fseiProtectedList
oder uid
unter ou=Listen
)Local Users sind notwendig, damit man in den Aliases auch an Skripte zustellen kann. Beispielsweise wird gott@beste-fachschaft.de gepiped aufgerufen und versendet dann wieder eine Mail.
Bei LMTP kann man den Postfix und Dovecot auf verschiedenen Server laufen lassen, jedoch ist das für den TUM Mailserver nicht notwendig! Bei Pipe kann man ein Commando spezifizieren und dann dort auch on the fly Parameter parsen. Genau dieses brauchen wir an der TUM um die Mailbox (also Bsp: list.admin) mitgeben zu können.
Eingang bei Postfix ⇒ Anwenden verschiedener Aliases ⇒ Zustellung mittels dovecot-deliver ⇒ Ausführung des DirtyShitScripts, dass die Mailbox zurückgibt (Bsp: lists.vorstand) ⇒ Speicherung auf HDD durch dovecot Die Zustellung läuft hier einfach für den User lists ab. Jedoch wird die Mail in seine Unterverzeichnisse gespeichert und nicht in Inbox.
Eingang bei Postfix ⇒ Anwenden verschiedener Aliases ⇒ Zustellung mittels dovecot-deliver ⇒ Ausführung des DirtyShitScripts, dass die Mailbox gengeriert (hier immer INBOX) ⇒ Speicherung auf HDD durch dovecot
Ein Alias stellt eine Namenersetzung in einer Email dar: noc → admin Wenn man die Email kopiert weiterschicken will (CC-Forward): admin → admin, zet
Es wurde aus folgenden Gründen die Eintragung über fseiUserForwardDoNotEdit im LDAP implementiert (statt Mail an Python zu Pipen):
~/.listsForward
selbst ihre Weiterleitung einstellen! (Trotzdem sicher! Keine Injections etc.)Arten von alias in verschiedenen LDAP-Flags abgelegt:
Arten der Weiterleitungen:
~/.forward
: Weiterleitung des persöhnlichen Postfaches~/.listsForward
: Weiterleitung der Listen an den Username
Die Berechtigungen für das ~/.listsForward
sind egal, da das Alias Skript mit Rootrechten ausgeführt wird und die Files einliest.
Das ~/.forward
muss vom User lesbar sein, weil sich Postfix mit Userrechten das File liest.
Local recipients:
Postfix hat einen Vorteil: Man hat per default nur zwei Config dateien!
Außerhalb dieser Dateien existieren nur noch die LDAP Abfragen und die Zertifikate, die aber innerhalb der beiden referenziert sein müssen.
Wichtige Kommandos sind:
postqueue -p
: Zeigt die in der Queue hängenden Mails an; -f
versucht die Mails erneut zuzustellengrep -Ev „status=deferred“ /var/log/mail.log | grep „delay=[0-9][0-9]“
: Zeigt alle mit einer Verarbeitungsdauer von >9s wegen Versandproblemen an. Das war auf dem alten Mailserver sehr kritisch.less /var/mail/mail.log
und less /var/mail/mail.err
zeigt die Logs von Postfix und Dovecot an
Alle Logs wandern nach /var/mail/mail.log
oder /var/mail/mail.err
.
Alle zentralen configs sind in /etc/dovecot
zuhause. Jedoch liegen die einzelnen Konfigurationen verstreut in den einzelnen Dateien unter /etc/dovecot/conf.d/
.
Sehr nützlich ist der Befehl doveconf
, der die aktuelle Konfiguration anzeigt. Mit grep
kann man dann schnell nach der gewünschten Stelle suchen. Sollte man dann die Config ändern wollen muss man sich mit egrep „suchbegriff“ ./conf.d/* -R
die Stelle angeben lassen. Die Optionen -A5 -B5
zeigen zusätzlich 5 Zeilen darüber und darunter an, um den Kontext zu verstehen.
Alle Logs wandern nach /var/mail/mail.log
oder /var/mail/mail.err
.
Eine sehr ausführliche Doku findet sich auf der offiziellen Seite: Dovecot Wiki
Sollte man im Internet nach etwas suchen und im Dokuwiki landen, achte darauf, dass du im neuen Wiki bist (Wiki2). Stand 03.2016
ACLs steht für Access Control Lists.
Gespeichert werden die Werte im LDAP, jedoch muss nach einer Änderung das Skript /root/admintools/set_imap_acls auf dem Mailserver ausgeführt werden.
Config Dateien sind mittels egrep „acl“ /etc/dovecot/* -R -A3 -B3
zu suchen.
Gute Dokumentation: Dovecot ACLs
Wieder müssen wir zwei Komponenten abdecken: User und Listen.
Beim Zustellen wird der Namespace nur für Listen verwendet. D.h. wenn eine Mail an eine Liste geht, so wird sie mit den User „lists“ zugestellt. Dabei wird dann auch die Mailbox spezifiziert mit Bsp: lists.admin Für einen User würde sie an diesen gehen, mit der Mailbox INBOX.
lists.admin ist als Namespace definiert:
D.h. es wird unter /etc/dovecot/conf.d/10-mail.conf
festgelegt, wo Mails gespeichert werden, die an lists.admin gehen sollen.
Das lists.admin statt des Speicherpfades wird später auch vom IMAP Programm verwendet.
Die Konfiguration ist in der /etc/dovecot/conf.d/10-mail.conf
zu finden.
Gute Dokumentation: Namespaces
Sieve Scripts können unter anderem über Roundcube (Webmailer) erstellt werden.
In den Index Files wird unter anderem gespeichert, ob der User die Mail schon gelesen hat. Das ist wichtig! Für User liegen diese Files natürlich in den entsprechenden Ordnern. Für Listen müssen diese Files auch bei diesen Usern liegen. Sonst würde die Mail als gelesen markiert werden, sobald sie der erste gelesen hat.
Das größte Problem ist, dass Dovecot nur die Index Files für den aktuellen Namespace speichern kann oder sonst für den übergeordneten.
Bsp: Angenommen man hat einen Namespace prefix=INBOX.
und einen prefix=lists.
(Seperator (der Punkt) am Ende ist nötig!).
Wenn man jetzt dem Namespace lists nicht die Indexfiles setzt, so muss man auch noch einen prefix= (leer) vorhanden sein.
Dieser Namespace gibt dann an, wo die Indexfiles gespeichert werden sollen. Da wir Sie in unserem Fall beim User (pro User) speichern wollen, muss das ein Namespace sein, der auf die Usermails und Indexfiles zeigt.
Wenn man also die Indexfiles nicht auf den aktuellen Namespace speichert, so muss man Sie eine Ebene höher speichern. Es ist nicht möglich anzugeben, in welchen Namespace man welche Indexfiles speichern will. Das muss über die Hierarchie geschehen.
Der User lists hat auch ein sieve script. Dieses Prüft auf den Spam-Level, der vom LRZ gesetzt wird. Mails mit zu hohem Spamlevel
/etc/dovecot/conf.d/10-mail.conf
zu finden.
Die Quotainformationen der User sind im LDAP gespeichert. Dovecot ist so eingestellt, dass jeder User per default 100MB Quota hat. Das Quota aus dem LDAP überschreibt dann diesen Wert. Der User „lists“ hat ein Quota von 0, was also unbegrenzt bedeutet.
Die Konfiguration ist in der /etc/dovecot/conf.d/90-quota.conf
zu finden. Jedoch wird das Plugin dafür an anderen Stellen aktiviert.
Weitere Informationen zum Quota findet man unter: Dovecot - Quota und Dovecot - Quota Configuration
Es wurde versucht das aufzusetzen, und dazu ein Skript unter /usr/local/bin/quotawarning
angelegt.
Das Skript läuft, aber dovecot schickt keine Quota Warnings.
Sieve Scripts können unter anderem über Roundcube erstellt werden.
Der User lists hat auch ein sieve script. Dieses Prüft auf den Spam-Level, der vom LRZ gesetzt wird. Das Sieve-Skript liegt unter eve:/home/quota2/lists/.dovecot.sieve
und leitet die Mails ggf. an admin.spam@fs.ei.tum.de weiter. Der Absender bekommt (per Vacation-Meldung) eine Antwort, dass er uns am Arsch lecken kann…
Zur Anmeldung muss der Benutzername mit dem Benutzerpasswort verwendet werden. Wäre es möglich, sich auch mit dem Mailalias anzumelden, dann könnte man ein einfachere Konfiguration schaffen. Thunderbird und andere Programme testen automatisch bei der Einrichtung, ob das was vor dem @-Zeichen steht auch als Benutzername funktioniert. Da man seine Mails aber mit vorname.nachname@fs.ei.tum.de verschicken soll, muss noch seinen FSEI-Benutzernamen separat eintragen.
Alternativ könnte man eine Autoconfig von Thunderbird (autoconfig.fs.ei.tum.de stellt ein XML-File mit der Default Config bereit) einrichten.
Nettes HowTo, was unter anderem die Problematik anspricht: https://skrilnetz.net/setup-your-own-mailserver/
Unsere Konfiguration sieht so aus:
DNS-Server:/etc/bind/gen-zonefiles
)Mailserver:/etc/opendkim/KeyTable
default._domainkey.mail.fs.ei.tum.de mail.fs.ei.tum.de:default:/etc/opendkim/default.private default._domainkey.mail.fsei.de mail.fsei.de:default:/etc/opendkim/default.private default._domainkey.mail.beste-fachschaft.de mail.beste-fachschaft.de:default:/etc/opendkim/default.private default._domainkey.mail.galeriefest.de mail.galeriefest.de:default:/etc/opendkim/default.private
Mailserver:/etc/opendkim/SigningTable
*@fs.ei.tum.de default._domainkey.mail.fs.ei.tum.de *@fsei.de default._domainkey.mail.fsei.de *@beste-fachschaft.de default._domainkey.mail.beste-fachschaft.de *@galeriefest.de default._domainkey.mail.galeriefest.de
/usr/local/bin/mailrestart
, dass Postfix und dovecot restartet (nützlich aber nicht notwendig…)