Workshop: Sendmail kämpft gegen Spam und Viren

Gezähmtes Monster

von Hannes Kasparick

Erschienen im Linux-Magazin 2006/05

Sendmail gilt zu Unrecht als nicht beherrschbares Ungetüm - dieser Workshop beweist es. Etwas strukturierte Arbeitsweise vorausgesetzt können Sie mit dem Oldie unter den MTAs flexible und wirksame Antispam- und Antivirenlösungen aufbauen.

Wer ein echter Unix-Administrator sein will, muss einmal in seinem Leben Sendmail konfiguriert haben - wer es ein zweites Mal tut, ist verrückt. Solche Sprüche sind lustig, verkennen aber die Realität. In mehr als 20 Jahren Entwicklungszeit (siehe Kasten "Sendmails Geschichte") ist Sendmail [1] zu einem robusten und zuverlässigen Mail Transport Agent (MTA) herangewachsen, für den es viele Zusatzprodukte und Addons gibt.

Sendmails Geschichte

1981 benannte Eric Allman [4], Mitarbeiter an der University Berkeley, seine Arpanet-Software Delivermail in Sendmail um. Zu dieser Zeit war Allmans Software der einzige verfügbare MTA. Im Laufe der Jahre entstanden Versionen mit unterschiedlichen Features und inkompatiblen Konfigurationen. Das 1992 erschienene Sendmail 8.0 vereint dagegen die besten Eigenschaften der Sendmail-Versionen von IDA, KJS, Sun und HP und orientiert sich an den Standards der Internet Engineering Taskforce (IETF).

In den folgenden Jahren erweiterten die Entwickler den MTA laufend um die Fähigkeiten, die das moderne Internet erfordert. Als er Berkeley verließ, gründete Allman 1998 Sendmail Inc. [5]. Die Firma bietet kommerziellen Support und Erweiterungen. Zum Redaktionsschluss aktuell war Sendmail 8.13.5.

Trotz seiner komplizierten und teilweise unorthodoxen Konfiguration hielt Sendmail seine Position als meistverbreiteter MTA im Internet, wenn auch zunehmend bedrängt durch Postfix, Qmail und Exim. Zu negativer Berühmtheit kam Sendmail durch kritische Sicherheitslücken in den Jahren 1996 und 2003. OpenBSD, das als sehr sicheres Betriebssystem gilt, setzt Sendmail trotzdem als Standard ein. Die Entwickler schätzen, dass der Sendmail-Quellcode sehr gut untersucht ist und dass die früheren Probleme von Sendmail auch Postfix und anderen noch bevorstehen.

Dieser Artikel erläutert neben der sicheren Grundkonfiguration auch drei praktikable Antispam- und Antivirus-Szenarien. Am Schluss diskutiert er ein viertes, radikales Szenario, bei dem das Spam-Aufkommen auf praktisch null absinkt. Die vollständigen Konfigurationsdateien sind unter [2] abrufbar.

Vorspeise

Stellvertretend für andere Distributionen benutzt dieser Workshop Debian 3.1 Sarge, die Unterschiede zu anderen Linux-Systemen sind marginal. Die zentralen Komponenten zum Versand von E-Mails installieren Sie mit »apt-get install sendmail sasl2-bin libsasl2-dev«. Die Installationsroutine gibt dabei Hinweise für die weitere Konfiguration, der Kasten "Sendmail-Konfiguration" ebenso.

Sendmail-Konfiguration

Vor Beginn der Installation sollten Sie sicherstellen, dass in »/etc/hosts« der Hostname des Servers nicht in einer Zeile mit »127.0.0.1« steht - hier gehört ausschließlich »localhost« hin. Alle Konfigurationsdateien befinden sich in »/etc/mail«. Sie ändern immer die »*.mc«-Dateien und übersetzen sie danach in »*.cf«-Konfigurationsdateien. Das passiert im einfachsten Fall mit »sendmailconfig«.

Die »*.cf«-Dateien editieren Sie nicht, da sie jede Neugenerierung überschreiben. Optionen in den »*.mc«-Dateien werden durch den Backtick »`« (neben der [Backspace]-Taste) eingeleitet und mit einem einfachen Anführungszeichen beendet. Was hinter »dnl« (do new line) steht, ignoriert Sendmail.

Um kein Open Relay für Spam-Versender zu schaffen, stellen Sie Sendmail so ein, dass es nur Mails versendet, wenn ein Benutzer sich authentisiert hat. (Andere Restriktionen, die beispielsweise das Versenden von E-Mails an eine IP-Adresse binden, sind natürlich auch möglich.) Zuständig für die Authentisierung ist der Saslauthd [3]. Um ihn dauerhaft zu aktivieren, setzen Sie in »/etc/default/saslauthd« den Parameter »START=yes«. Danach lässt er sich mit »/etc/init.d/saslauth start | stop | restart« steuern.

Um Fehlkonfigurationen in Sendmail schneller zu erkennen, lohnt es, den Loglevel in der »sendmail.mc« zu erhöhen: »define(`confLOG_LEVEL\',`15\')dnl«. Fehlermeldungen gibt Sendmail normalerweise in »/var/log/syslog« beziehungsweise »/var/log/mail.info« aus. Um die SMTP-Authentisierung zu aktivieren, führen Sie - wie es das Installationsprogramm vorschlägt - »/usr/share/sendmail/update_auth« aus und tragen »include(`/etc/mail/sasl/sasl.m4\')dnl\'« in die »sendmail.mc« ein.

Von Haus aus ist Sendmail nur am Loopback-Interface 127.0.0.1 aktiv. Um E-Mails auch von anderen Clients aus verwenden zu können, müssen Sie Sendmail an eine externe IP-Adresse binden. Dazu ersetzen Sie »127.0.0.1« durch die echte IP-Adresse des Mailservers »\'DAEMON_OPTIONS(`Family=inet, Name=MSP-v4, Port=submission, Addr =IP-Adresse \')dnl\'«.

Danach muss der Administrator die Konfigurationsdateien durch den Aufruf »sendmailconfig« neu generieren. Beim ersten Start gibt es einige Start-TLS-Fehlermeldungen, die beseitigen Sie später. Ob alles bis hierhin funktionsfähig ist, überprüfen Sie leicht mit Telnet:

Wenn alle Einstellungen korrekt sind und Sie Sendmail neu gestartet haben, antwortet der Server mit: »Relaying denied. Proper authentication required.«

Gut gesichert verschicken

Bevor der Benutzer E-Mails versendet, muss er sich mit Benutzernamen und Kennwort authentisieren. Der Prozess sollte unbedingt verschlüsselt ablaufen, um Passwortmissbrauch zu verhindern. »include(`/etc/mail/tls/starttls.m4\')dnl« aktiviert den Start-TLS-Mechanismus und »define(`confCRL\', `/etc/mail/tls/revocation.list\')dnl« definiert eine Widerrufsliste für Zertifikate. Die Widerrufsliste legen Sie mit

an und schützen sie gegen unbefugte Zugriffe. Die SSL-Zertifikate sollten auf jeden Fall von einer vertrauenswürdigen Certificate Authority unterschrieben sein, um Fehlermeldungen im E-Mail-Client und damit das Abstumpfen der Benutzer gegenüber Sicherheitsmaßnahmen zu verhindern.

Die vertrauenswürdige CA kann auch organisationsweit sein, dann muss allerdings das Root-Zertifikat auf jedem Client installiert sein. Um zu überprüfen, ob die Verschlüsselung funktioniert, eignet sich ein Netzwerksniffer. Normalerweise dürfen Sie dem Verschlüsselungssymbol des E-Mail-Clients aber vertrauen, beispielsweise dem Schloss.