Milter-Filter nach Empfänger für sendmail

Problemstellung

Sobald Netzwerke über mehrere Mail-Server bzw Rechner, die Mails akzeptieren, verfügen, existiert das Problem, dass nicht jeder Server darüber Kenntnis hat, ob eine bestimmte Mail-Adresse existiert. Eine gängige Konfiguration sieht vor, dass es einen zentralen Mail-Server gibt, der von ausserhalb des Netzwerkes, also meist vom Internet aus, erreichbar ist. Auf diesem werden die Filterungen nach Viren und Spam durchgeführt und dann werden die Mails an die entsprechenden Rechner innerhalb des Netzwerkes weitergeleitet. Der zentrale Mail-Server leitet die Mails weiter, wenn es ihm möglich ist die Domaine und/oder den Zielhost zu erreichen. An dieser Stelle ist es irrelevant und nicht überprüfbar, ob der spezifische Nutzer, an den die Mail adressiert ist, überhaupt existiert. Sollte der Nutzer nicht existieren, wird die Mail verworfen bzw eine Antwort-Mail mit dem Inhalt, dass die Adresse nicht existiert, zurückgesendet, sobald die Mail den Zielrechner erreicht. Das eigentliche Problem besteht darin, dass aufwendige Verfahren, wie z.B. Virenfilter, bereits durchgeführt wurden und den zentralen Mail-Server unnötig belastet haben. Um diesem Problem entgegenzuwirken, sollten fehlerhaft adressierte Mails bzw generierte Spam-Mails schon vom zentralen Mail-Server aussortiert werden.

Lösungsansätze

Zur Lösung des zuvor beschriebenen Problems gibt es 2 Lösungsansätze.

Lösung 1

Der zentrale Mail-Server befragt bei jeder eingehenden Mail den Zielhost, ob der adressierte Benutzer auf diesem existiert.

Vorteile:
Kein zusätzlicher Administrationsaufwand
Änderungen am Nutzerstamm werden sofort bemerkt
Nebeneffekt: Nichterreichbarkeit von Servern wird bemerkt

Nachteile:
Verzögerung der Abarbeitung der Mail (Netzwerklast, Last des sek. Servers, DNS-Abfrage, usw)

Lösung 2

Der zentrale Mail-Server befragt eine Datenbank, in der die existierende Nutzer mit den dazugehörigen Hosts und Subdomains gespeichert sind.

Vorteile:
Höhere Geschwindigkeit, vor allem wenn die DB lokal verfügbar ist
Autark von sekundären Servern
Keine Netzwerklast

Nachteile:
Erhöhter Administrationsaufwand

Entscheidung

Da die Performance im Vordergrund steht und der zusätzliche Administrationsaufwand im Verhältnis gering ausfällt, da der Nutzerstamm sich in den meisten Fällen nur gering und selten ändert, liegt es nahe die Lösung 2 zu verwenden.

Download und Installation

Download des Filters und dazugehöriger Skripte : addr-filter.tar.gz

System-Voraussetzung:
MySQL Version >=5
Sendmail mit Milter-API

Zuerst wird ein neuer Benutzer in der MySQL-Datenbank benötigt über den die Kommunikation und Administration ausgeführt wird. Als Standard wurde der Benutzer milter mit dem Passwort milter verwendet. Sollte ein anderer Benutzer verwendet werden, so muss dieses sowohl in den mitgelieferten Shell-Skripten als auch in der Konfigurationsdatei für den Filter entsprechend angepasst werden. Es stehen Makefiles für Solaris und Linux zur Verfügung. Durch das Setzen des Makros DEBUG in der Datei addr.c lässt sich der Filter im Debug-Modus kompilieren. Dies hat eine detailierte Ausgabe der Aktionen, die dieser durchführt, zur Folge. Mittels make bzw make -f makefile.solaris wird der Filter kompiliert.

In der Sendmail-Konfigurationsdatei (/etc/mail/sendmail.mc) müssen folgende Zeilen hinzugefügt werden:
INPUT_MAIL_FILTER(`addr', `S=unix:/var/run/addr.socket, T=C:2m')
define(`confINPUT_MAIL_FILTERS', `addr')

Das Einrichten der Datenbank erfolgt über das Skript db-install.sh.

Der Filter erwartet die Konfigurationsdatei /etc/mail/addr-filter oder eine beliebige Konfigurationsdatei, deren Pfad mittels Parameter -c beim Start an den Filter übergeben wird. Folgende Optionen lassen sich dort beeinflussen (in Klammern stehen jeweils die Standard-Werte):
mail_socket=unix:/var/run/addr.socket
db_host=localhost
db=addr
db_port=0
db_user=milter
db_passwd=milter

Der Filter selbst wird mittels addr gestartet und benötigt root-Rechte.

Die Konfiguration von eMail-Adressen wird mittels 3er Skripte gesteuert:
Der Benutzername und das Passwort für den Datenbank-Nutzer muss in den Skripten angepasst werden, sollte vom Standard (User:milter,Passwort:milter) abgewichen worden seien.

add_subnet:
Fügt ein Subnet/Subdomain zur Datenbank hinzu. Das Skript erwartet folgende Parameter:
-u subnet_name : Der Name des Subnetzes/Subdomain
-s subnet_group_id: Jedes Subnetz/Subdomain muss einer Gruppe zugewiesen werden, über welche intern die Verknüpfung zu Hostnamen und Benutzer durchgeführt wird.

add_host::
Fügt einen Hostnamen oder einen leeren Eintrag zur Datenbank hinzu. Leere Einträge werden in dem Fall benötigt, dass das Subnetz gleichzeitig den Zielhost spezifiziert.
-u hostname: Hostname spezifizieren
-n: leerer Hostname
-g group_id: Hosts müssen ebenfalls in Gruppen zusammengefasst werden
-s subnet_id: Zuordnung eines Host zu einer Gruppe von Subnetzen

add_user:
Fügt einen Nutzer in die Datenbank ein
-u username: Spezifiziert Nutzernamen
-g host_group_id: Ordnet den Nutzer eine Gruppe von Hosts zu