Die hier vorgestellten Konfigurationen werden bzw. wurden mit Exim4 unter Debian 3.1 (Sarge/stable)
eingesetzt (Paket exim4-daemon-light, Exim-Version 4.50). Hierbei wird die Debian-eigene
Verwaltung der Konfigurationsdateien verwendet, d.h. die Änderungen wurden in den entsprechenden
Dateien unter /etc/exim4/conf.d/ vorgenommen. Bei Verwendung der "non-split"-Konfiguration
ist anschließend noch das Skript /usr/sbin/update-exim4.conf.template auszuführen, welches
die Datei /etc/exim4/exim4.conf.template neu erstellt. Dieses Template dient schließlich – zusammen
mit den Werten aus /etc/exim4/update-exim4.conf.conf – dem Erzeugen der eigentlichen
Exim-Konfigurationsdatei, welche unter /var/lib/exim4/config.autogenerated abgelegt und
– falls erforderlich – bei jedem Start von Exim automatisch aktualisiert wird.
Dieses auf den ersten Blick reichlich kompliziert wirkende System ermöglicht jedoch eine robuste
Konfiguration, die auch bei Paket-Upgrades mit wenigen Benutzereingaben auskommen dürfte.
Die vorgeschlagenen Konfigurationen sollten allerdings auch – evtl. mit kleineren Anpassungen – mit allen anderen Distributionen verwendbar sein.
Die Exim4-Dokumentation [spec.txt.gz] beschreibt in Abschnitt 46.6 beispielhaft die Verwaltung
"virtueller Domains". Dabei wird zwischen den beiden folgenden Typen unterschieden:
Soll Exim als Backup-MX einer bestehenden Domain konfiguriert werden, so wird normalerweise
der entsprechende Domainname unter dc_relay_domains in der update-exim4.conf.conf
eingetragen. Dadurch nimmt Exim sämtliche Mails, die an Benutzer dieser Domain adressiert sind, an und leitet
sie anschließend an einen der anderen im DNS eingetragenen MX-Handler der Domain weiter. Um
Mail-Loops (endloses wechselseitiges Weiterleiten zwischen zwei oder mehr Mail-Servern) zu verhindern,
werden hierbei nur Hosts mit höherer Priorität berücksichtigt.
Falls nun der local part einer Empfängeradresse ungültig ist, wird die Mail trotzdem zunächst angenommen und in der Queue abgelegt. Da jedoch (spätestens) der Primary-MX die Mail wegen des ungültigen local parts ablehnt, wird eine Bounce-Mail erstellt, um den ursprünglichen Absender über den Fehler zu informieren. Dies kann jedoch u.U. – beispielsweise durch Spam – den anfallenden Traffic und die Last auf den Mailservern stark erhöhen. Auch sollen bereits Spammer durch Fälschen der Absenderadresse solche Bounces gezielt ausgenutzt haben, um ihren Müll zuzustellen.
Es ist also wünschenswert, dass auch die Backup-MX-Hosts Mails an in der jeweiligen Domain ungültige local parts direkt ablehnen und somit keine Bounces produzieren müssen. Exim bietet hierzu die Möglichkeit, den Backup-MX "callouts" durchführen zu lassen: dabei wird bei jeder eingehenden Mail zunächst der Primary-MX befragt, ob der local part gültig ist, und die Mail ggf. direkt abgewiesen. Diese Methode versagt jedoch bei nicht verfügbarem Primary-MX – und gerade in solchen Fällen soll ja der Backup-MX zum Einsatz kommen.
Um dieses Problem zu lösen, muss also auch jeder Backup-MX Informationen über die jeweils gültigen
local parts bekommen. Durch Verwendung der hier vorgeschlagenen Konfigurations-Erweiterung kann zu diesem Zweck
für jede weiterzuleitende Domain eine Datei ("Domainfile") unter /etc/mail/relay/ angelegt werden,
in welcher die erlaubten Empfängeradressen aufgelistet werden. Das Format dieser Dateien entspricht dabei
exakt demjenigen, welches zur Konfiguration der virtuellen Domains unter /etc/mail/virtual/
zum Einsatz kommt – es wird einfach in jeder Zeile der Teil rechts des Doppelpunkts ignoriert. Somit
können die Domainfiles auf Wunsch automatisch zwischen allen beteiligten Servern repliziert werden und
es entsteht kein zusätzlicher Administrations-Aufwand beim Hinzufügen oder Löschen von Mailadressen.
Abgesehen von der zusätzlichen Prüfung der local parts werden die über diesen Mechanismus konfigurierten
Domains genauso wie die in der update-exim4.conf.conf unter dc_relay_domains
eingetragenen Relay-Domains behandelt. Sie werden daher ebenfalls zu der entsprechenden Liste
+relay_to_domains hinzugefügt:
domainlist checked_relay_domains = \
${if exists{/etc/mail/relay}{dsearch;/etc/mail/relay}{}}
domainlist relay_to_domains = MAIN_RELAY_TO_DOMAINS : +checked_relay_domains
Der einzige Unterschied gegenüber den dc_relay_domains besteht in einem zusätzlichen ACL-Statement,
welches das Prüfen des local parts übernimmt:
# Deny if the address is in a checked relay domain (/etc/mail/relay/$domain # exists) and the local part cannot be verified. The case of failed routing is # handled by the next ACL statement (reports unroutable address in that case). deny domains = +checked_relay_domains message = unknown user !local_parts = lsearch;/etc/mail/relay/$domain
Diese ACL muss vor der "accept domains = +relay_to_domains"-ACL durchlaufen werden. Sie sorgt
dafür, dass Mails an undefinierte local parts direkt mit "unknown user" abgewiesen werden.
Bei falscher Konfiguration des Routings kann eine Mail jedoch auch bei korrektem local part trotzdem noch
abgewiesen werden – je nach Einstellung von CHECK_RCPT_GIVE_UNKNOWN_USER ebenfalls mit
"unknown user" oder mit "unrouteable address" (entsprechend dem Verhalten bei den
dc_relay_domains).
Anmerkung: im Sinne einer übersichtlichen und wartbaren Konfiguration sollten sämtliche Prüfungen, ob
eine eingelieferte Mail angenommen oder abgewiesen wird, nicht in den Routern, sondern bereits innerhalb
der ACLs vorgenommen werden
[1].
Wenn man die vom Debian-Konfigurationsmodell erzeugte Datei jedoch näher betrachtet, so stellt man fest,
dass dort sämtliche Prüfungen von local parts gerade nicht in den ACLs, sondern in den Routern stattfinden
(siehe Router system_aliases, hub_user, ..., und schließlich local_user).
Dies ist jedoch darauf zurückzuführen, dass hier das Verhalten der Router ebenfalls vom local part abhängt:
Weiterleitung an eine andere – lokale oder entfernte – Mail-Adresse, Auswertung der .forward,
.procmailrc usw., oder lokale Zustellung. Daher kann auf eine explizite Prüfung innerhalb der
ACLs verzichtet werden und stattdessen mittels verify = recipient die Router dazu veranlasst
werden, zunächst die Gültigkeit des local parts festzustellen (siehe Exim4-Dokumentation: spec.txt.gz,
Abschnitt 39.30). Im Unterschied dazu ist das eigentliche Routing für die +checked_relay_domains
völlig unabhängig vom local part, sodass hier eine explizite Prüfung innerhalb der ACL die saubere Lösung
darstellt.
Wird ein Mailserver hinter einem NAT-Gateway in einem lokalen Netz betrieben, so stimmt sein Hostname im Allgemeinen nicht mit dem Namen überein, über welchen er von außerhalb des lokalen Netzes erreicht werden kann.