У меня следующая проблема: у меня недавно появился новый рабочий компьютер (тестирование Debian, codenme: stretch), и мне пришлось переустановить fetchmail и procmail чтобы читать мои электронные письма с mutt. Сейчас, fetchmail также хорошо работает mutt работает, только почтовый ящик спула моих писем, кажется, остается таким же по умолчанию, /var/mail/user.
В моем .fetchmailrc Я определил mda это должно быть выполнено с помощью:
mda '/usr/bin/procmail -f %F -d %T';
и .procmailrc то, что я создал, выглядит так:
# Please check if all the paths in PATH are reachable, remove the ones that
# are not.
SHELL=/bin/sh
PATH=$HOME/bin:/usr/bin:/usr/ucb:/bin:/usr/local/bin:.
MAILDIR=$HOME/Mail # Youd better make sure it exists
SPOOL=$HOME/Mail/mbox
DEFAULT=$MAILDIR/mbox
ORGMAIL=$MAILDIR/mbox
LOGFILE=$MAILDIR/log
LOCKFILE=$HOME/.lockmail
VERBOSE= yes
LOGABSTRACT= all
Посмотрев везде, где я мог, изменил и проверил разрешения rc файлов и почтовой папки снова и снова, наконец, пытаясь удалить все и переустановить, ничего не изменилось: все письма по-прежнему доставляются в /var/mail/user даже когда я вставляю некоторые условия доставки в .procmailrc.
Наконец я заметил, что нет /etc/procmailrc файл (как я думаю, он должен быть), а также все log файлы, которые должны существовать и быть записанными, не существуют.
fetchmail вызывает procmail, потому что $ fetchmail -vvv во входящем электронном письме в более длинном выводе есть такая строка:
fetchmail: about to deliver with: /usr/bin/procmail -f 'email@addres' -d 'user'
Мой вывод таков procmail не работает должным образом или вообще. Электронные письма все еще приходят, но все они находятся в почтовом ящике / папке по умолчанию, и я не могу перемещать их, пока они доставляются (когда я нахожусь в mutt Я могу сохранить их во всех почтовых ящиках, которые у меня есть или которые я могу определить).
Я был бы очень признателен, если бы кто-нибудь помог мне решить эту проблему!
С уважением.
В LOCKFILE назначение вообще запрещает Procmail что-либо делать.
Изучение вывода Procmail при стандартной ошибке с помощью procmail -m VERBOSE=yes .procmailrc </dev/null должен легко показать, что он вечно ждет блокировки и в конце концов сдастся.
Смотрите также http://www.iki.fi/era/procmail/mini-faq.html#locking и http://www.iki.fi/era/mail/procmail-debug.html
Как правило, трогать не нужно ORGMAIL по любой причине тоже.
Procmail не требует /etc/procmailrc файл; если он существует, он будет вызван перед вашим .procmailrc, но это не должно быть необходимым или особенно полезным в вашем сценарии.
Обычно ваш .procmailrc должен существовать в вашем домашнем каталоге с доступом для чтения (и, по практическим соображениям обслуживания, для записи), только для вас. В зависимости от того, как fetchmail бежит procmail, могут быть обстоятельства, которые не ясны из вашего вопроса - например, если fetchmail не работает как root как и вы, он может не иметь разрешения на переключение на ваш UID.
Для устранения неполадок, возможно, переместите обычный .procmailrc в сторону и попробуйте действительно простой, общий, который, возможно, просто назначает LOGFILE=/tmp/procmail-testing.log и завершает работу с разрешением на чтение для всех. Если у вас получится заставить это работать, возможно LOG=`whoami` чтобы вы могли видеть, с какими разрешениями он работает.