Вводить новый адрес частью чужого трафика

критично

Warming of IPs with Cold VirtualMTA
Прогрев без отдельной рассылки

Рецепт из руководства, и правило у него одно, зато точное: первые N писем дня к каждому получателю, поданные в прогретый адрес отправки, уходят холодному. Остальные остаются на прогретом.

Норма задаётся на получателя, поэтому и кривая прогрева рисуется получателями: разным приёмникам можно дать разные числа, а всем прочим — общее в блоке <domain *>.

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

Предусловие — первая строка раздела. Механизм для тех, у кого есть хотя бы один прогретый адрес. Парку из одних новых вендор советует лимиты адреса отправки, а не это.

Побочная область применения — переезд. Холодный адрес это просто другой адрес отправки, и через него можно уводить часть трафика на новый сервер: в примере руководства он собирает письма в одну очередь queue-to и отдаёт их напрямую по smtp-hosts.

Главная ловушка — умножение на получателей. Норма задаётся на каждого, и десять крупных приёмников превращают 1000/day в десять тысяч писем с нового адреса за сутки. Это не прогрев, а объём, которым новый адрес зарабатывает отказы.
Что делает Хаб. Не пользуется: прогрев ведёт план — своё расписание, библиотека сообщений, резервный пул адресов и остановка по доле спама. Движковый рецепт отдаёт часть боевого трафика, и прогрев становится его заложником: нет рассылки в этот день — нет и прогрева. Разумная гибридная форма, если решим её строить: Хаб считает суточное число, MTA исполняет разделение.
Рекомендуемые значения

У рецепта нет значений — есть шаги. Решается здесь одно: как рисовать кривую.

Как задать норму Что получаете Когда
одно число в <domain *> одинаково всем получателям начало, пока приёмники не разделены
лесенка через запятую рост по дням, последнее значение повторяется обычный случай: прогрев — это рост
свои числа по получателям разная кривая у разных приёмников когда известно, кто строже

От чего считать. На одного крупного получателя, а не на весь объём: число умножается на количество приёмников. Начинать разумно с единиц-десятков писем в сутки на получателя и удваивать раз в несколько дней, глядя на долю отказов самого холодного адреса.

Правило «первые N на получателя в сутки», обнуление в полночь, сохранение счётчиков и предусловие про прогретый адрес — из руководства (§ 11.6). Кривая и порядок величин — наши.
Пример в конфигурации
# прогретый отдаёт первые письма дня; холодный шлёт по своим настройкам
<virtual-mta vmta1>
    smtp-source-host 1.2.3.4 vmta1.example.com
    cold-virtual-mta vmta2    <domain *>
        max-cold-virtual-mta-msg 1000/day
    </domain>
</virtual-mta>

<virtual-mta vmta2>
    smtp-source-host 5.6.7.8 vmta2.example.com
    <domain *>
        max-msg-rate 100/h
    </domain>
</virtual-mta>
Пример руководства. Тысяча писем на каждого получателя в сутки — на десяти крупных приёмниках это десять тысяч. Для настоящего начала прогрева число надо ставить на два-три порядка меньше и растить лесенкой.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Считают норму на весь объём

§ 11.6

Чем чревато1000/day при десяти крупных приёмниках — десять тысяч писем с нового адреса за сутки. Новый адрес получает объём, который прогревом уже не является, и вместо истории зарабатывает отказы.
Как заметитьДоля отказов у холодного адреса растёт с первого дня, при том что расчётный объём выглядел безопасным.
Как правильноДелить задуманный суточный объём на число получателей, которым парк реально пишет, и задавать результат лесенкой от единиц.

Прогревают, не имея прогретого адреса

§ 11.6

Чем чреватоОтдавать нечего: весь трафик и так с новых адресов. Механизм перекладывает его между ними, а истории не строит ни один.
Как заметитьНастройка сделана, доля отказов у всех адресов одинаково высокая.
Как правильноПользоваться лимитами адреса отправки — так советует первая строка раздела руководства.

Ставят постоянное число и называют это прогревом

§ 11.6

Чем чреватоСто писем в день с первого дня — это не прогрев, а сразу сотня писем с адреса без истории. Смысл прогрева в росте: получатель должен видеть аккуратно увеличивающийся поток.
Как заметитьПервые дни гладко, потом временные отказы и попадание в папку «Спам» — репутация не успела сложиться.
Как правильноЗадавать лесенку и удваивать значение раз в несколько дней, сверяясь с долей отказов именно холодного адреса.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у рецепта не бывает — это порядок действий. Но наследование участвует в его исходе: cold-virtual-mta можно записать в <virtual-mta-pool>, и тогда напарник достанется каждому участнику. А холодный адрес не наследует ничего от прогретого: всё, чем он отправляет, задаётся в его собственном блоке.
Как проверить на узле
Проверяется по учёту — узел отдельного счётчика не показывает:
pmtaacctfind --output csv[vmta,rcpt,timeLogged] /var/log/pmta/acct-*.csv
Имя холодного адреса должно появляться на первых письмах дня к каждому получателю и исчезать после выборки нормы. Если его нет вовсе — проверьте обе половины настройки и что письма подаются по SMTP: отбор идёт при приёме.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Планирование мощности · Прогрев адресов
Важность
критично