Der Prima-Mailcluster besteht aktuell aus marcy, jefferson und ted. Die Konfiguration für alle drei Systeme wird zentral auf kelly erstellt und via ssh auf die Rechner verteilt.

exim-Konfiguration

Das gemeinsame Konfigurationsfile ist kelly:/root/mailconfig/exim4.conf-cluster, durch das im gleichen Verzeichnis liegende Makefile wird die Datei in die Teile für die drei Rechner gesplittet und weiterverteilt. Die exim-Konfiguration von updatemailconfig auf den beteiligten Hosts übernommen, daher können Änderungen nur aktiv werden wenn wirklich eine neue Mail-Konfiguration vorliegt.

Auf ted muss mindestens exim 4.54 eingesetzt werden, da der fallback_hosts-Eintrag, der Mails bei nicht reagierendem amavis ohne Scan weiterleitet eine Portnummer braucht.

Mail-Konfiguration

Als Mail-Konfiguration wird hier die Sammlung von Konfigurationsdateien beschrieben, die das Mailrouting innerhalb von Prima beschreiben. Abgesehen vom hostspezifischen /etc/aliases ist diese auf allen beteiligten Systemen identisch.

Die Mailkonfiguration wird im täglichen Generator-Cronjob auf kelly von mk.mail.cluster erzeugt, die Systeme im Cluster prüfen alle 5 Minuten ob eine neue Konfiguration vorhanden ist und aktivieren diese ggfs. Damit es dabei nicht zu Mail-Loops kommt (zB Alias-Umstellung von UUCP auf POP3, Übernahme durch steve vor kelly) läuft auf allen beteiligten Systemen openntpd zum Zeitabgleich.

Alle automatisch generierten Dateien werden zwecks schnellerem Zugriff auf den Clusterhosts in eine dbm-Datenbank gewandelt, ein Makefile dafür liegt jeweils in /etc/exim4.

Details zu den einzenen Dateien:

sendonly

sendonly enthält alle Hosts, die zwar Mail im Cluster einliefern müssen, aber für die der Test ob die Absenderadresse zustellbar wäre fehlschlägt. Dies sind beispielsweise alle Hosts die steve und/oder kelly als MX eingetragen haben, für die aber ansonsten keine Routinginformationen vorhanden sind - seven.prima.de ist so ein Fall, von dort gehen Statusmails an die Adminliste.

Format: Hostnamensliste, einer pro Zeile

send-aliases

Alias-File für die Hosts die in sendonly eingetragen sind. Da die von ihnen abgeschickten Mails potentiell mit Bounces oder Statusmails beantwortet werden könnten wurde dieses Aliasfile angelegt damit diese nicht tagelang in der Quele rumliegen bis sie verworfen werden. Ausserdem ist es guter Stil (sowie RFC-konform) wenigstens postmaster@host annehmen zu können.

(Ja, das ist ein ziemlich mieser Hack und es sollte mindestens der Dateiname auf etwas sinnvolleres geändert werden.)

Format: Wie ein klassisches /etc/aliases, aber mit Domainnamen in den Adressen. *@domain geht, * wird als allerletztes Fallback verwendet wenn kein Eintrag gefunden wird.

handbetrieb

Ursprünglich zum Nachbau einer Speziallösung aus Postfix-Zeiten gedacht, inzwischen für einige weitere Hosts verwendet - handbetrieb routet alle Mails an eine Domain blind an einen angegebenen Host weiter. Die Speziallösung war ursprünglich dafür gedacht, alle Mails einer Site erst durch den Mailscanner zu schieben bevor sie an einen Site-spezifischen MX weitergeleitet werden, inzwischen ist aber beispielsweise auch bud dort eingetragen, der Mails an sich zwar selbst verarbeitet, aber für sich als MX mit geringster Priorität eingetragen ist.

kelly, steve und ted stehen mit sich selbst als Ziel in dieser Datei, damit es egal ist in welcher Reihenfolge sie fuer sich selbst als MX eingetragen sind. Findet sich einer der Clusterhosts selbst als Ziel in handbetrieb wird die Mail regulär bearbeitet und nicht etwa eine Schleife produziert.

Für hier eingetragene Hosts wird Callout-Verification benutzt um nur Mails anzunehmen die der Zielserver auch annehmen würde. Bei temporären Fehlern des Zielservers wird die Mail auch angenommen.

Format: domain: zielhostname

mxdomains

Liste aller Domains fuer die der Cluster MX sein soll. Die Clusterhosts stehen ebenfalls in dieser Datei, damit die Rechner untereinander MX fuer sich sein koennen. Mails an hier eingetragene Hosts werden an einen MX weitergeleitet, der die niedrigste numerische Priorität hat die kleiner als die des Clusters ist und ausserdem erreichbar ist. (d.h. ganz normales Mailrouting anhand der MXe). Ist der Cluster der MX mit numerisch niedrigster Priorität, obwohl die Mail eigentlich an einen anderen Host weitergeleitet werden soll muss stattdessen ein Eintrag in handbetrieb vorgenommen werden.

Format: domain: zielhostname

mxdomains

Liste aller Domains fuer die der Cluster MX sein soll. Die Clusterhosts stehen ebenfalls in dieser Datei, damit die Rechner untereinander MX fuer sich sein koennen. Mails an hier eingetragene Hosts werden an einen MX weitergeleitet, der die niedrigste numerische Priorität hat die kleiner als die des Clusters ist und ausserdem erreichbar ist. (d.h. ganz normales Mailrouting anhand der MXe). Ist der Cluster der MX mit numerisch niedrigster Priorität, obwohl die Mail eigentlich an einen anderen Host weitergeleitet werden soll muss stattdessen ein Eintrag in handbetrieb vorgenommen werden.

Diese Datei wird erst relativ spät im Routing ausgewertet, wenn die zu routende Adresse lokal für einen Rechner ist oder die Domain schon in memberdomains eingetragen ist ist ein Eintrag in mxdomains unerheblich da das Routing schon vorher beendet wird.

Für hier eingetragene Hosts wird Callout-Verification benutzt um nur Mails anzunehmen die der Zielserver auch annehmen würde. Bei temporären Fehlern des Zielservers wird die Mail auch angenommen.

TODO Eventuell fuer den Fall einer Vanity-Domain mit eigenem MX ermöglichen, den Cluster als Backup-MX zu verwenden? Dann müsste diese Datei allerdings auch autogeneriert werden.

Format: Ein FQDN pro Zeile, #-Kommentare möglich

whitelist-hosts

Liste der Hosts für die kein Greylisting vorgenommen wird. Einige Mailserver sind leider etwas kaputt und interpretieren 451 als "Permanent unzustellbar" und werfen die Mail weg statt es später nochmals zu versuchen. Andere werden zur Dupeschleuder. Der Inhalt der Datei stammt grösstenteils von http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt - dort werden Netze allerdings als verkuerzte IP angegeben (1.2.3), für Verwendung in exim muss das in Subnet-Notation (1.2.3.0/24) umgeschrieben werden.

Format: Ein Eintrag pro Zeile, #-Kommentare möglich. Als Eintrag kann eine IP, eine Netzangabe, ein Hostname (auch mit *) oder eine Regular Expression (auf jeden Fall mit ^ am Anfang) dienen.

quotaignore

Liste der Envelope-Froms, deren emails auch an die Mitglieder zugestellt werden, deren Quota erreicht oder überschritten ist.

Format: Ein Eintrag pro Zeile, #-Kommentare möglich. Als Eintrag kann eine email-Adresse oder eine Regular Expression (auf jeden Fall mit ^ am Anfang) dienen.

primaaliases

Alias-File für Adressen unter prima.de. Die Domain prima.de (und die identisch dazu behandelte Domain prima-dyn.de) ist rein virtuell, alle Adressen die darunter gültig sein sollen müssen in dieser Datei eingetragen sein. Der grösste Teil der Datei, die Aliase für Sites und Mitgliedernamen wird von mk.mail.cluster automatisch generiert, zusätzliche statische Einträge sind über das Template kelly:/etc/templates/primaaliases.tmpl möglich.

Format: Wie /etc/aliases

memberdomains

Liste aller Domains der Mitglieder und Routinginformationen falls diese Catchall sind. Falls eine Mitgliederdomain kein Catchall verwendet muss die Domain trotzdem in memberdomains eingetragen sein, allerdings mit einem leeren Ziel. Die Datei wird erst nach allowedaddresses ausgewertet, dadurch können bei einer Catchall-Domain trotzdem einzelne Adressen anders geroutet werden.

Format: domain: ziel, wobei ziel auch leer sein darf (der Doppelpunkt muss bleiben); #-Kommentare möglich.

Ziel gibt an wie eine Mail an diese Domain zuzustellen ist, mögliche Varianten sind:

allowedaddresses

Alias-File für Domains im memberdomains. Die Datei enthält alle Einträge die in der Email-Verwaltung vorgenommen wurden und gibt für diese an, wohin Mails an die jeweilige Adresse geroutet werden sollen. Im Fall einer Nicht-Catchall-Domain ist ausserdem ein *@domain-Eintrag vorhanden, der Mails an nicht angegebene Adressen ablehnt.

Format: foo@bar: ziel; #-Kommentare möglich

Ziel hat das gleiche Format wie bei memberdomains, Leereinträge sind aber nicht möglich (genauer: nicht sinnvoll). Bei der Mailadresse kann auch * als localpart verwendet werden, das matcht beliebige Localparts in der Domain. Matching auf beliebige Subdomains geht nicht.

sitenames

Liste aller aktuell gültigen Sitenames. Wird an einigen Stellen verwendet um gültige localparts in Mailadressen zu finden.

Format: Ein Sitename pro Zeile, #-Kommentare möglich

Internes Routing

marcy und jefferson leiten alle Mails, die nicht von marcy, jefferson oder ted via SMTP eingeliefert wurden an ted weiter. Sollte ted.prima.de nicht auflösbar sein wird die Mail regulär weiterverarbeitet. Sollte ted nicht erreichbar sein, leiten marcy und jefferson die Mails jeweils an den anderen Host weiter.

Auf marcy werden ausserdem alle Mails die vom User majordomo eingeliefert werden nicht an ted weitergeleitet, da angenommen wird das diese schon gescannt wurden.

ted leitet alle Mails, die keine der Bedingungen "kommt auf Port 10025 an", "wurde mit Protokoll 'spam-scanned eingeliefert" und "ist älter als 7200 Minuten" an den lokal laufenden amavis-Daemon auf Port 10023 weiter. Ist dieser nicht erreichbar wird die Mail auf Port 10025 eingeliefert und dadurch als schon gescannt behandelt.

Nach dem Spam-Scan werden die Mails entsprechend der obigen Konfigurationsfiles behandelt; Mails mit POP3-Ziel landen auf marcy, Mails mit UUCP-Ziel auf jefferson.

Greylisting

Das Prima-Greylisting ist eine Eigenbaulösung mit mysql-Backend auf ted. Ist die Datenbank nicht erreichbar (was über ein "SELECT 1" getestet wird), wird die Mail auf jeden Fall angenommen.

Eckdaten:

Quota

Für POP3-Postfächer existiert ein Quotasystem. Auf marcy läuft auf Port 666 ein Daemon, der auf die Anfrage 'GETQUOTA sitename' den aktuellen Quota-Status für den abgefragten Sitenamen zurückliefert.

Damit Mails an Über-Quota-User sich nicht auf den Prima-Systemen anhäufen (und damit effektiv die Quota erhöhen) existieren die quotatest-Router in der Exim-Konfiguration. Diese fragen mittels getquota.pl die Quota der betroffenen Site ab und geben dem einliefernden System schon beim 'RCPT TO' ein '451 Quota exceeded' zurück damit die Mail nicht bei uns eingeliefert wird sondern vorläufig auf dem sendenden System verbleibt.

postmaster-only

Einige bei Prima gehostete Domains (robin.de, uucp.prima.de) werden eigentlich nicht selbst für Mail verwendet, sollten aber aus Gründen des guten Stils trotzdem wenigstens eine Postmaster-Adresse haben. Dies wird durch den our_postmasters-Router sichergestellt, der Mails an postmaster@<diese domains> an postmaster@prima.de weiterleitet.

TODO (Mailsystem)

Prima/Mailcluster (zuletzt geändert am 2014-12-28 15:37:53 durch BodoBellut)