Mail Benachrichtigung - Unbekannter Absender

MickyF

Member
Nov 18, 2025
62
14
8
Hi!
Ab und an finde ich im System Log einen Fehler, dass beim Nachrichtenversand etwas schiefgegangen ist, der Sender abgewiesen wurde. Ist verständlich, denn die E-Mail Adresse root@pve01.ourhome gibt es natürlich nicht.
Jul 07 15:08:15 pve01 postfix/qmgr[1199]: BD925240927: from=<root@pve01.ourhome>, size=2357, nrcpt=1 (queue active)
Jul 07 15:08:16 pve01 postfix/smtp[1408501]: BD925240927: host mx01.goneo.de[85.220.143.6] said: 450 4.1.8 <root@pve01.ourhome>: Sender address rejected: Domain not found (in reply to RCPT TO command)
Jul 07 15:08:16 pve01 postfix/smtp[1408501]: BD925240927: to=<Notifier@xxx.de>, relay=mx02.goneo.de[85.220.165.130]:25, delay=227287, delays=227286/0.02/0.73/0.22, dsn=4.1.8, status=deferred (host mx02.goneo.de[85.220.165.130] said: 450 4.1.8 <root@pve01.ourhome>: Sender address rejected: Domain not found (in reply to RCPT TO command))
Jul 07 15:08:50 pve01 pvedaemon[1368942]: worker exit

Ich habe ein eigenes SMTP-Target im Datacenter aufgesetzt. Auch entsprechende Notification Matchers eingerichtet. Eine Testnachricht wird einwandfrei versendet.
Trotzdem erscheinen ab und zu diese Log-Einträge oben.

Ich möchte jetzt nicht ganz ausschließen, dass tatsächlich eine E-Mail "hängt", die nicht rausgeht und der Versand immer wieder aufs Neue versucht wird. Ich bin mir aktuell nicht 100%-ig sicher, dass ich nicht erst in letzter Zeit vor die Mail-Einstellungen korrigiert hatte.

Existiert irgendwo eine Queue mit geparkten und noch zu versendenden E-Mails? In diesem Zusammenhang, macht mich auch dies hier stutzig: "delay=227287"
Oder gibt es noch eine Mail-Einstellung, die ich übersehen habe?

Ach ja, der root User hat eine real existierende E-Mail-Adresse als Absender, kann also auch nicht die Ursache sein, aber, wie gesagt, bin mir nicht sicher, ob ich diese nicht erst vor kurzem korrigiert habe, daher meine Vermutung über eine geparkte E-Mail.
 
Ah, Danke! Hat schon Mal geholfen, denn
mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
ABCB11C0E0A 3626 Sat Jul 4 05:20:01 MAILER-DAEMON
(alias database unavailable)
root@pve02.ourhome

747F41C1075 1752 Mon Jul 6 05:00:02 root@pve02.ourhome
(alias database unavailable)
root@pve02.ourhome
Da wäre dann schon mal die Quelle der Syslog Einträge gefunden. Die Frage ist aber noch, wie kommen diese Mail zustande?
 
Mit
Code:
postcat -q MESSAGE_ID
kannst du dir den Inhalt der Mail anzeigen lassen und so ggf. rausfinden wo sie herkommt.
 
Kann bitte jemand den Inhalt von /etc/pve/notifications.cfg posten, sofern dort ext. E-Mail-Adresse zum Nachrichtenversand verwendet werden.
Den Inhalt gerne anonymisieren, damit nichts missbraucht wird.

Will meine Config damit vergleichen, Danke!

Das Wiki verwirrt mich aktuell auch ein wenig, v.a. in diesem Bild bei der Eingabe von Recipients:
1783508089452.png
Ich habe als Recipient auch root@pam eingestellt. Bei diesem Benutzer dann aber die ext. E-Mail-Adresse, unter der ich bspw. auch eine Test-Mail empfangen kann und ich erhalte auch ganz "normale" Benachrichtigungen, aber hin und wieder diese Fehler im System Log.
 
Last edited:
Die zwei Mails in der Queue haben nix mit deinem SMTP-Target aus der notifications.cfg zu tun, das sind zwei getrennte Wege. Dein SMTP-Target ist das neue PVE-Notification-System (deshalb geht die Testmail auch sauber raus), die hängenden Dinger dagegen sind ganz normale lokale Systemmails an root, die über den lokalen Postfix rausgehen. Die Uhrzeiten (05:00 und 05:20) deuten auf Cron hin, irgendein Job auf pve02 spuckt Output aus, der landet als Mail an root@pve02.ourhome, und weil .ourhome keine echte Domain ist, weist dein Relay den Absender ab. Daher der 450er.

Mit dem postcat -q von @mikee siehst du ja was drinsteht, dann weißt du welcher Job das ist. Die "alias database unavailable" beim MAILER-DAEMON-Eintrag würd ich mit newaliases beheben, das baut /etc/aliases.db neu. Das delay=227287 ist nur wie lange die Mail in der Queue hängt (~2,6 Tage), passt zum Arrival vom 4. Juli, also kein eigenes Problem.

Wenn dir die alten Mails egal sind: postsuper -d ALL leert die Queue (oder gezielt die IDs). Willst du, dass solche root-Systemmails künftig sauber rausgehen, musst du im Postfix den Absender umschreiben (sender_canonical bzw. myorigin auf eine echte Domain), sonst kickt dein Provider die immer wieder wegen der ourhome-Domain. Und das root@pam als Recipient ist völlig richtig so, das zieht die Mailadresse vom root@pam-User unter Datacenter > Permissions > Users, das ist nicht die Ursache.