Я новичок в eximʻe - и унаследовал систему, в которой работает exim, которая плохо себя ведет.
Мой экземпляр перестал отправлять электронные письма. Он принимает сообщения в очередь и работает с -q1h - каждый час для каждого сообщения в очереди он сообщает ...
defer (-53): retry time not reached for any host
Он настроен на использование высокодоступного интеллектуального хоста, поэтому это не проблема удаленного MTA. Действительно работает exim -v из командной строки, чтобы отправить электронное письмо, оно немедленно передается интеллектуальному реле. т.е. нет проблем с маршрутизацией, аутентификацией, доступностью. Exim просто не пытается пересылать эти электронные письма.
Я вижу много и много людей, говорящих, что способ исправить это - сбросить базу данных повторных попыток, удалив только файлы блокировки или базу данных блокировки и повторных попыток. Ни один из методов не повлиял на мой mailq.
NB это не повторная попытка после сбоя - exim никогда не пытался передать сообщение.
Конфигурация повтора по умолчанию:
begin retry
* * F,2h,15m; G16h,1h,1.5; F,4d,6h
Я полагаю, что -q1h является причиной того, что он не пытается сразу передать сообщение. Но почему он не забирает сообщения из очереди?
Поскольку это передается интеллектуальному реле, мне не нужно создавать резервную копию сообщений в течение часа. Если я удалю -q1h из опций, exim будет продолжать сканировать очередь регулярно или просто проигнорирует это?
В-q1h означает, что демон будет обрабатывать очередь один раз в час. Разумно обрабатывать очередь, поскольку даже если вы отправляете через смарт-хост, даже он может быть отключен / недоступен по какой-либо причине и приведет к тому, что сообщения будут помещены в очередь. Если очередь не запущена, эти сообщения никогда не будут отправлены.
Тот факт, что exim сообщает «время повтора не достигнуто ни для одного хоста», означает, что смарт-хост явно был недоступен в какой-то момент. Чтобы предотвратить бесполезную трату ресурсов на неоднократные попытки доступа к автономному узлу, налагается время повтора, которое, по-видимому, еще не достигнуто. Я уверен, что если вы продолжите поиск в журналах, вы увидите, где smarthost был недоступен.
Вы можете принудительно попытаться доставить сообщение, запустив exim -M messageID (вы можете увидеть идентификаторы сообщений с exim -bp или mailq если exim был связан с этим именем).
Я забыл правило №1:
Когда система Redhat / Centos кусает вас в% ^ & *, это, вероятно, SELinux / целевая политика