3

I'm using a combination of Postfix and Procmail to handle inbound email on one of my servers. Each user has a local account and I've been using the below /usr/local/etc/procmailrc successfully for years:

DEFAULT=$HOME/mail/
LOGFILE=/var/log/procmail

I've recently added a recipe to direct messages flagged as spam to a separate folder:

:0
* ^X-Spam-Flag: YES
$HOME/mail/.Junk/

However, it seems in some cases the messages going into this folder are owned by root instead of the correct user. I've never had this issue with the Inbox, and it also seems like it only affects certain users.

I managed to catch one of the Procmail processes in ps and it does seem to run as the correct user. (This user also has root owned mail in the Junk folder)

# ps axu | grep procmail
{correct-local-username}   7402   0.0  0.2  12140   1780 ??  Ss   11:37AM      0:00.01 /usr/local/bin/procmail -a

Does anyone have an idea why messages handled by the recipe would end up owned by root, while messages going to the default folder would get the correct owner?

Is there anything I can do (even if it's hacky such as calling chown from the Procmail recipe) to make sure the messages are always owned by the correct user?

In case it's of importance, Procmail is configured in Postix as follows:

mailbox_command = /usr/local/bin/procmail -a "$EXTENSION"
USD Matt
  • 5,321
  • 14
  • 23

1 Answers1

5

Check the permissions on the junk folder are correct, but could you also add the following to your procmail.cf:

DROPPRIVS=yes

I'm no expert on procmail, but according to this man entry, it should drop any priveleges that procmail has had, and the recipient doesn't (emphasis mine).

 DROPPRIVS            If  set  to  `yes'  procmail   will   drop   all
                      privileges  it  might  have  had (suid or sgid).
                      This is only useful if  you  want  to  guarantee
                      that the bottom half of the /etc/procmailrc file
                      is executed on behalf of the recipient.

Key part; executed on behalf of the recipient.

Explanation of why this works form user @Tripleee:

The DEFAULT delivery happens after an implicit DROPPRIVS, but if you explicitly deliver something while in privileged mode, you also need to explicitly drop your privileges.

Joe Brailsford
  • 1,091
  • 8
  • 10
  • Thank you. I still don't know why mail in `Inbox` would have correct owner but not in `Junk`, but this seems to fix it at least. – USD Matt Jun 20 '17 at 11:01
  • "I'm no expert on procmail" - I've never used procmail, hell yeah. Happy I could help my dude :) – Joe Brailsford Jun 20 '17 at 11:03
  • As for why the permissions change, I'd guess that any mail that doesn't match a recipe is just dropped into the inbox - there's no processing involved, so procmail is most likely not interacting with the mail in any special way, whereas mail that hits a recipe is forcibly moved, presumably it's that specific 'move' process that applies the current (procmail's - root) user priv's. An easy test: try it with other folders, if the same happens. – Joe Brailsford Jun 20 '17 at 11:08
  • 2
    The DEFAULT delivery happens after an implicit `DROPPRIVS`, but if you explicitly deliver something while in privileged mode, you also need to explicitly drop your privileges. – tripleee Jun 20 '17 at 11:25
  • Please do consider adding @tripleee's comment to this answer. – user Jun 20 '17 at 14:32