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

• DOVECOT
  • ACLs
  • Quota
  • Sieve und ManageSieve
• POSTFIX Postfix Config Params List
  • SMPT Server
  • Alias Fetching aus Ldap
• Custom Shit
  • Weiterleitungen
  • Listenzustellung
  • Helper Scripts
    • Dirty Shit Script

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:

• New mailinglist script: Zum Anlegen neuer Mailinglisten
• Set Imap ACLs: Zum Setzen der IMAP ACLs (nach Veränderungen am LDAP bezgl. fseiProtectedList oder uid unter ou=Listen)
• Alias Skript: Wird von cron jede Nacht ausgeführt und parsed in das LDAP die neuen Aliases (Das LDAP als Cache…)
• Mail Quota erhöhen

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):

• 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.

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 zuzustellen
• grep -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.

• 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

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.

Mail Quota erhöhen

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:

• 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

• Es gibt ein Skript unter /usr/local/bin/mailrestart, dass Postfix und dovecot restartet (nützlich aber nicht notwendig…)
• DKIM und DMARC beachten! Installationsanleitung: https://skrilnetz.net/setup-your-own-mailserver/
• 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.