Я использую postfix на своем сервере Debian (wheezy) и настроил его на использование policyd-weight следующим образом в файле main.cf:
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unlisted_recipient,
warn_if_reject check_policy_service inet:127.0.0.1:12525,
check_policy_service inet:127.0.0.1:10023,
permit
Некоторое время назад ранее работавшая установка начала отказываться от электронной почты, потому что она не могла связаться с демоном policyd-weight (следовательно, warn_if_reject, чтобы переопределить поведение bounce). Я проверил демон, он действительно работает и прослушивает порт 12525:
tcp 0 0 127.0.0.1:12525 0.0.0.0:* LISTEN 20005/policyd-weigh
В следующем сообщении об ошибке указывается, что, по моему мнению, лежит в основе проблемы:
Feb 1 12:25:34 ginger postfix/policyd-weight[4446]: warning: child: could not open RBL Lookup Socket to config: IO::Socket::INET: Bad hostname 'config' Invalid argument
Feb 1 12:25:34 ginger postfix/policyd-weight[4446]: warning: child: err: can't resolve "config" to address at /usr/lib/perl5/Net/DNS/Resolver/Base.pm line 755, <GEN14499> line 26.#012
Из этого мне кажется, что проблема действительно связана с политикой веса и связана с проблемой разрешения DNS. Сначала я подумал, что этому policyd-weight как-то ранее было присвоено имя хоста config, и я попытался преобразовать * config в IP-адрес. Однако мне не удалось найти никаких ссылок на config в файлах конфигурации policyd-weight.
Затем я понял, что, возможно, это был сервер имен, с которым policyd-weight не смог связаться (эта реализация отсутствует в большинстве сообщений, которые ссылаются на вышеуказанное предупреждающее сообщение postfix / policyd-weight), например он думал, что был назван сервер имен config (в моей настройке нет, так что это должно было потерпеть неудачу). И действительно, что-то подобное есть в /etc/resolv.conf файл:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver config
nameserver 213.133.100.100
nameserver 213.133.98.98
Я думаю, что линия действительно должна быть такой
# nameserver config
поскольку именно это предлагает большинство сообщений в Интернете (первые четыре обращения в Google для "конфигурация сервера имен" hetzner; невозможно разместить более двух ссылок из-за репутации), и эта конфигурация, скорее всего, будет унаследована от конфигурации по умолчанию, которую мой хостер использует при своих установках (имеется в виду их серверы имён):
/etc/resolvconf/resolv.conf.d/original
### Hetzner Online AG installimage
# nameserver 127.0.0.1
nameserver config
nameserver 213.133.100.100
nameserver 213.133.98.98
nameserver 213.133.99.99
nameserver 2a01:4f8:0:a111::add:9898
nameserver 2a01:4f8:0:a102::add:9999
nameserver 2a01:4f8:0:a0a1::add:1010
Комментирование вручную конфигурация сервера имен в /etc/resolv.conf и перезапуск policyd-weight работает нормально, и я вижу из X-policyd-weight заголовок входящих писем, что все работает нормально.
Однако мне не удается удалить или изменить эту строку навсегда. resolvconf похоже, не использует это /etc/resolvconf/resolv.conf.d/original файл при обновлении, поэтому всякий раз, когда я запускаю resolvconf -u он вызывает в точности версию /etc/resolv.conf Я цитировал выше.
/ и т.д. / сеть / интерфейсы не включает никаких серверов имен и, насколько мне известно, я тоже не использую NetworkManager. Должен ли я использовать что-то в следующей строке для определения серверов имен в / и т.д. / сеть / интерфейсы (как было предложено Руководство Debian)?
dns-nameservers 12.34.56.78 12.34.56.79
Я все еще хотел бы узнать, где (без комментариев) конфигурация сервера имен линия исходит и почему resolvconf восстанавливает его при каждом обновлении. С чего бы начать поиски?