Mails to root are not forwarded

[promoxer]

1. Sender is Datacenter > Options > email is proxmox@example.com
2. Set alias at Datacenter > Permissions > Users > root@pam > email is pve-ui-alias@example.com
3. I was expecting email FROM proxmox@example.com TO pve-ui-alias@example.com
4. My test is to run echo "test" | mail -s "[PVE] mails to root are forwarded" root
5. But there are no traces of pve-ui-alias or pve-file-alias in mail.log
6. Also added root: [EMAIL]pve-file-alias@example.com[/EMAIL] to /etc/alias + ran newaliases
7. I also ran dpkg-configure postfix to try and reset it to satelite system
8. But my mail.log still reports sending emails from root@example.com to root@example.com only,
9. What am I missing?

 

[promoxer]

https://serverfault.com/a/826268/930498 solution here started forwarding mails to `root` to pve-file-alias@example.com

But the mail content still does not reflect proxmox@example.com or pve-ui-alias@example.com, basically the UI options in #1 and #2 have no effect

 

[Lukas Wagner]

If forwarding mails via a sendmail-based notification target (which was the default and only option before the notification system overhaul in Proxmox VE 8.1), the mail is forwarded as is, without touching any headers. If that is a problem, you'd need to instruct Postfix to rewrite the From header (e.g. https://serverfault.com/questions/147921/forcing-the-from-address-when-postfix-relays-over-smtp - haven't tested their solution though)

 

[promoxer]

Well, without getting too deep into the details of sendmail or not, my expectation was for the options specified in the UI to work. But they did not work as expected, thus I had to dig deeper.

I meant, why are mails still being sent to `root` when the values provided to the options are not `root`? In my view, better to hide the options. I'm on PVE 7.4 btw

 

[Lukas Wagner]

I meant, why are mails still being sent to `root` when the values provided to the options are not `root`? In my view, better to hide the options. I'm on PVE 7.4 btw

The settings affect mail notifications for backups, fencing, etc.

But yeah, I see why this is confusing/annoying. Would you mind creating an issue at https://bugzilla.proxmox.com/ and describe the issue in detail there?

Thanks in advance!

 

[promoxer]

https://bugzilla.proxmox.com/show_bug.cgi?id=5135 done

 

[Lukas Wagner]

Thanks! I'll take a look at this when I find the time. That being said, the fix will probably only be shipped in the Proxmox VE 8.x branch due to the recently reworked notification system.

 

[promoxer]

Thanks sure, I'm going to upgrade to 8 anyway, but still finding a suitable weekend as I don't want to incur any downtime

 

[promoxer]

Where can I also add 2 feature requests?

1. Be able to trigger test nofications of varying severity (https://forum.proxmox.com/threads/how-to-test-proxmox-email-notifications.59982/#post-617343)

2. Backup also sends it's notifications to yet another email address. "Datacenter > Backup > General > Send email to"

My suggestion is to rename "Send email to" as "Also send email to" and add a tick "Don't send to root" checkbox.

In effect, backup emails will always be sent to root unless user says don't. And if additional emails are specified, they will be to sent to those + root as well. This will centralize notifcations into 1 location, "Database > Permissions > Users > root@pam"

I have not played around with PVE 8 yet, but my experience with effective notifications is, do I need to take action or not?
Based on this, it would be great if PVE has built-in mechanism to separate notifications into those 2 categories, yes and no.

See https://forum.proxmox.com/threads/separate-noteworthy-notifications.138043/#post-615763

e.g.

backup successful -> sent to pve-success@example.com
backup failed -> sent to pve-failed@example.com
ZFS vpool degraded -> sent to pve-failed@example.com

Thanks.

 

[promoxer]

Jan 26 08:45:23 box postfix/smtpd[477766]: warning: hostname 1.x.x.49.unknown.com does not resolve to address 49.x.x.1: Name or service not known
Jan 26 08:45:23 box postfix/smtpd[477766]: connect from unknown[49.x.x.1]
Jan 26 08:45:23 box postfix/smtpd[477766]: warning: restriction `reject_authenticated_sender_login_mismatch' ignored: no SASL support
Jan 26 08:45:23 box postfix/smtpd[477766]: NOQUEUE: reject: RCPT from unknown[49.x.x.1]: 554 5.7.1 Service unavailable; Client host [49.x.x.1] blocked using zen.spamhaus.org; https://www.spamhaus.org/query/ip/49.x.x.1; from=<root@pve.example.com> to=<pve1-report@mail-in-a-box.com> proto=ESMTP helo=<pve.example.com>
Jan 26 08:45:23 box postfix/smtpd[477766]: disconnect from unknown[49.x.x.1] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=4/6
Jan 26 08:45:23 box postfix/smtpd[477766]: warning: hostname 1.x.x.49.unknown.m1.com.sg does not resolve to address 49.x.x.1: Name or service not known
Jan 26 08:45:23 box postfix/smtpd[477766]: connect from unknown[49.x.x.1]
Jan 26 08:45:23 box postfix/smtpd[477766]: warning: restriction `reject_authenticated_sender_login_mismatch' ignored: no SASL support
Jan 26 08:45:23 box postfix/smtpd[477766]: NOQUEUE: reject: RCPT from unknown[49.x.x.1]: 554 5.7.1 Service unavailable; Client host [49.x.x.1] blocked using zen.spamhaus.org; https://www.spamhaus.org/query/ip/49.x.x.1; from=<root@pve.example.com> to=<pve1-report@mail-in-a-box.com> proto=ESMTP helo=<pve.example.com>
Jan 26 08:45:23 box postfix/smtpd[477766]: disconnect from unknown[49.x.x.1] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=4/6

Above shows emails from PVE being rejected as spam due to improper setup out of the box. PVE should just ask for a SMTP username/password and outsource sending emails to a proper SMTP.