Inhaltsverzeichnis
Beispielkonfiguration der TUM
MAILSERVER
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:
- Listen die man abbonieren kann (Shared Mailfolders)
- Fachschaftsarbeit ist ohne Listen nicht denkbar. Zustellung für jedes Postfach nicht sinnvoll (Platzbedarf).
- Sieverules über Konfigurationsdateien im Home Folder pro Nutzer beliebig Konfigurierbar
Plugins und Zusammensetzung
- DOVECOT
- Sieve und ManageSieve
- POSTFIX Postfix Config Params List
- SMPT Server
- Alias Fetching aus Ldap
- Custom Shit
- Weiterleitungen
- Listenzustellung
- Helper Scripts
Domains
Unterstützung für drei Domains ist aktuell implementiert:
mail.fs.ei.tum.de mail.fsei.de mail.beste-fachschaft.de
Wartung
Was man täglich brauchen kann:
- New mailinglist script: Zum Anlegen neuer Mailinglisten
- Set Imap ACLs: Zum Setzen der IMAP ACLs (nach Veränderungen am LDAP bezgl.
fseiProtectedList
oderuid
unterou=Listen
) - Alias Skript: Wird von cron jede Nacht ausgeführt und parsed in das LDAP die neuen Aliases (Das LDAP als Cache…)
Entscheidungen
Local oder Virtual Users?
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.
LMTP oder Pipe
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.
Aufbau
Ablauf einer Listen mail...
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.
Ablauf einer Usermail
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
Alias und Weiterleitungen
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):
- Postfix muss nur einmal eine LDAP abfrage machen. ⇒ sau schnell!
- User können durch
~/.listsForward
selbst ihre Weiterleitung einstellen! (Trotzdem sicher! Keine Injections etc.) - Bestehende Weiterleitungen bleiben erhalten, da für externe Leute sinnvoll. (LDAP-Flag: rfc822MailMember)
- fseiMailDeliverTo ist eine notwendige Möglichkeit listenmails zuzustellen. (Zustllung nicht nur an eine Liste möglich)
Arten von alias in verschiedenen LDAP-Flags abgelegt:
- listalias: mail oder cn ⇒ fseiMailDeliverTo, fseiUserForwardDoNotEdit, rfc822MailMember
- Mails können an den 'cn' name (Bsp admin) verschickt werden oder an die 'mail' alias
- Zugestellt wird dann an fseiMailDeliverTo (Zustellung lokal); an fseiUserForwardDoNotEdit (weiterleitung der Listen/wird per Skript erstellt); rfc822MailMember (externe Leute)
- useralias: mail oder uid ⇒ uid
- User kann Mails an seinen Usernamen und an seine Aliases empfangen
Arten der Weiterleitungen:
- User Forward (kann jeder User erstellen!):
~/.forward
: Weiterleitung des persöhnlichen Postfaches~/.listsForward
: Weiterleitung der Listen an den Username
- rfc822MailMember leitet eine Listenmail auch an einen User weiter (sinnvoll für externe Leute ohne FSEI Account)
- fseiMailDeliverTo: leitet eine Mail an den User lists weiter (Bsp admin → lists+admin)
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:
- Sucht einfach im LDAP nach allen ou=People, bei denen die objectClass=fseiMensch gesetzt ist (daher ist auch lists ein fseiMensch)
- Es kann nur an local recipients Zugestellt werden. Listen werden also dem User lists in den richtigen Ordner zugestellt.
Postifx
Arbeiten mit Postfix
Postfix hat einen Vorteil: Man hat per default nur zwei Config dateien!
- main.cf: Hier ist die komplette Konfiguration vorgenommen.
- master.cf: Hier sind alle Services von Postfix gelistet.
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
undless /var/mail/mail.err
zeigt die Logs von Postfix und Dovecot an
LOGGING
Alle Logs wandern nach /var/mail/mail.log
oder /var/mail/mail.err
.
DOVECOT
Arbeiten mit Dovecot
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.
LOGGING
Alle Logs wandern nach /var/mail/mail.log
oder /var/mail/mail.err
.
Dokumentation
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
ACLs steht für Access Control Lists.
- Wenn eine Liste im LDAP als fseiProtectedList=False markiert ist, dann dürfen alle User diese Liste lesen. Alle User, die unter „uid“ gelisted sind haben Schreibrechte, Löschrechte, etc.
- Wenn eine Liste im LDAP als fseiProtectedList=True markiert ist, dann dürfen nur User die unter uid gelistet sind darauf zugreifen und auch schreiben und löschen.
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
Dovecot Namespaces
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.
Index Files
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.
Quota
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
Quota Warnings
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
Sieve Scripts können unter anderem über Roundcube erstellt werden.
User: lists
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…
IMAP Login
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.
DMARC, DKIM, SPF
Nettes HowTo, was unter anderem die Problematik anspricht: https://skrilnetz.net/setup-your-own-mailserver/
Unsere Konfiguration sieht so aus:
- 1 gemeinsam genutzter Key für alle Domains (veröffentlicht in jeder Domain-Zone durch
DNS-Server:/etc/bind/gen-zonefiles
) - für jede Domain eine gesonderte Zeile in der SigningTable und der KeyTable
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
Nice to know
- Es gibt ein Skript unter
/usr/local/bin/mailrestart
, dass Postfix und dovecot restartet (nützlich aber nicht notwendig…) - IMAP-Verbindungen und master.cf beachten… Hast du kurzzeitige Verbindungsprobleme und sind viele Prozesse zu finden (pstree)? Dann muss man die Anzahl der Verbindungen erhöhen!
- Existiert ein alias/cn/uid zweimal, dann wird die Mail auch an beide/alle zugestellt…
- Öffnen einer Mail im RAW Format: Mail vom Mailserver kopieren; Dann die Endung .eml anfügen und mit Thunderbird öffnen.
Die hier im BuFaTa ET Wiki dargestellten Arbeitsdokumente sind Einzelbeiträge der jeweiligen Autoren und i.d.R. nicht repräsentativ für die BuFaTa ET als Organisation. Veröffentlichte Beschlüsse und Stellungnahmen der BuFaTa ET befinden sich ausschließlich auf der offiziellen Homepage.