Два приоритета, и какой из них выигрывает

queue and recipient priority
Один выбирает очередь, другой — порядок внутри неё

Рычагов два, и они разной крупности.

Приоритет очереди — queue-priority в блоке получателя. Он решает, каким очередям соединения и попытки доставки достаются раньше. Шкала числовая, умолчание посередине.

Приоритет получателя назначается правилом по образцу в <pattern-list> — по адресу получателя или по отправителю. Он переставляет получателей внутри очереди.

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

Пример руководства объясняет замысел лучше определения: письма сброса пароля вперёд еженедельной рассылки. Если оба идут в один домен — работает приоритет получателя. Если в разные — приоритет очереди.

Есть и третий путь, не настроечный: командой set-priority можно переставить письма, уже стоящие в очереди.

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

Вторая половина — шкала. Руководство называет её дважды и по-разному: раздел директивы говорит от 0 до 100, раздел про приоритеты — от 1 до 100. Разница в одно значение, и на практике это значит: не пользуйтесь нулём, если хотите предсказуемости.

Что делает Хаб. Не задействует ни один из двух: приоритеты очередей в правилах получателей не задаются, правил по образцу с приоритетом получателя тоже нет.

Разведение срочного и массового у нас идёт другим способом — отдельными адресами отправки: у прогрева свой поток, у рассылки свой, и конкурируют они не приоритетами, а пределами каждый в своей очереди.

Пример в конфигурации
# два рычага: приоритет очереди и приоритет получателя внутри неё
<domain someplace.com>
    queue-priority 75</domain>

<pattern-list myList>
    rcpt-to /password-reset@customer.com/ recipient-priority=100
    mail-from /newsletter/ recipient-priority=25
</pattern-list>
Первый решает, какой домен обслуживается раньше. Второй переставляет письма внутри домена — обогнать другой домен он не может.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ждут, что приоритет получателя обгонит чужую очередь

§ 11.9

Чем чреватоОн переставляет письма только внутри своей очереди. Срочное письмо в загруженный домен уйдёт раньше прочих писем в тот же домен — и не раньше писем в другие домены.
Как заметитьПриоритет получателя задан, а срочные письма всё равно ждут освобождения соединений.
Как правильноДля разных доменов пользоваться приоритетом очереди; приоритет получателя — только для порядка внутри одного.

Полагаются на нулевое значение шкалы

§ 11.9

Чем чреватоРуководство называет диапазон дважды и по-разному: раздел директивы — от нуля, раздел про приоритеты — от единицы. Поведение нуля из этого не выводится.
Как заметитьОчередь с нулевым приоритетом ведёт себя не так, как ожидалось.
Как правильноНе пользоваться нулём: единица так же низка и однозначна.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Как проверить на узле
Приоритеты видно в конфигурации, порядок в очереди — командой перечисления:
grep -n 'queue-priority\|recipient-priority' /etc/pmta/config /etc/pmta/virtualhost.txt
pmta list --priority --maxitems=20
Вторая команда показывает приоритет у каждого получателя в очереди. Если он одинаков у всех, приоритет получателя не назначается ничем — правил по образцу нет.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Прогрев адресов