Конфигурация PowerMTA.
Генератор, версии
и ночная сверка.

Сводка раздела — пять плиток о конфигурации всех серверов сразу. Здесь 17 серверов под управлением Хаба, 15 из них действительно отправляют письма, в конфигурациях 23 пары «домен + адрес» и ещё 3 адреса приёма у MailerQ, сохранено 68 версий. Плитка «Расхождение с сервером» выделена: на одном сервере файл не совпал с сохранённым. Справа — итог последней сверки и кнопка «Сверить все узлы», которая проверяет PowerMTA и MailerQ одной задачей. Открывайте раздел после любых изменений на серверах и перед большой рассылкой: если плитка расхождений выделена, сначала разберитесь с ним в блоке ниже, а уже потом применяйте новые конфигурации.

Увеличить

• Узлов под управлением — 17.
• Отправляют — 15 — у PowerMTA есть рабочая конфигурация, у MailerQ заданы адреса приёма.
• Пары «домен + адрес» — 23 и ещё 3 адреса приёма у MailerQ.
• Версий сохранено — 68.
• Расхождение с сервером — 1 — плитка выделена.
• Итог сверки — 17 из 17, расхождений 1, устарела 1, 47 минут назад.

Подпись под плитками говорит, какие файлы сверяются у каждого MTA.

Блок «Требует внимания» перечисляет серверы, с которыми что-то не так, — сначала самое срочное, и у каждой строки есть кнопка туда, где это исправляют. Здесь четыре замечания. На mta-07 файл virtualhost.txt изменили в обход Хаба. У tx-01 сверка старше самой конфигурации, и новую версию ещё не проверяли. У lab-01 и mta-11 нет доменов отправки, поэтому собирать конфигурацию пока не из чего — сначала нужно добавить домены. Разбирайте замечания по порядку: расхождение на mta-07 важнее устаревшей сверки, потому что на сервере работает не тот файл, который собрал Хаб.

Увеличить

• mta-07 — virtualhost.txt изменили в обход Хаба.
• tx-01 — сверка старше самой конфигурации — новую ещё не проверяли.
• lab-01 и mta-11 — нет доменов отправки — сначала домены, потом конфигурация.

Блок появляется, только когда есть проблемы.

Карточка сервера tx-01 показывает его конфигурацию PowerMTA так, как она реально применена. Слева — оба файла на сервере с контрольными суммами и пары «домен + адрес», из которых собран второй файл; отметка «ключ ✓» значит, что ключ подписи лежит на сервере. Справа — что настроено: скорость, соединения, расписание повторов, порты и число директив Хаба. Шапка предупреждает «Сверка устарела»: рабочую версию применили после проверки, и кнопка рядом проверит её заново. Карточку открывают, когда нужно быстро понять, как сейчас отправляет сервер, не читая сами файлы. Если цифры не те, что вы ждали, переходите в генератор кнопкой в подвале.

Увеличить

• Шапка — «Сверка устарела»: рабочую версию применили после проверки.
• Файлы на узле — config — зелёная точка, virtualhost.txt — серая: «сверяли прошлую версию».
• Пары — id.corvalis-bank.org · 203.0.113.121, ключ ✓.
• Что настроено — 2 письма в минуту, 5 соединений, по 20 на соединение; повторы 2 → 6 → 12 → 24 ч; подача 2525, приём 25.
• Директивы Хаба — 12 в общем блоке и 2 правила по почтовикам; пресет «Аккуратный».
• Подвал — базовая и рабочая версии, всего 10; «Домены узла» и «Открыть генератор».

Все цифры карточки взяты из применённой версии, а не из формы генератора.

Карточка mta-05 — сервер, у которого все три новых адреса на прогреве. Под скоростью написано «у всех vMTA темп ведёт прогрев»: общие настройки к непрогретому адресу не применяются. Новому адресу Хаб задаёт одно соединение и предел «не выше письма в час», а дальше скорость поднимает план прогрева. По карточке видно, что сервер не тормозит, а намеренно разгоняется постепенно, — менять его настройки вручную не нужно. Если кажется, что сервер отправляет слишком медленно, сначала посмотрите на строку под скоростью: пока адреса прогреваются, общие 10 писем в минуту к ним не применяются.

Увеличить

• Общие настройки — 10 писем в минуту и 15 соединений — к непрогретому адресу не применяются.
• Новый адрес — одно соединение и «не выше письма в час».
• Директивы — 11 в общем блоке, своих значений у vMTA и правил нет.

За дневным объёмом следит сам Хаб, а MTA отвечает только за скорость.

Карточка mta-07 в красной рамке — так выглядит сервер, где конфигурацию правили мимо Хаба. Сверка нашла не тот virtualhost.txt, который туда положил Хаб: итог «Разошлась», у файла показана сумма, которую вернул сервер. Красным выделены только рамка, итог и сам файл — остальная карточка выглядит как обычно, потому что изменился один файл, а не весь сервер. Что именно поменяли, покажет консоль сверки. Такую карточку стоит разобрать сразу: следующее применение из генератора перезапишет ручную правку, поэтому сначала решите, нужна ли она, и если нужна — внесите её в генератор.

Увеличить

• Итог — «Разошлась».
• Файл — сумма, которую вернул сервер.
• Остальное — выглядит как обычно — изменился один файл, а не весь сервер.

Исправить можно двумя способами: собрать заново в генераторе или вернуться к сохранённой версии.

Карточка сервера MailerQ показывает его по понятиям MailerQ, а не по меркам PowerMTA. Файл у него один, и Хаб меняет в нём только свои строки — приём, панель и предпросмотр. Пулы, лимиты и ключи подписи MailerQ хранит в своей управляющей базе, поэтому второго файла нет. Вместо пар «домен + адрес» здесь адреса приёма: два домена на двух адресах. Письма на них передают сам сервер и платформа рассылки, а отправку ограничивает список разрешённых адресов. Открывайте её, когда сервер MailerQ не принимает письма от платформы: первым делом проверьте адреса приёма и список разрешённых адресов.

Увеличить

• Файл — один — /etc/mailerq/config.txt; Хаб меняет в нём только свои строки.
• Второго файла нет — пулы, лимиты и ключи — в управляющей базе MailerQ.
• Адреса приёма — два домена на двух адресах, порт 25251.
• Логин не нужен — отправку ограничивает список разрешённых адресов.

Кнопка внизу ведёт на страницу настройки MailerQ, а не в генератор PowerMTA.

Карточка mta-11 — только что установленный сервер. Базовый файл положила установка MTA, и сверка его подтвердила: «Совпадает». Рабочей конфигурации ещё не было, потому что собирать её не из чего — доменов на сервере нет. Пометка об этом на итог сервера не влияет: после добавления доменов следующий шаг — собрать конфигурацию PowerMTA в генераторе и применить её на сервер. Если сервер уже должен отправлять, добавьте ему домены отправки — переход к доменам сервера есть в подвале карточки. После этого карточка покажет рабочую версию рядом с базовой.

Увеличить

• Базовая версия — есть и совпадает.
• Рабочей конфигурации — ещё не было — доменов на сервере нет.

Серая пометка «рабочей конфигурации ещё не было» — не поломка, а шаг, до которого ещё не дошли.

Лента последних применений хранит всё, что Хаб клал на серверы: 68 версий за всё время, на экране последние 12. По каждой видно, когда и на какой сервер её положили, базовая она или рабочая, контрольную сумму и ответ MTA. На примере tx-01 видна вся вчерашняя история сервера. Чтобы откатить конфигурацию PowerMTA, достаточно нажать «Вернуться к ней» у нужной версии; действующая версия помечена «действует». Ленту открывают, когда после применения что-то пошло не так: найдите последнюю версию, которую MTA принял без замечаний, и вернитесь к ней. Версия с пометкой «такая же, как действующая» ничего не изменит.

Увеличить

• По каждой — когда, сервер, вид, контрольная сумма и что ответил MTA.
• История tx-01 — правка, возврат к версии 8 октября и сегодняшнее применение.
• Действия — «действует», «такая же, как действующая» или «Вернуться к ней».

Версии MailerQ вернуть нельзя: они хранятся со скрытыми паролями.

Консоль сверки открывается кнопкой «Сверить все узлы»: это одна задача на все серверы, 17 шагов — по шагу на сервер. Для каждого файла видно, как Хаб считает контрольную сумму и что ответил сервер, а в конце — итог по серверу и общее «Готово». Консоль доказывает, что проверка действительно прошла на каждом сервере, а не просто поставила отметку. Если файл на каком-то сервере разошёлся, ниже видны отличающиеся строки. Сверку стоит запускать вручную после того, как кто-то работал на серверах напрямую, — не дожидаясь ночной проверки. Итог появится в сводке вверху страницы.

Увеличить

• Для каждого файла — команда sha256sum, ответ сервера и вывод.
• В конце — итог по серверу и общее «Готово».
• Нет сохранённой версии — «сверять не с чем» — не расхождение.

Консоль можно свернуть или открыть отдельно — задача сохраняется в истории.

Если контрольные суммы не совпали, сверка не ограничивается словом «разошлось»: Хаб читает файл с сервера и показывает строки, которые отличаются. «+» — строка есть на сервере, «−» — пропала. Здесь на mta-07 у адреса на прогреве вручную подняли max-smtp-out с одного соединения до трёх. Сверка ничего не исправляет сама: собрать конфигурацию заново в генераторе или вернуться к сохранённой версии решаете вы. Прежде чем решать, выясните, кто менял файл и зачем: правка могла быть намеренной. Если она нужна, перенесите значение в генератор — тогда она переживёт следующее применение.

Увеличить

• mta-07 · config — совпадает с сохранённой версией.
• virtualhost.txt — + max-smtp-out 3, − max-smtp-out 1.
• Итог — файл на узле изменён мимо Хаба.

Комментарий в строке по-прежнему говорит про одно соединение — правку сделали вручную.

Верх генератора — параметры, общие для всего сервера. Пароль подачи — это пароль для логинов vMTA, тот же прописывается в платформе рассылки. Пресет по умолчанию задаёт значения для новых блоков и правил, а «Обратный адрес» подменяет Return-Path, чтобы отказы, пришедшие позже, шли в Хаб; подсказка сразу говорит, что для этого нужно в DNS. Ниже — пары сервера, из которых собираются vMTA: домен, адрес отправки, имя vMTA и селектор ключа подписи. Этот блок заполняют при настройке сервера; пароль подачи потом нужен в платформе рассылки, иначе она не сможет отдавать письма в vMTA.

Увеличить

• Пароль подачи — для логинов vMTA; пул — pmtauser, точка отправки — имя её vMTA.
• Пресет по умолчанию — значения для новых блоков и правил.
• Обратный адрес — подмена Return-Path на bounce@bounce.<домен>.
• Пары — домен, адрес, имя vMTA и селектор ключа подписи.

Пустой пароль оставляет прежний; кнопка рядом создаёт длинный.

Блок «Кому разрешена подача» решает, с каких адресов письма принимаются без пароля. Подключённые скрипты — платформы рассылки, с которыми работает Хаб; их адрес берётся из настроек доступа, а не из адреса сайта, потому что за прокси они разные. Дополнительные адреса и подсети подписаны, чьи они, — здесь это серверы приложения Corvalis. Так видно, кто может слать письма через ваш сервер без логина. Сюда добавляют адрес, когда подключаете новую платформу или сервер приложения, который отдаёт письма напрямую. Список стоит держать коротким и подписанным, чтобы через полгода было ясно, чей это адрес.

Увеличить

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

Без логина с чужого адреса письма не принимаются, с логином — с любого. На приём отказов через порт 25 это не влияет.

Блок <domain *> — общие директивы PowerMTA для всех vMTA сервера. Пресет заполняет его в один клик, а у каждого поля две подписи: что оно значит и как называется директива. Здесь задают темп и соединения, режим замедления (backoff) — как MTA сбавляет скорость, когда почтовик начинает отказывать, — и адрес, на который MTA сообщит о замедлении. Какое значение будет при пустом поле, видно прямо в поле подсказкой. Начните с пресета и меняйте только то, что действительно отличается для вашей отправки: если поле пустое, MTA возьмёт своё значение по умолчанию.

Увеличить

• Темп и соединения — соединения, скорость, писем на соединение, предел по объёму.
• Режим замедления — темп в замедлении, расписание повторов, возврат к обычной скорости.
• Кому сообщать — адрес, на который MTA напишет о замедлении.

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

Ниже — по блоку на каждую пару «домен + адрес», то есть на каждую vMTA, а внутри — правила для почтовиков поверх общих. Почтовик выбирают из списка, где уже вписаны все его домены, или вписывают домен вручную. Так для Gmail, Outlook и других крупных почтовых сервисов скорость и соединения задаются отдельно от остальных. У каждого правила свои кнопки пресетов и удаления, а пустое поле правила берёт значение из настроек своей vMTA. Правила по почтовикам добавляют, когда Gmail или Outlook начинают откладывать письма, а остальные принимают нормально: так скорость снижается только для одного почтовика.

Увеличить

• Почтовик — из списка со всеми его доменами или вручную.
• У tx-01 — Gmail — 2 соединения и письмо в минуту, Outlook — 2 соединения и два письма в минуту.
• Пустое поле — «как у vMTA».

Скорость с пустым полем не превысит общий блок.

Галочка «Переопределить общие» нужна, когда одна vMTA должна работать иначе, чем остальные на сервере. Она даёт этой vMTA собственный набор настроек, в котором сначала стоят текущие общие значения — со всеми правками и адресом для писем о замедлении. Менять нужно только то, чем этот адрес отличается, — остальное уже заполнено. Так отдельный адрес настраивают точечно, не трогая настройки всего сервера. Пользуйтесь галочкой, когда отличается один адрес, а не весь сервер: массовые правки проще внести в общий блок. Иначе со временем станет трудно понять, какие настройки у какого адреса.

Увеличить

• Сначала — текущие общие значения со всеми правками.
• Менять — только то, чем этот адрес отличается.

Остальные vMTA сервера продолжают работать по общему блоку.

Две кнопки внизу генератора разделяют проверку и действие. «Собрать конфигурацию» показывает оба файла и ничего не меняет на сервере — результат можно спокойно посмотреть. «Применить на узел» кладёт файлы в безопасном порядке: копия прежних файлов, проверка синтаксиса средствами MTA, перезагрузка и возврат прежних файлов, если что-то пошло не так. Поэтому ошибка в настройках не оставит сервер без рабочей конфигурации. После применения проверьте журнал по шагам и карточку сервера — там появится новая рабочая версия. Если что-то пошло не так, к прежней версии можно вернуться в ленте применений.

Увеличить

• Собрать конфигурацию — показывает оба файла и ничего не меняет на сервере.
• Применить на узел — копия, проверка синтаксиса, перезагрузка — и возврат при неудаче.

Сначала посмотреть, потом применить.

Предпросмотр основного файла /etc/pmta/config — ровно в том виде, в каком он попадёт на сервер. Его собирает тот же механизм, что и применение, вместе с адресом Хаба для управления и сбора показателей. Поэтому то, что вы видите здесь, и есть будущий config PowerMTA — без сюрпризов после нажатия «Применить на узел». Файл можно скопировать или скачать, чтобы показать коллеге или сохранить у себя. Предпросмотр безопасен: он ничего не меняет на сервере, так что смотреть его можно сколько угодно. Особенно полезно открыть его перед первым применением на новом сервере.

Увеличить

• Совпадает до байта — предпросмотр собирает тот же механизм, что и применение.
• Шапка файла — откуда он взялся и почему его не стоит править руками.
• Скопировать и скачать — кнопки над файлом.

Комментарии в файле — на английском: его читают администраторы, говорящие на разных языках.

Предпросмотр второго файла — /etc/pmta/virtualhost.txt для tx-01. В нём блок <virtual-mta> с ключом подписи, соединениями, адресом отправки и именем HELO, которым сервер представляется почтовику, ниже — общий блок <domain *> и правило для Gmail. Здесь удобно проверить vMTA перед применением: все ли пары на месте и с теми ли ключами подписи. Комментарии в файле — на английском, как и в основном. Если в файле не хватает пары или у vMTA не тот ключ, поправьте пары в генераторе до применения — после него MTA начнёт отправлять именно так.

Увеличить

• <virtual-mta> — ключ подписи, соединения, адрес отправки и HELO.
• <domain *> — общий блок.
• Правило — для Gmail.

Каждая директива подписана комментарием — файл понятен и без Хаба.

Журнал применения показывает по шагам, что происходило на сервере, когда Хаб клал конфигурацию. Сначала подготовка: ключи подписи, доступ Хаба к управлению, сертификат STARTTLS и ключ для передачи показателей. Затем запись файлов, проверка синтаксиса, перезагрузка MTA и веб-монитора и проверка, что порт 25 отвечает снаружи. По журналу видно, на каком шаге возникла бы ошибка, — и что при неудаче Хаб вернул бы прежние файлы. Журнал стоит смотреть после каждого применения: если какой-то шаг не прошёл, здесь видно, на каком именно, и это подскажет, что исправлять — DNS, порт или сам файл.

Увеличить

• Подготовка — ключи подписи, доступ Хаба 198.51.100.250, сертификат STARTTLS, токен показателей.
• Файлы — основной файл и 1 vMTA, проверка синтаксиса — успешно.
• Перезагрузка — конфигурация и веб-монитор.
• Итог — порт 25 отвечает, MTA принял все vMTA.

Последняя строка — главная: адреса отправки и ключи подписи на месте.

Так в предпросмотре выглядит vMTA на прогреве — новый адрес на mta-05. У него одно соединение, адрес отправки и блок WARMUP-MANAGED с ограничением «не выше письма в час на приёмник». За дневным объёмом следит сам Хаб, а PowerMTA отвечает только за скорость. Так прогрев IP-адреса идёт по плану, а не по случайным правкам, и новый адрес не получит лишнего объёма в первые дни. Поэтому для адресов на прогреве скорость в генераторе не правят — достаточно следить за планом в разделе «Прогрев». Как адрес идёт по плану на деле, видно в мониторинге на вкладке «vMTA и задания».

Увеличить

• Одно соединение — адрес новый.
• WARMUP-MANAGED — ограничение «не выше письма в час на приёмник».

Скорость между этими метками задаёт план прогрева, поэтому вручную их не меняют.