KeyHelp: E-Mail-Adressen der Server-Domain wie postmaster und abuse einrichten

Jeder Mailserver sollte unter seinem eigenen Namen erreichbar sein: an postmaster@ schicken andere Mailserver Hinweise zu Zustellproblemen, an abuse@ gehen Beschwerden über Spam oder kompromittierte Konten, und laut KeyHelp-Dokumentation senden Zertifizierungsstellen Bestätigungsmails für ein Zertifikat der Serverdomain nur an solche vordefinierten Adressen (RFC 2142). Bei KeyHelp ist der Hostname des Servers, etwa server.example.de, aber keine normale E-Mail-Domain, für die Sie Postfächer anlegen könnten. Dafür gibt es eine eigene Einstellung. Diese Anleitung zeigt, wie Sie sie richtig ausfüllen, was KeyHelp dabei in Postfix schreibt und warum diese Adressen im Grundzustand ins Leere laufen. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12.

Voraussetzungen

• Ein KeyHelp-Server mit Administrator-Zugang. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15, Hostname server.example.de.
• Eine Zieladresse, die Sie regelmäßig lesen. Im Test war das das Postfach info@kunde1.example.de auf demselben Server. Eine externe Adresse geht auch, dann gilt der Hinweis zu SPF weiter unten.
• SSH-Zugang als root, um die Wirkung in /etc/aliases und im Mail-Log zu prüfen. Für die Einstellung selbst genügt das Panel.

Schritt 1: Grundzustand prüfen

Bevor Sie etwas ändern, lohnt der Blick auf den Ist-Zustand. Postfix nimmt Mails für den Hostnamen über die klassische lokale Zustellung an. Die passenden Einträge zeigt postconf:

postconf myhostname mydestination alias_maps virtual_mailbox_domains

myhostname = server.example.de
mydestination = localhost, $myhostname
alias_maps = hash:/etc/aliases
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Der Hostname steht in mydestination, ist also eine lokale Domain. Die Kundendomains dagegen kommen aus der KeyHelp-Datenbank über virtual_mailbox_domains. Der Hostname ist damit keine E-Mail-Domain der KeyHelp-Verwaltung, die Panel-Seite aus Schritt 2 sagt das auch ausdrücklich. Welche Empfänger Postfix für den Hostnamen annimmt, regeln die Systembenutzer und /etc/aliases (local_recipient_maps = proxy:unix:passwd.byname $alias_maps). Auf unserem frisch installierten Server sah die Datei so aus:

#  This file is managed by KeyHelp.                 
hostmaster: root
postmaster: root
webmaster: root
abuse: root
clamav: root

Alle Namen zeigen auf den lokalen Benutzer root, und für root gibt es keine weitere Weiterleitung (eine Datei /root/.forward existierte nicht). Der Test mit zwei Mails an postmaster und abuse zeigt, was daraus folgt:

printf "Subject: Test postmaster\n\nHallo\n" | sendmail postmaster@server.example.de
journalctl -u postfix@- --since "-3min" --no-pager | grep status=

Oct 01 17:32:16 server.example.de postfix/pipe[6211]: E063B42B35: to=<root@server.example.de>, orig_to=<postmaster@server.example.de>, relay=dovecot, delay=0.63, delays=0.55/0.02/0/0.06, dsn=5.1.1, status=bounced (user unknown. Command output: lda(root@server.example.de): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied )

Postfix löst postmaster zu root auf und übergibt die Mail an das Dovecot-Zustellprogramm. Dovecot kennt root@server.example.de nicht als Postfach, die Mail kommt mit dsn=5.1.1 zurück. Im Test ging auch die Unzustellbarkeitsnachricht an den Absender (hier root) auf demselben Weg verloren. Ohne Weiterleitung gehen Hinweise an postmaster und abuse also verloren.

Verifizieren: Wenn in /etc/aliases keine Zeile root: … mit einer echten Adresse steht, ist die Weiterleitung nicht eingerichtet. Im Mail-Log steht dann bei Testmails an postmaster@ und abuse@ status=bounced.

Schritt 2: Die Einstellung im Panel finden

Melden Sie sich als Administrator an und öffnen Sie im Menü „Einstellungen“ den Punkt „Konfiguration“. Dort finden Sie den Bereich „E-Mail-Adressen der Server-Domain“. Die Seite erklärt selbst, worum es geht: „Die Domain des Control Panels (server.example.de) kann nicht direkt für den Empfang von E-Mails verwendet werden.“

Die Seite hat genau zwei Felder:

• „Verfügbare Empfängeradressen (<Name>@server.example.de)“: ein mehrzeiliges Feld, ein Name pro Zeile, ohne Domain.
• „Weiterleiten an“: eine E-Mail-Adresse, an die alle Mails an diese Namen gehen.

Getrennte Ziele je Adresse sieht die Oberfläche nicht vor.

Verifizieren: Auf der Seite stehen im oberen Feld die Namen hostmaster, postmaster, webmaster, abuse und root. Steht unter „Weiterleiten an“ nichts, gilt der Befund aus Schritt 1.

Schritt 3: Empfängeradressen und Ziel eintragen

Ergänzen oder kürzen Sie die Liste nach Bedarf. Für einen Mailserver sind postmaster und abuse die wichtigsten Einträge. Im Test haben wir zusätzlich security eingetragen und webmaster bewusst entfernt, um zu sehen, was mit Namen passiert, die nicht in der Liste stehen. Außerdem haben wir einen Eintrag absichtlich mit Domain geschrieben, also abuse@server.example.de. Unter „Weiterleiten an“ steht die Zieladresse, im Test info@kunde1.example.de. Klicken Sie auf „Speichern“.

Die Oberfläche meldet „Die Einstellungen wurden aktualisiert.“ Der Eintrag mit Domain wurde dabei still zu abuse gekürzt. Sie müssen also nur den Namen vor dem @ eintragen.

Wichtig für externe Ziele: Die Seite weist selbst darauf hin, dass Sie den Server bei einer fremden Zieladresse möglicherweise in den SPF-Einstellungen des externen Servers auf die Whitelist setzen müssen. Hintergrund und Abhilfe erklärt die Anleitung E-Mail-Weiterleitungen mit SRS zuverlässig zustellen. Ein Postfach auf dem eigenen Server als Ziel umgeht das Thema.

Verifizieren: Nach dem Neuladen der Seite stehen Ihre Namen ohne Domain im oberen Feld und Ihre Zieladresse unter „Weiterleiten an“.

Schritt 4: Wirkung in /etc/aliases prüfen

KeyHelp schreibt die Datei nicht sofort beim Speichern. Direkt nach dem Speichern stand in der Datenbank schon der neue Wert, /etc/aliases trug aber noch den alten Zeitstempel. Etwa eine Minute später war die Datei neu geschrieben. Das passt zum minütlichen KeyHelp-Cronjob, der in /etc/cron.d/keyhelp eingetragen ist:

/etc/cron.d/keyhelp:9:*/1 * * * * root nice -n 5 php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php

Danach sieht die Datei so aus (ohne Kommentarkopf):

grep -v "^#" /etc/aliases

hostmaster: root
postmaster: root
abuse: root
security: root
root: info@kunde1.example.de

Das Prinzip: Jeder Name aus der Liste zeigt weiter auf root, und neu ist die Zeile root: info@kunde1.example.de. Erst sie sorgt dafür, dass Mails das Postfach erreichen. Die zugehörige Datenbank /etc/aliases.db wurde zur selben Minute erneuert, ein manuelles newaliases war nicht nötig. Beachten Sie auch: Die Zeile clamav: root aus dem Grundzustand war nach dem Speichern weg, weil clamav nicht in der Liste des Panels stand. KeyHelp schreibt die Datei vollständig neu. Zeilen, die nicht aus dem Panel stammen, fallen dabei weg; der Kommentarkopf der Datei verweist für Änderungen auf das Konfigurationsmenü.

Verifizieren: ls -la /etc/aliases /etc/aliases.db zeigt eine Uhrzeit nach Ihrem Speichern, und grep -v "^#" /etc/aliases enthält die Zeile root: mit Ihrer Zieladresse.

Schritt 5: Zustellung testen

Schicken Sie auf dem Server je eine Testmail an jeden Namen, auch an einen, den Sie entfernt haben:

for a in postmaster abuse security webmaster; do
  printf "Subject: Test an $a\n\nHallo\n" | sendmail $a@server.example.de
done
journalctl -u postfix@- --since "-1min" --no-pager | grep -E "orig_to|status="

Im Log sehen Sie zwei Stufen. Zuerst die lokale Auflösung, dann die Zustellung ins Zielpostfach mit der ursprünglichen Adresse in orig_to:

postfix/local[6846]: 4909342B3C: to=<postmaster@server.example.de>, relay=local, delay=3.5, delays=3.4/0.01/0/0.04, dsn=2.0.0, status=sent (forwarded as B55F342B3F)
postfix/lmtp[6849]: B55F342B3F: to=<info@kunde1.example.de>, orig_to=<postmaster@server.example.de>, relay=server.example.de[private/dovecot-lmtp], delay=0.1, delays=0.01/0.01/0.01/0.06, dsn=2.0.0, status=sent (250 2.0.0 <info@kunde1.example.de> pmRNLvOZvmrDGgAAd+yh0g Saved)
postfix/pipe[6860]: BFADD42B35: to=<webmaster@server.example.de>, relay=dovecot, delay=3.5, delays=3.5/0/0/0.03, dsn=5.1.1, status=bounced (user unknown. Command output: lda(webmaster@server.example.de): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied )

postmaster, abuse und security kamen an, webmaster nicht mehr, weil der Name aus der Liste entfernt war. Im Postfach lässt sich das mit doveadm gegenprüfen:

doveadm fetch -u info@kunde1.example.de "hdr.subject hdr.to" mailbox INBOX subject "Test an" | grep subject

hdr.subject: Test an security
hdr.subject: Test an postmaster
hdr.subject: Test an abuse

Zum Schluss der SMTP-Dialog, wie ihn ein fremder Mailserver führt. Wir haben dazu auf dem Server selbst mit Python eine Sitzung auf Port 25 an die eigene Server-IP geöffnet (nicht über localhost, das in mynetworks steht) und nur die Empfänger abgefragt:

python3 - <<EOF
import smtplib
s=smtplib.SMTP("203.0.113.10",25,local_hostname="mail.example.org")
s.ehlo()
print(s.mail("pruefung@gmx.de"))
for r in ("abuse@server.example.de","webmaster@server.example.de","gibtsnicht@server.example.de"):
    print(r, s.rcpt(r))
s.quit()
EOF

abuse@server.example.de (250, b'2.1.5 Ok')
webmaster@server.example.de (550, b'5.1.1 <webmaster@server.example.de>: Recipient address rejected: User unknown in local recipient table')
gibtsnicht@server.example.de (550, b'5.1.1 <gibtsnicht@server.example.de>: Recipient address rejected: User unknown in local recipient table')

Namen, die nicht in der Liste stehen, lehnt Postfix also schon im SMTP-Dialog ab. Ausnahmen sind postmaster und root, siehe „Typische Fehler“ und „Häufige Fragen“. Der Absender bekommt sofort eine klare Rückmeldung, statt dass die Mail angenommen und später zurückgeschickt wird.

Verifizieren: Im Zielpostfach liegen die Testmails, im Log steht für jeden Namen aus der Liste status=sent mit orig_to der ursprünglichen Adresse.

Typische Fehler

Weiterleitung leer gelassen

Das ist der Auslieferungszustand und der häufigste Fehler. Wir haben das Feld „Weiterleiten an“ nach dem Test wieder geleert und gespeichert. Die Meldung lautete wie immer „Die Einstellungen wurden aktualisiert.“, eine Warnung gab es nicht. Nach dem nächsten Cronjob fehlte die Zeile root: in /etc/aliases, und eine Mail an abuse@ endete wieder mit „user unknown. Command output: lda(root@server.example.de): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied“. Speichern Sie die Seite also nie ohne Zieladresse.

Ungültige Zieladresse

Das Feld „Weiterleiten an“ ist ein E-Mail-Feld. Mit dem Eintrag postmaster ohne Domain hält bereits der Browser das Formular an, Chromium meldet „Die E-Mail-Adresse muss ein @-Zeichen enthalten. In der Angabe "postmaster" fehlt ein @-Zeichen.“ Auch ohne diese Browserprüfung lehnt KeyHelp den Wert ab: „Die eingegebene E-Mail-Adresse ist ungültig.“

postmaster aus der Liste entfernt

Im Test haben wir die Liste auf abuse und hostmaster gekürzt. Anders als bei webmaster lehnte Postfix postmaster@ im SMTP-Dialog nicht ab, sondern antwortete mit 250 2.1.5 Ok. Die Mail kam danach trotzdem zurück, die Logzeile lautete „to=<postmaster@server.example.de>, relay=dovecot“ mit „status=bounced“. postmaster wird angenommen, auch wenn Sie es nicht eintragen, landet dann aber nirgends. Lassen Sie postmaster deshalb immer in der Liste.

Eigene Zeilen in /etc/aliases verschwinden

KeyHelp schreibt die Datei aus der Panel-Einstellung neu. Im Test ging dabei clamav: root verloren, und auch alles, was Sie von Hand ergänzen, verschwindet beim nächsten Speichern. Pflegen Sie die Namen nur über das Panel.

Häufige Fragen

Kann ich für den Hostnamen ein richtiges Postfach anlegen?

Nicht über die normale Domainverwaltung, der Hostname ist im Panel keine E-Mail-Domain. Für die Adressen aus dieser Anleitung reicht die Weiterleitung in ein bestehendes Postfach.

Brauche ich root@ in der Liste?

Die Zeile root: mit Ihrer Zieladresse schreibt KeyHelp selbst, sobald „Weiterleiten an“ gefüllt ist. Im Test nahm Postfix root@server.example.de im SMTP-Dialog mit 250 2.1.5 Ok an, auch nachdem root nicht mehr in der Liste stand, und eine Mail an root (im Test die Unzustellbarkeitsnachricht zur Testmail an postmaster) landete laut Log mit orig_to=<root@server.example.de> im Zielpostfach. Damit erreichen Sie auch Mails, die der Server an root schickt.

Was ist mit postmaster@ und abuse@ der Kundendomains?

Diese Einstellung betrifft nur den Hostnamen des Servers, wie der Text auf der Panel-Seite sagt. Die Kundendomains haben wir in diesem Test nicht verändert.

Was sagt die KeyHelp-Dokumentation dazu?

Die Knowledge Base (Artikel „Server-Einstellungen“) beschreibt den Punkt im Artikel zu den Server-Einstellungen als „E-Mail-Adressen für Serverdomain“ mit einer Checkbox „Weiterleitung aktivieren?“ und einem Feld „Ziel E-Mail-Adresse der Weiterleitung“. In KeyHelp 26.1.1 gibt es keine Checkbox mehr, sondern die frei bearbeitbare Liste und das Feld „Weiterleiten an“. abuse ist ab Werk enthalten, in der Knowledge Base fehlt es in der Aufzählung.

Testumfang

Wir haben auf KeyHelp 26.1.1 die Seite „E-Mail-Adressen der Server-Domain“ mit eigener Liste, leerer und gefüllter Weiterleitung getestet und die Wirkung in /etc/aliases, im Mail-Log, im Zielpostfach und im SMTP-Dialog an die eigene Server-IP geprüft. Auffällig: Im Auslieferungszustand gehen Mails an postmaster@ und abuse@ verloren. Nicht geprüft haben wir externe Zieladressen und die Zustellung aus dem Internet. Senden Sie nach jeder Änderung eine Testmail.

Fazit

Die Einstellung ist schnell gesetzt, wird aber leicht vergessen, weil KeyHelp den Grundzustand ohne Zieladresse ausliefert und nicht warnt. Die Liste der Namen allein bewirkt nichts, erst die Adresse unter „Weiterleiten an“ macht aus postmaster@ und abuse@ funktionierende Adressen. Wer nach dem Speichern eine Minute wartet, /etc/aliases kontrolliert und je eine Testmail schickt, ist auf der sicheren Seite. Hinweise anderer Mailserver und Missbrauchsmeldungen erreichen Sie dann zuverlässig.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• KeyHelp: E-Mail-Weiterleitungen mit SRS zuverlässig zustellen
• KeyHelp: Rspamd-Spamfilter einrichten und einstellen
• Keyweb: KeyHelp, alle Funktionen im Überblick
• KeyHelp Knowledge Base: Server-Einstellungen (Abschnitt E-Mail-Adressen für Serverdomain)
• RFC 2142: Mailbox Names for Common Services, Roles and Functions