Postfix, VPN i smarthost: kolejka to nie firewall

Trzymanie poczty w kolejce, aż VPN się podniesie, to problem planowania, a zwykłym rozwiązaniem jest zatrzymanie Postfixa, podmiana main.cf i ponowne uruchomienie. To działa i jest złą formą, bo miesza dwa wymagania: kiedy próbować dostarczenia i która ścieżka sieciowa może je nieść. Drugie jest decyzją firewalla i żadna dyrektywa Postfixa nie może jej podjąć. Gdy oba się rozdzieli, każde ma małą i sprawdzalną odpowiedź.

Utrzymaj stabilny cel relay, zablokuj bezpośrednie dostarczanie na granicy sieci i pozwól kolejce czekać.

Dwa wymagania, które ludzie łączą w jedno

Relay mówi Postfixowi, gdzie przekazać pocztę; relayhost = [smtp.corp.example]:587 wskazuje host i port, a nawiasy tłumią wybór oparty na MX dla tego następnego skoku. Ścieżka mówi jąderu, dokąd pakietom wolno iść. Poprawny relayhost bez ograniczenia ścieżki nadal pozwala Postfixowi dotrzeć do internetu bezpośrednio, gdy tablica routingu na to pozwoli, a poprawny firewall z błędnym relayhost wysyła pocztę w złe miejsce. Żadne nie wynika z drugiego.

Mapy transportu, nadpisania dla poszczególnych nadawców i zapasowe relaye zasługują na to samo czytanie. Stabilny relayhost nie jest dowodem, że każda skonfigurowana trasa dostarczania go używa, a trasa zapasowa omijająca relay to ten sam błąd w lepszym kamuflażu.

Co faktycznie robi defer_transports

defer_transports wstrzymuje wiadomości dla nazwanych transportów, więc żadna próba dostarczenia nie jest podejmowana, dopóki jedno przejście kolejki ich nie dotknie. To kontrola planowania, a opróżnienie kolejki ją unieważnia; to jest projekt, a nie defekt. Używaj prawdziwych nazw transportów z master.cf, bo własny transport lub osobno nazwany transport relay nie jest objęty tylko dlatego, że jego program także mówi po SMTP. Zwykła ponowna próba to inny mechanizm: przy ścieżce fail-closed próby dostarczenia po prostu zawodzą i zostają w kolejce, bez żadnej dyrektywy odroczenia.

Trwałe błędy nie czekają uprzejmie. Zły odbiorca lub odrzucone poświadczenie odbija się lub zawiesza jako twardy błąd, zamiast czekać, aż pojawi się tunel, więc kolejka pełna odroczonej poczty nie jest automatycznie bezpieczną kolejką.

Wymuś ścieżkę w warstwie sieci

Ograniczenie należy do granicy lokalnego wyjścia lub do wnętrza izolowanej przestrzeni nazw sieci. Musi obejmować rzeczywiste adresy relay, transport i port, w tym IPv6, jeśli jest włączony, bo reguła blokująca TCP 25 nic nie robi dla relay na 587 lub 465. Trzymaj loopback i lokalne ścieżki wysyłania osobno, aby sama kolejka działała dalej. Polityka powinna pozostać zamknięta, gdy trasa tunelu znika lub pojawia się ponownie pod inną nazwą interfejsu.

Zdarzenie podniesienia interfejsu nie dowodzi, że relay jest przez niego osiągalny. Dlatego hook, który sprawdza łącze i potem opróżnia kolejkę, jest wygodą, a nie gwarancją: łącze może się zmienić między sprawdzeniem a próbą dostarczenia.

Udowodnij to jedną nieszkodliwą wiadomością

Wyślij jedną nieszkodliwą wiadomość przy wyłączonym VPN, a następnie sprawdź postqueue -p pod kątem powodu odroczenia i ID kolejki. Przywróć zamierzoną ścieżkę i poproś o kontrolowane przejście kolejki, obserwując, czy wiadomość wychodzi przez relay, a nie gdzie indziej. Potem ponownie przerwij ścieżkę w locie i potwierdź, że wiadomość wraca do kolejki. Przejrzyj maximal_queue_lifetime, zanim zdecydujesz, jak długo może trwać awaria, bo wartość zero oznacza jedną próbę, a nie nieograniczone przechowywanie.

Monitoruj wiek kolejki i użycie dysku. Polityka czekająca na VPN zamienia się w awarię poczty, jeśli nikt nie zauważy, że kolejka rośnie od piątku.

Zapisuj relay, transport, regułę firewalla i czas życia razem. Te cztery opisują układ; każde z nich osobno opisuje domysł.