Procmail, кажется, не выполняется при получении писем с fetchmail
У меня следующая проблема: я недавно получил новый рабочий компьютер (тестирование 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 Я могу сохранить их во всех почтовых ящиках, которые у меня есть или могут быть определены).
Буду очень признателен, если кто-нибудь поможет мне решить эту проблему!
С уважением.
1 ответ
LOCKFILE назначение не позволяет Procmail вообще что-либо делать.
Проверка вывода Procmail на стандартную ошибку с procmail -m VERBOSE=yes .procmailrc </dev/null должен с готовностью показать, что он всегда ждет на замке, и в конечном итоге сдаваться.
Смотрите также http://www.iki.fi/era/procmail/mini-faq.html и 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` так что вы можете видеть, с какими разрешениями он работает.