Search results

You need to take into account the rules and their priorities as well (e.g. in the default rule-set the Blocklist rule has a higher priority than the Welcomelist rule) The docs try to explain this with: but - put shortly - it should work as you describe it - if you get surprised by the results...

We have a section in our reference documentation for that because the question came up quite a few times : https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_welcomelist_overview This should explain most things I hope

This seems to be the most recent version according to the ClamAV CDN's TXT records: dig +noall +answer current.cvd.clamav.net TXT @8.8.8.8 current.cvd.clamav.net. 527 IN TXT "1.0.9:62:27821:1763031600:1:90:49192:339" (the second field in the : separated list is the version of...

hm - on a hunch - make sure your maxspamsize in the Spam Detector settings is as large as your max e-mail size: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_options_2 https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_mailproxy_options else SpamAssassin could see mails as...

mostly because PMG itself is meant to be deployed behind a firewall - see: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#chapter_deployment But apart from that - because there are quite a few deployments which do need to adapt a few of the ports and settings - and providing a sensible...

Yes - as said above - when you remove the files this is to be expected! - do not remove them, but truncate them (make them an empty file) how exactly do the two files look afterwards? - as said I cannot reproduce the problem when running your pmgsh command from above you could also install...

ran that command with an rfc1918 IP (192.168.244.244) and it worked and did not break the GUI - so maybe the issue might be ansible (or python3) related? does the issue also occur if you run the command without playbook? the journal might contain some messages explaining why it's not working

As the GUI and pmgsh use the same code-paths in the backend this sounds odd or might point to a quoting issue - which entries do you try to add/create (please anonymize what you don't want to have public - but keep it consistent (if your replace proxmox.com with xxx.domain then do so everywhere...

From a quick check your analysis is correct - creating a new selector in the GUI/CLI/pmgsh will set it as the currently used one and the TXT record is only shown for the currently set selector. Options if your workaround does not work for you: * stop postfix while creating the new selector...

Please let us know if that indeed fixes the issue! Thanks!

it seems you're still running the postgresql server version 15 (on port 5432): see: https://pmg.proxmox.com/wiki/Upgrade_from_8_to_9#Upgrade_the_PostgreSQL_database this should take care of the collation warnings as well. I hope this helps!

did you upgrade the postgres cluster? (did you drop the old postgres cluster after the upgrade)? here the warnings went away latest after a reboot with the system using the postgres version from trixie (without the need to run the alter database statement) I hope this helps!

bounces generated by postfix itself do not pass through the filter processing and are thus not signed by PMG. IIRC this should not be a problem if your PMG has a dedicated hostname (which then needs to _not_ have a DMARC policy) else if you enable receiver verification at least there should...

The regex you posted works here on a test-setup (single what-object in the rule, action block). please share: * `pmgdb dump --rules active` * the logs for that mail (best from the journal)

keep in mind that receiving mail-servers might also score those mails higher. but to answer your question - you should be able to lower the score or disable the rule with a custom score (for disabling use 0 as score)...

Die mail wurde laut log zugestellt - und damit am PMG aus der queue gelöscht (sie ist nicht mehr am system) Die erste Zeile zeigt, dass die mail am 28.1.2025 vo 192.168.200.201 angenommen wurde (dort sollte die suche nach F0C0868E3D7 in den Logs aufschluss geben). die zweite Zeile sagt, dass...

See: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_welcomelist_overview the user block/welcome lists only tweak the spamscore - what happens with those mails depends on the rules configured by the admin. If you configure a rule to block mails with a spamscore of e.g. 50 (with...

This is usually handled by enabling recipient verification: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_mailproxy_options you can disable the logging to /var/log/mail.log in rsyslog.conf (/var/log/syslog is used for the tracking center) also fixed by recipient verification...

Thanks for the report! we managed to reproduce the issue - and are currently working on a patch: https://lore.proxmox.com/pmg-devel/20251028163628.79739-1-s.ivanov@proxmox.com/T/#t Once we apply an improved version it should work again!

In theory there is no safe way to upgrade if you don't remember what you did on a system. But I'd say that most changes should be preserved if you upgrade in place and carefully compare the configuration changes the upgrade process asks you about. Also make sure to create a backup and test that...