Короткая запись из разряда «заметил, но не разобрал». Пишу её именно в таком виде, потому что список незакрытого — часть честного отчёта, а не то, о чём стоит молчать до появления красивого решения.

Что я увидел

Разбирая логи почтового сервера по другому поводу, обратил внимание на цифры резолвинга в rspamd:

800–1200 мс на один DNS-запрос, при 42–52 запросах на одно письмо.

Перемножьте. Даже по нижней границе получается заметная задержка на каждом входящем письме; по верхней — десятки секунд.

Само по себе количество запросов нормально: rspamd проверяет отправителя по множеству списков, и каждая проверка — это обращение к DNS. Ненормально время одного запроса. Секунда на резолв — это очень много для сервиса, который стоит рядом.

Гипотеза

Одна: возможно, rspamd не использует встроенный резолвер unbound-mailcow, а ходит куда-то наружу — к резолверу провайдера или к публичному.

Подчёркиваю: это гипотеза, а не диагноз. Я её не проверял и ничего не исправлял. Она объясняет наблюдаемое, но объяснять наблюдаемое — слишком низкая планка: неверные версии делают это ничуть не хуже верных.

Как это проверить

Если у вас похожая картина, начать можно с трёх команд:

# какой резолвер видит rspamd
docker compose exec rspamd-mailcow cat /etc/resolv.conf
# ищем таймауты и медленные запросы
docker compose logs --tail=1000 rspamd-mailcow | grep -iE 'dns|timeout|resolv'
# жив ли встроенный unbound
docker compose ps unbound-mailcow

Первая отвечает на главный вопрос — к кому rspamd вообще ходит. Третья проверяет обратное предположение: может, встроенный резолвер просто не поднят, и тогда объяснение совсем другое.

Дальше — замерить время ответа у unbound-mailcow напрямую и сравнить с тем, что даёт нынешний резолвер. Смысл именно в сравнении. Абсолютное «секунда на запрос» само по себе ещё не приговор: надо увидеть, что альтернатива быстрее. Иначе можно переключить резолвер и обнаружить, что дело было не в нём.

Чем грозит, если не трогать

Задержкой доставки на каждом входящем письме. При большом потоке — очередью на приёме: письма не теряются, но приходят с опозданием, и опоздание растёт вместе с нагрузкой.

Но есть следствие похуже, и оно не про скорость. При таймаутах RBL-проверки просто не срабатывают. Список, до которого rspamd не достучался, не говорит «этот отправитель чист» — он не говорит ничего, и письмо проходит дальше без этой проверки.

То есть медленный DNS тихо ухудшает качество фильтрации. Спама становится больше, и объяснить это будет нечем: правила на месте, настройки не менялись, антиспам работает. Просто часть проверок не успевает ответить.

Отдельно неприятно то, что такая проблема не выглядит как поломка. Почта работает, письма доходят, ошибок нет. Есть только «что-то у нас почта медленная» и «что-то спама прибавилось» — две жалобы, которые никто не свяжет друг с другом, пока не посмотрит на время резолвинга.

Почему пишу, не разобравшись

Потому что «замечено, не разобрано» — законный пункт отчёта, а не черновик, который надо прятать до готовности.

Если однажды я вернусь к этому и выясню причину, напишу по фактам. Пока — вот наблюдение, вот гипотеза, вот способ проверить. Ненайденное отличается от несуществующего, и честнее назвать границу, чем сделать вид, что её нет.