procmail's logging helped me get one account's .procmailrc working, but two other accounts don't work and don't log); having difficulty diagnosing

As a site that has a number of users who are "technologically challenged", and as the system mangler, it's fallen on me to solve the spam problem for us all. So, SpamAssassin's doing a fine job of identifying the spam, now it's just a matter of moving it into a directory where people can find it and identify the ham now and then - as the SA people call it!

I'd been using an IMAP based reader for that, but this needs a more systemic approach, and the SA people recommended I use procmail, which had lain fallow for a long time but has recently been revived by the original author, Stephen R. van den Berg. Thus, bugs fixed in the modern procmail v 3.22, ONWARD! (Tripleee noted that this is still the OLD procmail - the new one comes out with "rawhide," Fedora 38, which is in testing now - we're using Fedora Server 37, updated in January, with Postfix 3.7, and SpamAssassin 3.4 - more on that if anyone cares).

I figured I'd be the test subject, and I have quite a few accounts for various reasons, as system's staff often do. My first one I chose because it's seldom got inbound mail, and so if it goes wrong, it's unlikely to be an issue. And, I had trouble; I got crickets.

When I added to ~/.procmailrc the logging entries (seen below), I got the data that pointed me along, and when I added what were supposed to be some default environment variable definitions, most notably defining MAILDIR, it perked right up! It was ALREADY working fine! YAY! To help others behind me, KEY were these settings:

USER=<the_username>
LOGFILE=/var/log/procmail.$USER
VERBOSE='yes'
LOGABSTRACT='all'

This let me find the issues - there weren't many, but a few - and solve them. While other variables helped, the critical one was setting MAILDIR, which, only later did I discover would be set wrong by default for most / many Fedora systems. ... You CAN just "hard code" the file paths to the "folders", but this helped a lot:

MAILDIR=$HOME/mail

I have just ONE recipe:

:0
* ^X-Spam-Status: *Yes
Spam

The plan is that 'Spam' is where 'known spam' goes, as identified by SA, but it could be wrong. Spam that SA doesn't catch I want users to put in their 'spam' folder (note the case difference) for use in training SA. But, I digress.

But when I copied and re-chowned this simple config to a more used, and vital, account, I can see in /var/mail/maillog that it's calling the (also identical content) .forward script I'm using, and so I know procmail (the command) is getting called. But from there, NOTHING is going to the configured LOGFILE. And, it's worth pointing out that that's similar to what happened with the first account, which I solved by using the logging (in retrospect, it was only the wrong MAILDIR entry). But here, the logging isn't getting any content into it!

So, I tried another one - same thing. And, of course, I've checked file permissions and so forth... I must be "overlooking something", but, well, it was clear that the log writing was (and remains) setup just fine for the first account, so I've focused on that, and it seems absolutely "stellar" - I'd take just getting that far (logging working) on these other two accounts as a win!

(I even tried putting execute privs on .forward, but of course it wasn't needed before and didn't help now!)

Thanks.

Additional info:

It may be helpful to others to know that if you create a log file in /var/log, say, /var/log/procmail, and set the log env to point there, ALL users can use it if the permissions on the file are simply 777. No directory tree issues were found.

Also, while procmail is indeed called from postfix "without additional help," experimentation showed that the entry in .forward is required on this Fedora system - exactly how the .forward is called / read I haven't had time to fully investigate.

I would imagine that systems that don't have an email server being banged on so hard that the rate of new lines being added to the mail server's log is "a waterfall" would have an easier time finding this problem; because our system's logging rate is often over 100 lines a second (sometimes WAY higher), if you don't have something to search for - via a tail -f /var/log/maillog | grep "some search text" - you haven't a prayer of finding anything.

But, I gave it a shot, with ONE working account to go by. And, from that I found a procmail[7965]: Suspicious rcfile entry. OK, something to bite into!

Pursuit showed no obvious errors, BUT, well, the parent directory correctly has a different group entry than the username - different because of VERY legitimate reasons. Changing the group would have unknowable consequences without substantial investigation.

None of the usual advice applies, such as chmod 0640, so, I dug deeper.

I found this tidbit hiding somewhere:

Procmail usually gives this error if: [...] The directory is both world-writable and world executable but not ‘sticky’ (mode +t).

And, so, a simple chmod +t on the parent directory did the trick!