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, се превръща в пощенски срив, ако никой не забележи, че опашката расте от петък.

Записвайте релея, транспорта, правилото на защитната стена и живота заедно. Тези четири описват подредбата; всяко едно от тях само описва догадка.