Minimal-Mailer

Um eine Anwendung auf einem Raspi eine E-Mail versenden zu lassen oder wichtige Systemnachrichten eines Root-Servers zu empfangen, muss niemand einen vollwertigen Mailserver wie Exim oder Postfix in Betrieb nehmen. Sie allein für solche Zwecke einzurichten, stellt unnötigen Aufwand dar, der obendrein komplex und fehleranfällig ist – schließlich möchte niemand eine Spam-Schleuder ins Internet stellen.

Mit Nullmailer und Ssmtp gibt es zwei Minimallösungen, die für den Versand von Systemnachrichten an festgelegte Mailadressen und auch die Weiterleitung sonstiger Nachrichten über einen Server bei einem nahezu beliebigen Provider vollends genügen. Sie nehmen übers Netz keine Nachrichten an. Dieser Artikel erklärt die Unterschiede und zeigt, wie Sie die Helfer passend konfigurieren und gleich testen.

Streuung

Einen Schritt zurück: Wenn auf einem Unix-System ein Prozess eine E-Mailnachricht schicken will, ruft er üblicherweise das Programm sendmail auf. Es erwartet einige Parameter, um die Nachricht mit Absender, Empfänger, Betreff und Inhalt zu versehen. Wie dabei die Benutzernamen von Absender- und Empfängeradressen ergänzt werden, hängt von vielen Faktoren ab, die abhängig von der eingesetzten Software erheblich streuen.

Nullmailer und Ssmtp sind darauf optimiert, Nachrichten bei einem voreingestellten SMTP-Server abzuladen (SMTP-Relay) – dazu vertraut man ihnen meist die Zugangsdaten für diesen SMTP-Server an. Außerdem schreiben sie Absender- und Empfängeradressen so um, dass die Nachrichten ankommen und nicht stranden, etwa beim Mailadmin der Firma, aus dessen Netzwerk sie versendet werden, oder sonst irgendwo.

Beide bringen ein eigenes sendmail-Kommando mit. Während Ssmtp Nachrichten direkt beim eingestellten SMTP-Server ablädt und sich sofort beendet, arbeitet Nullmailer wie ein „echter“ Mailserver: Das Programm verwendet eine Queue, in die es Nachrichten aufnimmt und die es regelmäßig abarbeitet. Entsprechend läuft dauerhaft ein Nullmailer-Prozess. Der Nullmailer-Versand ist dadurch robuster. Ssmtp eignet sich eher als Extra in Containern.

Welchen der beiden Mailer Sie auf Ihrer Distribution vorfinden, hängt vom Stall ab, aus dem sie stammt: In Systemen der Debian-Familie wie dem Raspi und Ubuntu stehen beide zur Wahl – hier ist Nullmailer der Vorzug zu geben, weil er aktuell weiterhin gepflegt wird. In Red Hats Abkömmlingen trifft man eher Ssmtp an, obwohl der ursprünglich von Debian-Entwicklern stammt. Seit 2014 wurde nichts mehr daran geändert, obwohl es Sicherheitsbedenken gibt (siehe ct.de/y1ec).

Nullmailer

Auf einem Debian-System verdrängt das Einrichten per apt-get install nullmailer einen eventuell schon vorhandenen Mailserver wie Exim. Die Paket-Installation fragt einige Parameter ab, etwa den SMTP-Server des Providers und eventuelle Anmeldedaten. Weitere Fragen kriegen Sie gestellt, wenn Sie das Paket mit dpkg-reconfigure nullmailer nochmals konfigurieren lassen.

Der volle Satz der Optionen ist erst in den Konfigurationsdateien im Verzeichnis /etc/nullmailer zugänglich, die jeweils eine Zeile enthalten: Den Inhalt der Datei „defaultdomain“ hängt Nullmailer als Domain an Hostnamen an, die keinen Punkt enthalten. Aus der Datei „defaulthost“ holt es den Hostnamen, wenn in der Standarddatei /etc/mailname nichts steht; die letztgenannte Datei sollte ohnehin tunlichst befüllt sein.

Mehrzeilig können die folgenden Konfigurationsdateien sein: In „adminaddr“ führen Sie E-Mailadressen auf, die alle Mails erhalten sollen, die an @localhost oder den in /etc/mailname abgelegten Mailnamen gerichtet sind. Das verhindert, dass Mail etwa an den Nutzer root vom SMTP-Server des Providers abgewiesen wird.

An welche Server Nullmailer liefert, steht in der Datei „remotes“: Eine Zeile startet mit dem Namen des Servers und nennt mit Leerzeichen davon getrennt die Auslieferungsart „smtp“. Es dürfen Optionen für das zum Ausliefern verwendete Backend folgen, die man durch Aufruf desselben mit Parameter herausfindet: /usr/lib/nullmailer/smtp --help. (Nullmailer unterstützt mit qmqp auch eine überholte qmail-Spezialität.)

Ein Zeile mit fiktiven Namen und Zugangsdaten:

smtp.example.com smtp --user=hans :

. --pass=wurst --starttls

Nullmailer würde Nachrichten bei smtp.example.com einliefern und dafür eine TLS-gesicherte Verbindung nutzen und sich mit AUTH PLAIN dort anmelden.

Neuere Nullmailer-Versionen (> 1.13), die leider erst in Debian-Testing zu haben sind, kennen zusätzlich die Datei „allmailfrom“. Die Angabe darin überschreibt den vollständigen Absender. Außerdem hat der Autor allerhand Ergänzungen vorgenommen, die das Programm im Fehlerfall und bei abgelehnten Zustellversuchen besser reagieren lassen. Zudem spricht es seit Version 2 auch IPv6.

Ssmtp

Nullmailers Brüderchen Ssmtp kommt mit zwei Dateien für die Konfiguration aus „ssmtp.conf“ und „revaliases“. Die erste nimmt globale Optionen auf, mit mailhub=smtp.example.com beispielsweise den SMTP-Server, bei dem Ssmtp Nachrichten abliefern soll. An die in root= hinterlegte Adresse schickt Ssmtp alle Nachrichten, die an Unix-Nutzer gerichtet sind, deren User-ID kleiner als 1000 ist.

In der Datei „revaliases“ lassen sich zeilenweise für je einen lokalen Nutzer eine Zieladresse und ein SMTP-Server hinterlegen, an die Ssmtp Nachrichten verschickt. Zugangsdaten für entfernte Server lassen sich dort allerdings nicht zusätzlich definieren. Manchmal bleibt die root=-Option augenscheinlich wirkungslos, weil bei Ssmtp mit dem Nutzernamen, etwa root, auch eine Domain ankommt. Dann hilft es, in „revaliases“ einen Eintrag für root zu hinterlegen – dann passt Ssmtp den Absender selbstständig an.

Das vom ssmtp-Paket installierte sendmail kennt diverse Optionen, um dem Aufruf auch Authentifizierungsdaten und andere SMTP-Server mitzugeben – das kann man aus Anwendungen heraus nutzen, die eine detaillierte Konfiguration für den sendmail-Aufruf erlauben. Neben Nullmailer und Ssmtp gibt es weitere Minimalmailer, die aber selten empfohlen und eingesetzt werden: msmtp wird immerhin noch gepflegt.

Improvisiere!

Leider gibt es kein Patentrezept für die Konfiguration im Detail, weil viele Variablen im Spiel sind: Nicht jeder SMTP-Server ist bereit, Nachrichten von beliebigen Nutzern an beliebige andere zu verschicken, selbst wenn sich ein dort wohlbekannter Benutzer authentifiziert hat. Auch bei der SMTP-Authentifizierung selbst gibt es diverse Spielarten: PLAIN, SSL, TLS und Port 25, 465 oder 587. Mancher Server erwartet zur Authentifizierung vollständige Namen mit Domain, andere wollen es ohne.

Letztlich hilft nur Probieren, wenn eine Suche im Internet nach dem gewählten Mailer und Mailprovider keine Treffer ergibt. Starten Sie mit einem minimalen Satz an Konfigurationsdaten und konkretisieren Sie diese nach und nach. Fangen Sie also ohne die Angabe eines Ports an. Verschicken Sie per echo "Hiho" | sendmail root Testnachrichten und schauen Sie dabei unbedingt Meldungen an, die das System ausspuckt.

Während Ssmtp hier sehr direkt reagiert und Probleme beim Versand gleich berichtet, etwa „Relay access denied“, muss man Nullmailer Details abringen. Mit dem Befehl mailq sehen Sie, ob Nachrichten in seiner Queue stecken, die er nicht los wird. Gründe dafür finden sich spätestens in der Log-Datei (/var/log/mail.err auf Debian-Systemen); Ssmtp führt eine solche, wie gesagt, nicht.

Sollte sich ein SMTP-Server partout an den generierten Adressen stören, so können eventuell die Optionen des versendenden Prozesses helfen. cron etwa erlaubt es, in der Crontab mit MAILTO=user@example.com den regulären Empfänger der Nachrichten zu überschreiben, das ist üblicherweise der Eigentümer der jeweiligen Crontab. Moderne cron-Versionen erlauben auch das Setzen eines Absenders mit MAILFROM=joe@example.com.

Oft verursacht die Absenderadresse die meisten Probleme. Beim Testen mit sendmail auf der Kommandozeile landen womöglich anders vervollständigte Absenderadressen beim Mailhelfer als beim Aufruf aus der Webanwendung heraus, für die Sie den Aufwand eigentlich treiben (etwa root@localhost statt nur root). Prüfen Sie also nicht ausschließlich mit sendmail auf der Kommandozeile, sondern auch aus der jeweiligen Anwendung heraus.

Testen Sie unbedingt auch, ob die Nachrichten wirklich ankommen. Gerade, wenn Sie gängige kostenlose Hoster wie Google Mail, Web.de oder Outlook.com verwenden, landen Nachrichten schnell in der falschen Inbox. Kommen Ihre Testnachrichten nicht an, sollten Sie misstrauisch werden. Prüfen Sie vor ersten Gehversuchen, ob auf Seiten des Anbieters SMTP/IMAP-Zugriffe freizuschalten sind. Oft gibt es dafür im Web-Interface Optionen.

Schauen Sie sich am Ende die Rechte der Konfigurationsdateien an. Wenn die Passwörter enthalten, sollten sie nur ausgewählten Nutzern offen stehen, etwa der Gruppe „mail“. (ps@ct.de)

Beispielkonfigurationen für einige Provider:ct.de/y1ec