Postfix 3.10: aktualizacje, TLSRPT i droga do wersji 3.11

Prawidłowe określenie daty wydania Postfixa 3.10

W momencie przeprowadzania badania, tj. 20 października 2026 r., Postfix 3.10 nie jest aktualną stabilną gałęzią rozwojową: rolę tę pełni Postfix 3.11. Producent klasyfikuje wersję 3.10 jako Gałąź starszych wersji, ale nadal dostarcza do niego poprawki błędów i zabezpieczeń. W oficjalnych ogłoszeniach jako najnowsza dostępna wersja tej gałęzi wymieniono Postfix 3.10.14 z 7 września 2026 r.

To rozróżnienie oddziela dwa różne rodzaje decyzji. Aktualizacja serwisowa, np. z wersji 3.10.8 do nowszej poprawki 3.10, zachowuje wybraną gałąź funkcjonalną i wprowadza jej poprawki. Natomiast aktualizacja do wersji 3.11 powoduje zmianę gałęzi rozwojowej i dlatego musi zostać sprawdzona pod kątem zmienionych funkcji, zgodności konfiguracji, rozszerzeń i procedur operacyjnych. Przejście na wyższą wersję gałęzi głównej i pobocznej nie jest automatycznie odpowiednim rozwiązaniem dla każdego systemu produkcyjnego.

W przypadku pakietów dla systemu Linux, oprócz widocznej wersji Postfixa, sprawdź metadane pakietu, dziennik zmian oraz informacje dotyczące bezpieczeństwa udostępnione przez dostawcę systemu operacyjnego. Sprawdź tam, jakie poprawki zawiera ten konkretny pakiet oraz czy dostawca udokumentował backporty. Ogłoszenie wydawcy głównego opisuje natomiast wydanie Postfixa i nie stanowi dowodu na istnienie ogólnej polityki dotyczącej backportów w danej dystrybucji.

W kontekście planowania konserwacji oznacza to: najpierw należy udokumentować zainstalowaną wersję pakietu, kanał repozytorium oraz lokalne modyfikacje. Następnie należy sprawdzić, jakie poprawki dla tego pakietu podaje dostawca systemu operacyjnego. Dopiero to porównanie pokaże, czy istnieje zaległa Aktualizacja Postfixa czy aktualizacja do wersji 3.10 jest konieczna, czy też planowane przejście na wersję 3.11 przyniosłoby dodatkowe korzyści merytoryczne. Punkt 3.10.14 stanowi w tym kontekście punkt odniesienia dla wersji upstream, a nie instrukcję instalacji dla konkretnego systemu Linux.

Rola MTA, porty SMTP i ograniczenia systemowe

Postfix to Agent transferu poczty (MTA). Przyjmuje wiadomości e-mail za pośrednictwem protokołu SMTP, na podstawie konfiguracji routingu i zasad decyduje o dalszym przetwarzaniu oraz przekazuje wiadomości do innych serwerów pocztowych lub lokalnych ścieżek dostarczania. W ten sposób Postfix stanowi warstwę transportową serwera pocztowego w systemie Linux. Jednak jego konfiguracja nie określa automatycznie, w jaki sposób użytkownicy przeglądają swoje skrzynki pocztowe ani jak oceniane są podejrzane treści.

Serwer IMAP lub POP3 udostępnia skrzynki pocztowe dla programów pocztowych i stanowi odrębny element w stosunku do transportu SMTP. Podobnie funkcje Postfixa nie zastępują kompletnego rozwiązania do filtrowania spamu lub wirusów: takie systemy muszą być w razie potrzeby odpowiednio zintegrowane, konserwowane i monitorowane. To rozróżnienie ma znaczenie praktyczne, ponieważ pomyślny wynik testu SMTP nie świadczy ani o możliwości pobrania wiadomości ze skrzynki pocztowej, ani o jakości sprawdzania treści.

Port 25 służy zazwyczaj do obsługi ruchu SMTP między serwerami pocztowymi, a tym samym do publicznej obsługi MX. Natomiast porty 587 i 465 są przeznaczone do dostarczania wiadomości przez klienty pocztowe, zazwyczaj z uwierzytelnianiem i własną definicją usługi. Postfix traktuje te role nie tylko inaczej pod względem organizacyjnym: niektóre ustawienia nie mogą lub nie powinny obowiązywać ogólnie dla wszystkich usług SMTP.

Przed wprowadzeniem zmian potrzebujesz uprawnień administracyjnych, kopii zapasowej konfiguracji Postfixa umożliwiającej przywrócenie stanu poprzedniego oraz okna serwisowego dostosowanego do kolejki, terminów dostarczania i powiązanych aplikacji. Należy również ustalić, czy serwer wysyła wiadomości wychodzące, odbiera je jako publiczny serwer MX, czy też obsługuje dostarczanie przez klientów. Te zwolnienie ze służby zapobiega sytuacji, w której decyzja dotycząca ochrony danych, uzasadniona z punktu widzenia przesyłania danych, przypadkowo zmieniłaby publicznie dostępny port 25.

TLSRPT zapewnia bezpieczne dostarczanie wiadomości e-mail

Postfix 3.10 oferuje opcjonalną obsługę TLSRPT w kliencie SMTP. Domeny mogą publikować za pośrednictwem DNS adres odbiorcy dla zbiorczych raportów TLS; norma RFC 8460 dopuszcza adresy e-mail oraz punkty końcowe HTTPS. Postfix zgłasza przy tym jedynie powodzenie lub niepowodzenie uzgodnień TLS, maksymalnie jeden status końcowy na każde połączenie SMTP. Nieudane próby nawiązania połączenia oraz przerwania przed lub po uzgodnieniu TLS nie są rejestrowane.

Sam numer wersji 3.10 nie świadczy jednak o tym, że zainstalowany pakiet Postfix rzeczywiście może korzystać z TLSRPT. Funkcja ta wymaga, aby Postfix był wyposażony w bibliotekę kliencką obsługującą TLSRPT oraz opcję kompilacji USE_TLSRPT została utworzona. Przed rozpoczęciem planowania konfiguracji należy zatem sprawdzić na podstawie dokumentacji pakietu, podanych cech kompilacji oraz dostępnych pakietów dodatkowych, czy dana dystrybucja posiada tę obsługę.

TLSRPT uzupełnia procedury, które faktycznie wpływają na zabezpieczenia TLS w procesie dostarczania wiadomości. STARTTLS umożliwia wynegocjowanie szyfrowania transportowego. DANE wykorzystuje wpisy TLSA i opiera swoje założenia bezpieczeństwa na protokole DNSSEC; MTA-STS publikuje politykę dotyczącą oczekiwanych właściwości TLS. W przypadku niepowodzenia obowiązkowego wymogu DANE lub MTA-STS protokół TLSRPT może dostarczyć dalsze informacje o takich błędach. Nie aktywuje on jednak ani szyfrowania, ani samej weryfikacji certyfikatu.

Należy tu rozróżnić dwie role. Domena odbiorcza publikuje Punkt końcowy rua oraz zapewnia lub zleca nadzorowany odbiór oraz analizę przychodzących raportów. Z kolei MTA zgłaszający potrzebuje odpowiednio skonfigurowanego i aktywowanego serwera Postfix oraz oddzielnej infrastruktury, która gromadzi, pobiera, agreguje zdarzenia i wysyła raporty. Te dwie perspektywy mogą być oddzielone organizacyjnie; właściciel domeny publikującej nie musi sam generować raportów TLSRPT na tym samym systemie.

Wtyczka polityki TLS nie jest zatem standardowo częścią każdego łańcucha raportów TLSRPT. Postfix sam obsługuje DANE. Odpowiednia wtyczka staje się szczególnie istotna, gdy wysyłający serwer MTA przekazuje informacje o polityce MTA-STS poprzez smtp_tls_policy_maps . Postfix 3.10 rozszerza odpowiedzi takiej wtyczki o atrybuty związane z TLSRPT; nie oznacza to jednak ani tego, że każda instalacja wymaga wtyczki, ani tego, że TLSRPT jest wbudowany w każdy pakiet wersji 3.10.

Ponadto TLSRPT nie jest systemem monitorowania w czasie rzeczywistym. Instrukcja Postfixa podaje, że średnio mija około dwunastu godzin, zanim pojawi się komunikat o błędzie, i dlatego wyraźnie odróżnia raporty od monitorowania pilnych awarii. W przypadku bieżących problemów z dostarczaniem nadal konieczne jest sprawdzanie kolejki, analiza logów i powiadamianie o alarmach. TLSRPT pomaga przede wszystkim w wykrywaniu powtarzających się wzorców i problemów związanych z polityką na podstawie wielu prób dostarczenia.

Przygotowanie aktualizacji Postfixa w gałęzi 3.10

Aktualizacja w ramach Postfixa 3.10 to zadanie konserwacyjne o jasnym założeniu: aktualizujesz istniejącą gałąź starszej wersji do stanu poprawek udostępnionego przez twoją dystrybucję. Przed rozpoczęciem czynności zabezpiecz konfigurację Postfixa i zaplanuj okno konserwacyjne. Sprawdź również, czy serwer obsługuje wysyłkę wiadomości wychodzących, ruch MX lub funkcję Submission, ponieważ od tego zależą działania kontrolne i plan awaryjny.

Najpierw sprawdź wersję programu Postfix, która jest zainstalowana lub która została wykryta przez uruchomiony program, i wyraźnie odnotuj ją w main.cf ustalonych parametrów. Pierwsze dwa polecenia służą do przeprowadzenia analizy stanu obecnego. postfix check Jest to natomiast polecenie administracyjne służące do konserwacji: kontroluje ono w szczególności prawa własności i dostępu do plików oraz katalogów i może tworzyć brakujące katalogi. Należy je zatem uruchamiać z odpowiednimi uprawnieniami administracyjnymi, a nie zakładając, że system plików pozostaje niezmieniony.

postconf mail_version
postconf -n
postfix check

Wydanie postconf mail_version określa wersję uruchomionego silnika Postfix. postconf -n wyświetla parametry z jawnymi name=value-wpisów w main.cf. Mogą to być również ustawienia, których wartość odpowiada aktualnemu domyślnemu ustawieniu; wyświetlany wynik nie stanowi zatem pewnego dowodu na faktyczne odstępstwo od wartości domyślnej. Ponadto po zmianie wersji wartości domyślne mogą ulec zmianie, podczas gdy wcześniej ustawiony wpis pozostaje niezmieniony.

Również postfix check nie stanowi pełnej weryfikacji konfiguracji serwera pocztowego. Polecenie to może zgłaszać problemy z uprawnieniami do katalogów lub plików oraz generować brakujące katalogi, jednak nie ocenia kompleksowo merytorycznej poprawności wszystkich parametrów. Łańcuchy certyfikatów, mapy zewnętrzne, zależności DNS, filtry, uwierzytelnianie oraz integracja podłączonych usług muszą zostać sprawdzone oddzielnie.

Do aktualizacji pakietu użyj obsługiwanej metody aktualizacji przez twoją dystrybucję. Sprawdź w metadanych pakietu, dzienniku zmian i informacjach dotyczących bezpieczeństwa, jakie poprawki i ewentualne backporty zawiera dany pakiet. Porównaj te informacje z ogłoszeniami autora pakietu. Nie wnioskuj o braku poprawki wyłącznie na podstawie skróconego ciągu znaków oznaczającego wersję.

Szczególny wymóg aktualizacji procesu, opisany w dokumentacji Postfixa, dotyczy przejścia ze starszej gałęzi rozwojowej na wersję Postfix 3.10.0. Ze względu na zmianę wewnętrznego protokołu agenta dostarczającego wymagane jest wówczas co najmniej postfix reload lub konieczne jest zatrzymanie, po którym następuje ponowne uruchomienie; w przeciwnym razie kurierzy mogą przed nieoczekiwanym smtputf8-Atrybut „ostrzegaj”. Tego uzasadnienia nie można ogólnie odnieść do każdej późniejszej aktualizacji w ramach wersji 3.10.

W przypadku aktualizacji konserwacyjnych w gałęzi 3.10 należy zamiast tego sprawdzić, czy narzędzie pakietowe już przeładowało lub uruchomiło usługę zgodnie z wytycznymi dystrybucji oraz czy uruchomione procesy odpowiadają zaktualizowanemu stanowi. Jeśli tak nie jest, należy skorzystać z funkcji przeładowania lub ponownego uruchomienia przewidzianej przez dystrybucję i pakiet. Następnie sprawdź kolejkę i logi w oknie konserwacji, zamiast zakładać wykonanie konkretnego polecenia aktywacji niezależnie od zachowania pakietu.

Planowanie TLSRPT z wykorzystaniem DNS i infrastruktury raportowej

W przypadku TLSRPT należy oddzielnie zaplanować rolę domeny odbierającej raporty oraz rolę MTA wysyłającego raporty. Domena, która chce otrzymywać raporty o doręczeniach do swojej własnej infrastruktury, publikuje Punkt końcowy rua w DNS i gwarantuje, że ich odbiór, ochrona, przechowywanie i analiza są realizowane w sposób wiążący. Rekord TXT określa zatem, dokąd inne wysyłające serwery MTA powinny kierować swoje zbiorcze raporty.

MTA, który ma samodzielnie generować raporty TLSRPT, wymaga niezależnie od tego pakietu Postfix wraz z biblioteką kliencką TLSRPT oraz USE_TLSRPT została skompilowana. Wskazanie „Postfix 3.10” potwierdza jedynie, od której gałęzi dostępna jest integracja; nie określa ono cech kompilacji konkretnego pakietu binarnego. Dlatego przed zaplanowaniem tej funkcji sprawdź dokumentację pakietu, informacje o kompilacji oraz dostępne pakiety dodatkowe w swojej dystrybucji.

Na każdym uczestniczącym w systemie Postfix uruchamia się lokalny Collector odbiera zdarzenia przekazywane przez zintegrowaną bibliotekę TLSRPT za pośrednictwem lokalnego gniazda domeny Unix. Niezależnie od tego można obsługiwać moduły pobierające, centralną agregację oraz generator raportów: Pobierają one zebrane dane, tworzą przewidziane podsumowania i wysyłają raporty do miejsc docelowych opublikowanych przez domeny odbiorców. Te komponenty końcowe mogą być scentralizowane na innych systemach; nie zastępuje to jednak lokalnego kolektora w danym systemie Postfix.

A Wtyczka polityki jest wymagane dodatkowo tylko w określonych scenariuszach po stronie nadawcy. Jeśli MTA korzysta z informacji dotyczących polityki MTA-STS poprzez smtp_tls_policy_maps, wtyczka wykorzystywana w tym celu musi obsługiwać atrybuty związane z TLSRPT. DANE jest obsługiwane przez sam Postfix. Ani wpis DNS domeny odbiorczej, ani przetwarzanie raportów przez odpowiednio skonfigurowany serwer MTA nie wymagają zatem z góry wtyczki MTA-STS.

Poniższy wpis dotyczy wyłącznie składni DNS dla odbiorcy raportu. example.invalid nie jest celowo domeną produktywną i nie wolno jej przejmować bez zmian. Tag v=TLSRPTv1 charakteryzuje tę procedurę; rua określa tutaj miejsce docelowe dla raportów. RFC 8460 dopuszcza, oprócz poczty elektronicznej, również punkty końcowe HTTPS.

_smtp._tls.example.invalid. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

W przypadku raportów TLSRPT program Postfix 3.10 definiuje nagłówek TLS-Required: no, aby podczas przesyłania raport mógł zostać obniżony do poziomu bezpieczeństwa TLS „may“. Ten ściśle ograniczony wyjątek zapobiega sytuacji, w której zgłoszenie błędu nie zostanie dostarczone nawet przy rygorystycznych wymaganiach TLS. Nie stanowi to jednak zalecenia, aby obniżyć wymagania TLS w przypadku zwykłej korespondencji biznesowej lub wiadomości e-mail użytkowników.

Ochrona przesyłanych danych, szczegółowa ocena opcji TLS

Ustawienie smtpd_hide_client_session dotyczy uwierzytelnionego przesyłania wiadomości przez klienta pocztowego. Jeśli opcja ta jest włączona, serwer SMTP generuje nagłówek „Received:” bez informacji pochodzących z sesji klienta. W zależności od sesji można w ten sposób ukryć w nagłówku np. nazwę hosta i adres IP klienta, dane sesji TLS, informacje logowania SASL oraz szczegóły protokołu SMTP.

Uporządkuj je Funkcja ochrony danych do dedykowanej definicji usługi przesyłania danych dla portu 587 lub 465, zamiast definiować je globalnie w main.cf aby go aktywować. Publiczny serwer MTA na porcie 25 pełni inną rolę w transmisji między serwerami. Dokumentacja Postfixa wymaga w tym przypadku zastosowania wartości domyślnej, aby zachować zgodność z wymaganiami RFC 5321.

Decyzja ta dotyczy zatem nie tylko prywatności, ale także prześledzalności i granic usług. W przypadku uwierzytelnionych klientów ograniczenie zbędnych metadanych może być uzasadnione. Jednak w przypadku publicznego serwera MX takie samo ustawienie naruszałoby udokumentowane oczekiwania dotyczące informacji zawartych w polu „Received:”. Dlatego zamiast stosować jednolitą regułę globalną, należy rozważyć oddzielne usługi, moduły nasłuchujące i ich odpowiednie parametry.

Postfix 3.10.0 zawiera również dostosowanie do OpenSSL 3.5 i jego składni grupowej dla kryptografii postkwantowej. Jeśli wybór grup ma zostać w pełni przekazany do centralnie zarządzanej konfiguracji OpenSSL, należy tls_eecdh_auto_curves oraz tls_ffdhe_auto_groups oba pola muszą być puste. Dopiero takie wspólne ustawienie pozwala OpenSSL na dokonanie wyboru; Postfix sam nie obsługuje nowej składni OpenSSL.

Wyzerowanie obu parametrów automatycznych to Przypadek szczególny dla centralnie zarządzanych ustawień kryptograficznych, nie jest to ogólna rekomendacja dotycząca wzmocnienia bezpieczeństwa. Rozwiązanie to jest odpowiednie tylko wtedy, gdy aktualna konfiguracja OpenSSL jest znana, opatrzona numerem wersji i przetestowana. W przypadku braku takiej kontroli przeniesienie wyboru może ukryć błędne konfiguracje lub spowodować nieoczekiwane zachowanie protokołu TLS; w takim przypadku jawni ustawienia Postfixa pozostają bardziej przejrzyste.

Sprawdzić aktualizacje i znane problemy

Sama informacja o wersji 3.10 nie określa jednolitego stanu technicznego. Decydujące znaczenie mają konkretna wersja poprawki, informacje zawarte w dzienniku zmian pakietu dystrybucyjnego oraz, w razie potrzeby, poprawki przeniesione wstecz. Postfix 3.10.14 został ogłoszony 7 września 2026 r. jako wersja starsza wraz z innymi nadal obsługiwanymi gałęziami. Nie oznacza to jednak, że każdy pakiet dla systemu Linux zawiera już ten stan źródłowy.

Konkretnym przykładem jest Postfix 3.10.6: w tej wersji naprawiono problem związany z Wymagany protokół TLS: nie oraz tryb opakowania TLS po stronie klienta. Poprzednia implementacja mogła zakłócać działanie takich połączeń; poprawka traktuje je z poziomem bezpieczeństwa „encrypt“. Użytkownicy korzystający z trybu opakowania SMTPS powinni zatem sprawdzić aktualizacje i faktycznie stosowaną ścieżkę transmisji, zamiast wyciągać wnioski o identycznym zachowaniu na podstawie wersji „3.10”.

W ogłoszeniu z dnia 3 października 2014 r. wymieniono między innymi poprawki i wzmocnienia zabezpieczeń dotyczące scenariusza „SMTP-Smuggling” z wykorzystaniem smtpd_proxy_filter. Nie oznacza to jednak, że problem dotyczy wszystkich serwerów pocztowych: parametr ten jest domyślnie wyłączony, a jego znaczenie zależy od lokalnej konfiguracji oraz architektury filtrów umieszczonych przed serwerem lub z nim połączonych. Dlatego należy najpierw sprawdzić, czy funkcja ta jest w ogóle aktywnie wykorzystywana.

W przypadku nietypowego dostarczenia danych warto postępować zgodnie z określoną kolejnością podczas wyszukiwania błędów: najpierw sprawdź rzeczywiste odchylenia i poprawność konfiguracji, a następnie czy po aktualizacji nastąpiło ponowne załadowanie. Następnie należy sprawdzić kolejkę i logi pod kątem powtarzających się komunikatów dotyczących protokołu TLS, połączeń lub komunikatów typu „Deferred”. Systematyczny przewodnik po Analiza logów Postfixa pomaga w przyporządkowaniu poszczególnych zdarzeń do identyfikatora kolejki oraz do próby ich dostarczenia.

Ostrzeżenie: Zmiana wersji nie zastępuje analizy przyczyn. Ponowne załadowanie nie usuwa ani nieprawidłowych łańcuchów certyfikatów, ani błędów DNS, ani nieodpowiednich reguł routingu. Z drugiej strony brak ponownego załadowania po aktualizacji może maskować zmiany w procesach lub konfiguracjach zachodzące podczas pracy systemu. Należy zatem wspólnie dokumentować stan aktualizacji, źródło pakietu, moment aktywacji oraz zaobserwowane komunikaty w logach.

Jak prawidłowo oceniać raporty TLSRPT w praktyce

Raporty TLSRPT są opóźnione i nie zastępują monitorowania w czasie rzeczywistym. Dokumentacja Postfixa podaje, że średnio mija około dwunastu godzin, zanim pojawi się raport o błędzie. W przypadku Postfixa rejestrowane wyniki odnoszą się do procedur uzgadniania TLS; brakuje informacji o błędach nawiązywania połączenia oraz przerwach przed lub po uzgodnieniu. W przypadku pilnych zdarzeń nadal konieczne jest monitorowanie kolejki, analiza logów i powiadamianie o alarmach.

Również ponowne wykorzystanie ogranicza liczbę operacji: ponownie wykorzystane połączenie SMTP nie powoduje kolejnego uzgodnienia TLS. W przypadku wznowionych sesji TLS Postfix 3.10 domyślnie pomija rejestrowanie; decydujące znaczenie ma tutaj parametr smtp_tlsrpt_skip_reused_handshakes. Dane zbiorcze w raportach nie stanowią zatem ani pełnej liczby wszystkich połączeń SMTP, ani wskaźnika wiadomości czy wskaźnika dostarczalności. Należy analizować rodzaje błędów, domeny odbiorców, okresy oraz powtarzające się wzorce w połączeniu z logami serwera.

Samo techniczne dostarczenie raportu nie przynosi jeszcze żadnych korzyści. Należy z góry ustalić, kto obsługuje odbiorcę rua, kto odbiera i archiwizuje raporty oraz jak długo dane będą przechowywane. Ponieważ raporty mogą zawierać informacje dotyczące sesji TLS, koncepcja operacyjna powinna uwzględniać uprawnienia dostępu, wytyczne dotyczące ochrony danych oraz procedurę usuwania danych. Należy również ustanowić procedurę eskalacji w przypadku powtarzających się błędów.

Analiza łączy zatem dwa poziomy: TLSRPT przedstawia zagregowane trendy w danym okresie, podczas gdy protokoły serwerów pocztowych dostarczają szczegółowych informacji na temat przebiegu poszczególnych prób dostarczenia wiadomości. W celu bieżącej obserwacji uzupełnieniem jest Praktyczny przewodnik po monitorowaniu logów Postfixa raporty dotyczące metod klasyfikacji komunikatów o błędach i kolejek. Automatyczne alarmy powinny reagować na aktualne dane operacyjne, a nie dopiero na otrzymane agregaty TLSRPT.

Jeśli nie przewidziano wyznaczonego odbiorcy, bezpiecznego miejsca przechowywania ani regularnej analizy danych, publikację TLSRPT należy najpierw zaplanować, a nie uruchamiać pochopnie. Odpowiedzialność za sporządzenie sprawozdania stanowi część funkcji bezpieczeństwa: dopiero przypisanie błędu do właściwego podmiotu umożliwia podjęcie odpowiedniej reakcji, na przykład w przypadku wygaśnięcia polityki MTA-STS lub problemów z danymi TLSA.

3.10 – kontynuować lub przejść do punktu 3.11

Wybór między aktualizowaniem poprawek a zmianą gałęzi zależy od sytuacji wyjściowej i celów operacyjnych. W momencie sporządzania niniejszego opracowania Postfix 3.10 pozostaje nadal obsługiwanym gałęziem starszej wersji, podczas gdy 3.11 jest stabilną gałęzią rozwojową. Dlatego regularne poprawki w ramach wersji 3.10 są wskazane w przypadku istniejących instalacji; nie należy ich jednak utożsamiać z aktualizacją funkcjonalną do wersji 3.11.

Przejście na wersję 3.11 jest uzasadnione przede wszystkim wtedy, gdy potrzebne są jej funkcje lub długoterminowe cele. REQUIRETLS i dane wyjściowe JSON niektórych narzędzi administracyjnych są udokumentowane jako cechy nowszej gałęzi i nie należy ich uwzględniać jako funkcji Postfixa 3.10. Przed zmianą gałęzi należy sprawdzić zgodność parametrów konfiguracyjnych, podłączonych filtrów, uwierzytelniania i automatyzacji.

Aby zapewnić stabilne działanie systemu 3.10 bez konieczności wprowadzania nowych funkcji, należy ciągła aktualizacja poprawek działanie, które jest bezpośrednio odpowiednie. Wymaga ono jednak kontrolowanego przebiegu, obejmującego tworzenie kopii zapasowej, sprawdzanie pakietów, walidację, weryfikację aktywacji procesu oraz monitorowanie. Zmiana gałęzi wymaga natomiast uzasadnienia merytorycznego i zaplanowanego okna serwisowego; sam wyższy numer wersji nie stanowi wystarczającego kryterium decyzyjnego.