Mailversand vom netcup-Server: Systemmails mit msmtp über Port 587 einrichten

Dies ist Teil 20 unserer netcup-Serie. Er folgt auf das Monitoring in Teil 19, weiter geht es mit Teil 21: DNSSEC. Monitoring, Sicherheitsupdates und Cron-Jobs nützen nur etwas, wenn ihre Meldungen auch ankommen.

Bei neu bestellten netcup-Servern blockiert die Standard-Policy „netcup Mail block“ der SCP-Firewall laut netcup den Versand über SMTP. Ob das auch Port 587 trifft, zeigt Schritt 1. Für Systemmails brauchen Sie aber keinen eigenen Mailserver. Diese Anleitung richtet msmtp ein, das Meldungen über ein vorhandenes Postfach bei Ihrem Mailanbieter auf Port 587 einliefert. Im Labor getestet mit msmtp 1.8.28 in einem Debian-13.7-Container gegen einen lokalen Test-Mailserver mit Anmeldung und STARTTLS.

Voraussetzungen

• netcup-vServer oder Root-Server mit Debian 13, eingerichtet nach Teil 2 der Serie; jede Servergröße reicht, msmtp bleibt nur für den Versand aktiv
• Ein Postfach bei einem Mailanbieter, das nur für Systemmails dient, mit Zugangsdaten für SMTP auf Port 587 und STARTTLS
• Eine Empfängeradresse für die Meldungen
• Zugang zum Server Control Panel (SCP)

Schritt 1: Was der netcup Mail block bedeutet

Die SCP-Firewall sitzt vor dem Server. Laut netcup-Dokumentation sperrt die Standard-Policy „netcup Mail block“ eingehende und ausgehende SMTP-Verbindungen, damit neue Server nicht für Spam missbraucht werden. Welche Ports genau betroffen sind, nennt die Dokumentation nicht. Prüfen Sie es deshalb selbst, bevor Sie etwas ändern.

Prüfen Sie vorher mit dpkg -l postfix exim4-daemon-light, ob ein Mailserver installiert ist. Das Paket msmtp-mta ersetzt ihn, auf so einem Server installieren Sie es nicht. Fragt die Installation nach AppArmor, antworten Sie mit Nein, sonst darf msmtp nicht in das Protokoll aus Schritt 3 schreiben.

Installieren Sie die Pakete und testen Sie den Port:

sudo apt-get update
sudo apt-get install -y msmtp msmtp-mta bsd-mailx netcat-openbsd
nc -vz -w 5 smtp.example.com 587

Ersetzen Sie smtp.example.com durch den Server Ihres Anbieters. Eine erreichbare Gegenstelle meldet:

Connection to smtp.example.com (…) 587 port [tcp/submission] succeeded!

Wird das Paket verworfen, wartet nc bis zur Zeitgrenze:

nc: connect to smtp.example.com (…) port 587 (tcp) timed out: Operation now in progress

Verifizieren: Sie wissen, ob Port 587 offen ist. Bei einem Timeout prüfen Sie zuerst Ihre eigene Firewall: Haben Sie ufw nach Teil 5 mit gesperrtem Ausgang eingerichtet, fehlt Port 587. Geben Sie ihn mit sudo ufw allow out 587/tcp frei und testen Sie erneut. Bleibt der Timeout, gehen Sie zu Schritt 2, sonst direkt zu Schritt 3.

Schritt 2: Die Policy nur bei Bedarf entfernen

Blockiert die Firewall den Port, entfernen Sie die Policy im SCP: Server wählen, Reiter Firewall, bei „netcup Mail block“ auf Löschen klicken und unten Speichern. Änderungen gelten laut netcup sofort. Wie Policys funktionieren, zeigt Teil 5.

Damit tragen Sie die Verantwortung für den Versand von diesem Server. Betreiben Sie keinen offenen Mailversand, und halten Sie den Server aktuell. Filtern Sie ausgehend mit eigenen Regeln, muss Port 587 dort ebenfalls frei sein.

Verifizieren: Der Test mit nc aus Schritt 1 meldet nun succeeded.

Schritt 3: msmtp einrichten

msmtp nimmt Mails entgegen und reicht sie an den Server Ihres Anbieters weiter. Es hält keine Warteschlange und öffnet keinen Port. Das Paket msmtp-mta stellt zusätzlich den Befehl sendmail bereit, den Cron und viele andere Programme aufrufen.

sudo tee /etc/msmtprc >/dev/null <<'EOF'
defaults
auth           on
tls            on
tls_starttls   on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
timeout        15
logfile        /var/log/msmtp.log
aliases        /etc/aliases

account        relay
host           smtp.example.com
port           587
from           server@example.com
user           server@example.com
password       IHR-PASSWORT

account default : relay
EOF
sudo chown root:msmtp /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo touch /var/log/msmtp.log
sudo chown root:msmtp /var/log/msmtp.log
sudo chmod 660 /var/log/msmtp.log
sudo cp -a /etc/aliases /etc/aliases.bak 2>/dev/null
sudo tee /etc/aliases >/dev/null <<'EOF'
root: admin@example.com
default: admin@example.com
EOF

Das Passwort steht im Klartext in der Datei. Nehmen Sie deshalb ein Postfach, das nur diesem Zweck dient, und nie Ihr Hauptpostfach. Die Rechte 640 schützen die Datei vor normalen Benutzern, solange msmtp ohne SGID-Bit läuft (Schritt 5).

Verifizieren: ls -l /etc/msmtprc zeigt -rw-r----- 1 root msmtp.

Schritt 4: Testmail senden

printf "To: admin@example.com\nSubject: Test von msmtp\n\nHallo\n" | sudo msmtp admin@example.com
echo $?
sudo tail -1 /var/log/msmtp.log

Der Rückgabewert 0 bedeutet, dass der Server die Mail angenommen hat. Das Protokoll enthält dann eine Zeile mit smtpstatus=250 (hier gekürzt):

host=smtp.example.com tls=on auth=on user=server@example.com from=server@example.com recipients=admin@example.com mailsize=175 smtpstatus=250

Verifizieren: Die Testmail liegt im Postfach. Liegt sie im Spam-Ordner, prüfen Sie beim Anbieter SPF und DKIM der Absenderdomain.

Schritt 5: Normale Benutzer und Cron freischalten

Hier hakte es im Test. Sendet ein normaler Benutzer eine Mail, scheitert das unter Debian 13 trotz korrekter Datei:

sendmail: account default not found: no configuration file available
Can't send mail: sendmail process failed with error code 78

Die Meldung führt in die Irre: Die Datei ist da, nur darf der Benutzer sie nicht lesen, und das Programm läuft ohne die Gruppe msmtp.

Wichtig: Debian hat das SGID-Bit absichtlich entfernt, weil lokale Benutzer damit an die Zugangsdaten aus /etc/msmtprc kommen können, auch ohne die Datei lesen zu dürfen (Debian-Bug 944188). Lassen Sie Meldungen deshalb am besten nur von root-Jobs senden, die brauchen diesen Schritt nicht. Setzen Sie das Bit nur auf einem Server, auf dem ausschließlich Sie selbst Benutzer sind und auf dem keine fremden Programme als normaler Benutzer laufen. dpkg-statoverride sorgt dafür, dass die Einstellung Paket-Updates übersteht:

sudo dpkg-statoverride --update --add root msmtp 2755 /usr/bin/msmtp
ls -l /usr/bin/msmtp
echo Testlauf | mail -s "Cron-Test" root

Im Test kam die Mail an root danach über den Alias bei admin@example.com an. Das Bit blieb auch nach einer Neuinstallation des Pakets erhalten. Ein direktes cat /etc/msmtprc scheitert weiter mit Permission denied, das schützt das Passwort aber nicht vor msmtp selbst.

Verifizieren: ls -l /usr/bin/msmtp zeigt -rwxr-sr-x 1 root msmtp, und die Mail ist im Postfach. Wie Sie Sicherheitsupdates melden lassen, zeigt die Anleitung zu unattended-upgrades.

Schritt 6: Meldungen sinnvoll nutzen

Jetzt lohnt es sich, Programme gezielt melden zu lassen. Cron schickt die Ausgabe eines Jobs laut Handbuch an die Adresse aus MAILTO. Tragen Sie die Variable oben in die Crontab von root ein, dann landet jede Ausgabe bei Ihnen:

MAILTO=admin@example.com
30 3 * * * /usr/local/bin/backup.sh

Melden sollten vor allem Dinge, auf die Sie reagieren müssen: fehlgeschlagene Sicherungen, Updates, die einen Neustart verlangen, und volle Platten. Halten Sie erfolgreiche Läufe still, sonst gehen die wichtigen Mails in der Menge unter. Unser Monitoring aus Teil 19 ergänzt das, denn ein ausgefallener Server schickt keine Mail mehr. Überwachen Sie den Server deshalb auch von außen.

Bedenken Sie außerdem die Grenzen von msmtp: Es liefert sofort ein und speichert nichts zwischen. Fällt der Anbieter gerade aus, ist die Meldung verloren. Für Systemmails ist das meist vertretbar, weil die Ursache beim nächsten Lauf erneut auffällt. Bei Mails an Kunden wäre es das nicht, dafür brauchen Sie einen Mailserver oder einen Versanddienst.

Verifizieren: Legen Sie einmalig einen Job an, der absichtlich etwas ausgibt, zum Beispiel echo Test, und prüfen Sie nach dem Lauf Postfach und /var/log/msmtp.log. Lehnt der Anbieter die Mail ab, passen Sie den Absender an.

Schritt 7: Sichern und wiederherstellen

Die Einrichtung besteht aus wenigen Dateien. Sichern Sie sie gemeinsam und verschlüsselt außerhalb des Servers, denn das Archiv enthält das Passwort.

sudo tar czf /root/msmtp-backup.tar.gz -C / etc/msmtprc etc/aliases
sudo chmod 600 /root/msmtp-backup.tar.gz

Fehlen die Dateien, meldet msmtp:

msmtp: account default not found: no configuration file available

So stellen Sie sie wieder her:

sudo tar xzpf /root/msmtp-backup.tar.gz -C /
ls -l /etc/msmtprc

Beim Umzug auf einen neuen Server installieren Sie zuerst die Pakete aus Schritt 1, erst dann spielen Sie die Sicherung ein, denn die Gruppe msmtp entsteht bei der Installation. Das Log aus Schritt 3 legen Sie neu an.

Verifizieren: Die Rechte stehen wieder auf -rw-r----- 1 root msmtp, und eine Testmail wie in Schritt 4 geht durch.

Schritt 8: Aktualisieren

msmtp kommt aus den Debian-Paketquellen und wird mit dem System aktualisiert. Von Hand geht es so:

sudo apt-get update
sudo apt-get install -y --only-upgrade msmtp msmtp-mta
msmtp --version | head -1

Verifizieren: Die Version wird angezeigt, und eine Testmail wie in Schritt 4 liefert den Rückgabewert 0.

Troubleshooting

Häufige Fragen

Warum nicht Postfix?

Postfix ist ein vollständiger Mailserver mit Warteschlange. Für einzelne Systemmails reicht msmtp, es läuft nur während des Versands. Der Preis: Ist der Anbieter nicht erreichbar, geht die Mail nicht in eine Warteschlange, sondern der Versand schlägt fehl. Der Rückgabewert war im Test 75.

Brauche ich Reverse-DNS?

Für diesen Weg nicht zwingend, denn die Mail gelangt über den Server Ihres Anbieters ins Internet. Für einen eigenen Mailserver ist es Pflicht, siehe Teil 6.

Sollte ich Port 25 nutzen?

Für das Einliefern bei Ihrem Anbieter ist Port 587 mit Anmeldung der vorgesehene Weg. Nutzen Sie die Angaben aus dessen Dokumentation.

Welches Postfach eignet sich?

Jedes Postfach, das SMTP auf Port 587 mit Anmeldung anbietet. Legen Sie ein eigenes an und nutzen Sie es nur für diesen Server. Wird das Passwort bekannt, ändern Sie es dort, ohne dass Ihr Hauptpostfach betroffen ist.

Fazit

Mit msmtp erreichen Systemmails Ihres netcup-Servers zuverlässig ein Postfach, ohne dass ein Mailserver läuft. Prüfen Sie zuerst den Port, nehmen Sie ein eigenes Postfach und senden Sie möglichst nur aus root-Jobs. Ihr Server ist jetzt abgesichert, gesichert, überwacht und meldet sich, wenn etwas nicht stimmt.

Weiterführende Anleitungen und Quellen

• Teil 5: netcup SCP-Firewall einrichten
• Teil 6: Reverse-DNS im netcup SCP setzen
• Teil 19: Beszel Server Monitoring
• Linux-Server absichern: ufw und Fail2ban
• msmtp-Dokumentation
• msmtp auf GitHub
• netcup Helpcenter: Firewall