Postfix, VPN і smarthost: черга — не міжмережевий екран

Тримати пошту в черзі до підняття VPN — це задача планування, і звичайне рішення — зупинити Postfix, замінити main.cf і запустити його знову. Це працює, і це неправильна форма, бо змішує дві вимоги: коли слід намагатися доставити і який мережевий шлях може це нести. Друге — рішення міжмережевого екрана, і жодна директива Postfix не може його ухвалити. Щойно їх розділити, кожна має невелику й перевірювану відповідь.

Тримайте призначення релея стабільним, блокуйте пряму доставку на межі мережі і дозвольте черзі чекати.

Дві вимоги, які люди зливають в одну

Релей повідомляє Postfix, куди передавати пошту; relayhost = [smtp.corp.example]:587 задає хост і порт, а квадратні дужки пригнічують вибір за MX для цього наступного переходу. Шлях повідомляє ядру, куди пакетам дозволено йти. Правильний relayhost без обмеження шляху все одно дозволяє Postfix виходити в інтернет напряму, коли таблиця маршрутизації це дозволяє, а правильний міжмережевий екран із неправильним relayhost надсилає пошту не туди. Жодне не випливає з іншого.

Карти транспорту, перевизначення для окремих відправників і резервні релеї заслуговують на таке саме прочитання. Стабільний relayhost не доводить, що кожен налаштований маршрут доставки його використовує, а резервний шлях в обхід релея — та сама помилка в кращому маскуванні.

Що насправді робить defer_transports

defer_transports утримує повідомлення для зазначених транспортів, тому спроба доставки не робиться, доки їх не торкнеться один прохід черги. Це керування плануванням, і очищення черги його перекриває; це задум, а не дефект. Використовуйте справжні назви транспортів із master.cf, бо власний транспорт або окремо названий транспорт релея не охоплюється лише тому, що його програма теж говорить SMTP. Звичайна повторна спроба — інший механізм: за шляху fail-closed спроби доставки просто не вдаються й залишаються в черзі, без жодної директиви відкладення.

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

Забезпечте шлях на мережевому рівні

Обмеження належить межі локального виводу або внутрішній частині ізольованого мережевого простору імен. Воно має охоплювати реальні адреси релея, транспорт і порт, включно з IPv6, якщо його ввімкнено, бо правило, що блокує TCP 25, нічого не робить для релея на 587 або 465. Тримайте loopback і локальні шляхи подання окремо, щоб сама черга працювала далі. Політика має залишатися закритою, коли маршрут тунелю зникає або з’являється знову під іншим іменем інтерфейсу.

Подія підняття інтерфейсу не доводить, що релей доступний через нього. Тому перехоплювач, який перевіряє зв’язок і потім очищає чергу, — це зручність, а не гарантія: зв’язок може змінитися між перевіркою та спробою доставки.

Доведіть це одним нешкідливим повідомленням

Надішліть одне нешкідливе повідомлення, коли VPN опущено, потім перегляньте postqueue -p щодо причини відкладення та ID черги. Відновіть потрібний шлях і запитайте контрольований прохід черги, спостерігаючи, чи повідомлення виходить через релей, а не кудись інде. Потім знову розірвіть шлях у середині польоту й підтвердьте, що повідомлення повертається до черги. Перегляньте maximal_queue_lifetime, перш ніж вирішувати, скільки може тривати збій, бо нульове значення означає одну спробу, а не необмежене зберігання.

Стежте за віком черги та використанням диска. Політика, що чекає VPN, перетворюється на збій пошти, якщо ніхто не помітить, що черга зростає від п’ятниці.

Записуйте релей, транспорт, правило міжмережевого екрана і термін життя разом. Ці чотири описують устрій; будь-яке з них окремо описує здогад.