Я использую комбинацию Postfix и Procmail для обработки входящей почты на одном из моих серверов. У каждого пользователя есть локальная учетная запись, и я использовал следующие /usr/local/etc/procmailrc успешно в течение многих лет:
DEFAULT=$HOME/mail/
LOGFILE=/var/log/procmail
Недавно я добавил рецепт, чтобы отправлять сообщения, помеченные как спам, в отдельную папку:
:0
* ^X-Spam-Flag: YES
$HOME/mail/.Junk/
Однако в некоторых случаях кажется, что сообщения, попадающие в эту папку, принадлежат пользователю root, а не правильному пользователю. У меня никогда не было этой проблемы с почтовым ящиком, и, похоже, она затрагивает только определенных пользователей.
Мне удалось поймать один из процессов Procmail в ps и, похоже, он работает как правильный пользователь. (Этот пользователь также имеет почту, принадлежащую пользователю root, в папке нежелательной почты)
# 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
Кто-нибудь знает, почему сообщения, обрабатываемые по рецепту, в конечном итоге принадлежат пользователю root, а сообщения, идущие в папку по умолчанию, получают правильного владельца?
Могу ли я что-нибудь сделать (даже если это взломано, например, вызвать chown из рецепта Procmail), чтобы убедиться, что сообщения всегда принадлежат правильному пользователю?
Если это важно, Procmail настраивается в Postix следующим образом:
mailbox_command = /usr/local/bin/procmail -a "$EXTENSION"
Убедитесь, что права доступа к папке нежелательной почты верны, но не могли бы вы также добавить следующее в свой procmail.cf:
DROPPRIVS=yes
Я не специалист по procmail, но согласно запись этого человека, он должен отбросить все привилегии, которые были у procmail, а у получателя - нет (выделено мной).
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.
Часть ключа; исполняется от имени получателя.
Объяснение того, почему это работает, от пользователя @Tripleee:
Доставка DEFAULT происходит после неявного DROPPRIVS, но если вы явно доставляете что-то в привилегированном режиме, вам также необходимо явно отказаться от своих привилегий.