Postfix, VPN и smarthost: ред није firewall

Држање поште у реду док се VPN не подигне је проблем заказивања, а уобичајено решење је зауставити Postfix, заменити main.cf и поново га покренути. То ради и погрешног је облика, јер меша два захтева: када испоруку треба покушати и који мрежни пут је може носити. Други је одлука firewall-а и ниједна Postfix директива је не може донети. Кад се два раздвоје, сваки има мали и проверљив одговор.

Држите одредиште relay-а стабилним, блокирајте директну испоруку на мрежној граници и пустите ред да чека.

Два захтева која људи спајају у један

Relay говори Postfix-у где да преда пошту; relayhost = [smtp.corp.example]:587 именује хост и порт, а заграде потискују MX-базирани избор за тај следећи скок. Пут говори језгру куда пакети смеју ићи. Исправан relayhost без ограничења пута и даље пушта Postfix директно на интернет када то рутинг табела дозволи, а исправан firewall са погрешним relayhost-ом шаље пошту на погрешно место. Ниједно не подразумева друго.

Транспортне мапе, измене по пошиљаоцу и резервни relay-и заслужују исто читање. Стабилан relayhost није доказ да свака конфигурисана рута испоруке користи њега, а резервни пут који заобилази relay иста је грешка у бољој камуфлажи.

Шта defer_transports заправо ради

defer_transports задржава поруке за именоване транспорте, тако да се ниједан покушај испоруке не изводи док их прелаз реда не дотакне. То је контрола заказивања, а пражњење реда је надјачава; то је дизајн, а не дефект. Користите стварна имена транспорта из master.cf, јер прилагођени транспорт или засебно именован relay транспорт није покривен само зато што и његов програм говори SMTP. Обичан поновни покушај је други механизам: уз fail-closed пут, покушаји испоруке једноставно не успевају и остају у реду, без укључене директиве одлагања.

Трајне грешке не чекају пристојно. Лош прималац или одбијена акредитива враћају се или запну као тврда грешка уместо да седе док се тунел не појави, па ред пун одложене поште није аутоматски сигуран ред.

Наметните пут на мрежном слоју

Ограничење припада граници локалног излаза или унутар изолованог мрежног именског простора. Мора да покрије стварне адресе relay-а, транспорт и порт, укључујући IPv6 ако је омогућен, јер правило које блокира TCP 25 не чини ништа за relay на 587 или 465. Држите loopback и локалне путеве предаје одвојеним да сам ред настави да ради. Политика треба да остане затворена када рута тунела нестане или се поново појави под другим именом интерфејса.

Догађај подизања интерфејса не доказује да је relay кроз њега доступан. Зато је кука која провери везу и затим испразни ред погодност, а не гаранција: веза се може променити између провере и покушаја испоруке.

Докажите то једном безазленом поруком

Пошаљите једну безазлену поруку са искљученим VPN-ом, затим прегледајте postqueue -p за разлог одлагања и ID реда. Вратите предвиђени пут и затражите контролисани прелаз реда, гледајући да ли порука одлази кроз relay, а не негде другде. Затим поново прекините пут усред лета и потврдите да се порука враћа у ред. Прегледајте maximal_queue_lifetime пре него што одлучите колико прекид може трајати, јер нула значи један покушај, а не неограничено задржавање.

Надзируте старост реда и коришћење диска. Политика која чека VPN претвара се у поштански прекид ако нико не примети да ред расте од петка.

Забележите relay, транспорт, правило firewall-а и животни век заједно. Та четири описују уређење; било које само за себе описује нагађање.