Der Prima-Mailcluster besteht aktuell aus [[Prima/marcy|marcy]], [[Prima/jefferson|jefferson]] und [[Prima/ted|ted]]. Die Konfiguration für alle drei Systeme wird zentral auf [[Prima/kelly|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 [[Prima/ted|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 [[http://www.exim.org/exim-html-4.50/doc/html/spec_39.html#SECT39.31|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 [[http://www.exim.org/exim-html-4.50/doc/html/spec_39.html#SECT39.31|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: * uucp:sitename: Zustellung via UUCP an die Site sitename * bsmtp:sitename: Zustellung via BSMTP an die Site sitename * pop3:sitename: Zustellung via POP3 an die Site sitename * forward:adr: Zustellung via Forward an die Mailadresse adr. Die Auswertung der Adresse erfolgt wie in /etc/aliases, dadurch ist zB auch ''forward::fail: User unknown'' (permanent ablehnen), ''forward::defer: Mailbox unavailable'' (temporaer ablehnen, zB bei nicht zahlender Site) oder ''forward::blackhole:'' (Mail annehmen und wegschmeissen) möglich. === 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: * explizites Host/IP-Whitelisting in whitelist-hosts * automatisches Whitelisting für den einliefernden Host, wenn das Tupel (Sendehost,Sendeadresse,Empfängeradresse) unabhängig vom Clusterhost auf dem es landet innerhalb von 24 Stunden wiederholt wurde (Mindestwartezeit 5 Minuten) * Whitelisting-Einträge die 30 Tage nicht benötigt wurden werden entfernt == 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) == * Fallback zu amavis auf steve * mxhosts/handbetrieb/sendonly/send-aliases ist unelegant, vereinfachen oder wenigstens sinnvoller benennen