Recent content by BloodyIron

from ISO for me

Yup. The fact that it still has history and markers indicates there still is information in PMG to process, even if it isn't the full E-Mail message itself.

I don't see how that gives me what I was speaking to at all. I'm talking about going back through message log history, which clearly exists in PMG, and marking said content as "actually spam" (or equivalent) so that future spam analysis can be more accurate. This is more of a manual influence...

I have a fresh install of Proxmox Mail Gateway that's a few weeks old now. And the service/daemon "clamav-freshclam" is NOT set to start automatically. This seems like an undesirable state of things, so I'm going to configure it to auto start. But does anyone know why it is like this?

So when I find a message in the logs that showed it was accepted/sent to the recipient, but it was actually spam, how can (in the webGUI) I mark said message as actually spam for PMG to learn from it? I'm not yet finding a way to do that (via webGUI).

This isn't about making it more secure, this is about NOT making it less secure by placating a bad idea which would tangibly make the supply chain of software less secure. I'm not going to sit here and give you the education you need on why supply chain matters... _especially when we're talking...

This aspect SHOULD NOT rely on a third party from the Proxmox group itself. Those scripts are well intentioned, but are NOT sufficiently vetted for security functions. Proxmox VE clusters are used in many sensitive environments and this can lead to very real, and potentially wide-spread...

I'm trying to review the task history for an LXC and the LXC has _ZERO_ task entries for the last year, but I know for a fact there's multiple. Can we _please_ have this number increased by... a lot? Or changed in nature so that task history limits are at least per-object?

Indeed! It can even show if multiple IPs and IPv6 (in addition to IPv4) addresses. Surely this can be tallied and indexed/searched/listed in some way.

This method (with the "More" menu top right) worked for me! I did the CLI stuff earlier in the thread but tried this method again (webGUI) and it worked "better" for me :)

If you can't prove who did what actions on an IT System that needs to be audited, then you can't complete audit. This is a hard limitation in environments that require such auditing, whether it is for periodic certification of the environment, or ITSEC forensic purposes. This will be a reason...

It's really hard to not want to jump down your throat when I clearly spell out earlier in this discussion that this is a scaling problem _which you directly quote me as saying_. Yes I understand at the scale you speak to there are ways to do this, but that does not detract the value of what I...

You're completely failing to see that to get Shell/CLI access on _each and every PVE Node in a cluster_ that currently that is _ONLY_ possible with PAM. LDAP/AD/OIDC/PVE/other authentication capabilities within Proxmox VE _CANNOT_ grant Shell/CLI access. THAT is the difference. In order to...

Okay now do that for each additional user on a huge Proxmox VE cluster one at a time... Having to manually go and set up a new user or modify an existing PAM user on a multi-hundred (or larger) PVE Node Cluster just so they can get Shell/CLI access is a very poor way to go about doing things...

Bug is the only real class of report that can be made, regardless of if the term is fully accurate or not. And this is a scaling problem, plus that's the whole point of the webGUI for Proxmox in general. So you can manage how the system operates _without_ having to go to the CLI. You literally...