Всё, что руководство требует до установки MTA. Ни одно из требований не выглядит серьёзным по отдельности, и каждое, не выполненное, проявляется позже и не там, где его ищут.
Поддерживаемая система и архитектура. Список конечен, и попытка поставить MTA на что-то за его пределами не даёт внятной ошибки.
Статический адрес и доменное имя. Адрес отправки — основа репутации: сменившийся адрес означает репутацию с нуля. Имя нужно не меньше — им узел представляется приёмнику.
Доступный резолвер. Может стоять и на другой машине, но должен быть рекурсивным: MTA сам по цепочке серверов имён не ходит.
Синхронное время по NTP. Расхождение часов ломает не отправку, а разбор: события в учёте и журнале перестают сходиться с тем, что видят приёмники и Хаб.
Посчитанное железо. Не «побольше», а по двум правилам: память от числа получателей в очереди, диск от объёма писем (capacity-sizing).
Ключ лицензии запрашивается у поддержки вендора заранее — без него MTA не заработает.
Чего проверка не покрывает: статичность адреса, рекурсивность резолвера, синхронность часов и наличие ключа лицензии. Это остаётся на том, кто заводит узел.
Пороги у нас — «вообще пригоден», а не расчёт под план: посчитать железо от планируемого объёма Хаб мог бы, данных хватает, но профиля отправки пока нет.
Шесть требований и что проверяет каждое:
| Требование | Чем грозит невыполнение | Проверяется |
|---|---|---|
| поддерживаемая система | установка без внятной ошибки | до установки |
| статический адрес и имя | смена адреса обнуляет репутацию | у провайдера, не на узле |
| рекурсивный резолвер | отказы доставки, похожие на проблемы приёмника | запросом к нему |
| синхронное время | расхождение учёта с реальностью | сравнением с внешним источником |
| посчитанное железо | упор в память или диск под нагрузкой | двумя правилами прикидки |
| ключ лицензии | MTA не запустится | заранее, у поддержки |
Порядок проверки — от необратимого к поправимому. Адрес и имя менять после того, как на них появилась репутация, дороже всего; память и диск на большинстве площадок добавляются на ходу.
Резолвер проверять запросом, а не наличием строки в настройках. Прописанный, но нерекурсивный резолвер выглядит настроенным и не работает.
# шесть проверок одной страницей hostnamectl && ip -4 addr show dig +short @127.0.0.1 gmail.com MX # резолвер отвечает и рекурсивенtimedatectl | grep -i 'synchronized' nproc && free -m && df -h /var
▲
Типичные ошибки и проблемы
что делают не так и чем это кончается3 ошибки▶
Считают адрес статическим, не закрепив его у провайдера
§ 1.7
Прописывают резолвер, не проверив, что он рекурсивный
§ 1.7
Откладывают синхронизацию часов
§ 1.7
Связанные записи
3 связи
Как перевести план отправки в железоДаёт те два правила, по которым считаются память и диск. § 1.7.1.2Ограничения облакаВ облаке к списку добавляется своё: снятое ограничение на исходящий почтовый порт. § 1.7
Чем опасна виртуальная машинаПорядок действий, в котором механизм и применяется. § 2.5Установка на LinuxВсе требования к машине должны быть выполнены до этого шага. § 1.2name-serverGlobalРезолвер — одно из требований к машине, на которой узел будет работать. § 1.2thread-reuseGlobalЕдинственная настройка, чьё умолчание зависит от архитектуры машины, на которой узел будет работать. § 3.3.1.38
pmta show status pmta show license pmta resolve gmail.com MX
Что ещё почитать
3 статьи
◇Ключ активации — условие установки, а не шаг после неёБез ключа активации от поддержки SparkPost MTA не ставится и не работает, а уровень лицензии задаёт потолок исходящих соединений: на стандартной всё сверх 200 игнорируется.◇Ограничения облакаОблака ограничивают исходящую почту через порт 25, пока не попросишь снять лимит, а их диапазоны адресов почтовики встречают с подозрением.◇Как перевести план отправки в железоДве постоянные, по которым считается любой узел: около 2 КБ памяти на каждого получателя в очереди и место под спул, пропорциональное суммарному размеру писем.
- Цена ошибки
- безопасно: неверное значение ничего не ломает
- Сценарии
- Планирование мощности · Подготовить узел к отправке
- Важность
- критично