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 и рокот на траење заедно. Тие четири го опишуваат распоредот; било кое од нив самостојно опишува претпоставка.