Postfix - optymalizacja wysyłki

Sun 07 August 2011 by admin

Postfix często wybierany jest jako serwer pocztowy, jednym z argumentów na jego korzyść jest wydajność. Optymalnie zrealizowana kolejka active predestynuję go do wyboru w roli smarthost'a. W jaki jeszcze inny sposób możemy wpłynać na wydajność naszej konfiguracji ?

Przede wszystkim przy wysyłce dużej ilości poczty np. maillingu reklamowego możemy zrezygnować z content filter'a np. popularnego amavisd dla poczty wysyłanej z zaufanych źródeł. W tym celu  należy w pliku master.cf stworzyć kolejna instancję smtpd nasłuchujaca na innym adresie IP lub innym porcie niż ten użyty do ,,normalnej'' komunikacji. Tym sposobem pozbywamy się waskiego gardła w postaci czasochłonnego skanowania  poczty, która de facto została wygenerowana przez nas.

Kolejne waskie gardło to kolejka maildrop, do której wiadomości moga trafiać (sendmail) nawet gdy serwer postfix jest niedostępny. Usługa pickup pobiera te wiadomości i przekazuje do głównych kolejek, niestety jest ona jednowatkowa zatem może pobierać tylko jedna wiadomość naraz i ograniczona jest dodatkowo podsystem I/O. W tym celu korzystniej jest użyć protokołu smtp do dostarczenia wiadomości do serwera pocztowego, dla aplikacji napisanych w języku PHP zamiast standardowego sendmail'a możemy użyć np. mini-sendmail'a wprowadzajac zmianę w pliku php.ini.

Wysłanie poczty do konkretnego nadawcy wiaże się z rozwiazaniem nazwy DNS dla rekordów A i MX, dlatego istotny jest wybór serwera DNS. Najlepiej gdy serwer DNS znajduję się w sieci lokalnej i jest serwerem buforujacym zapytania. Czas odpowiedzi na rozwiazanie adresu możemy mierzyć korzystajac np. z narzędzia dig.

Specyfika wysyłki dużej ilości poczty w relatywnie krótkim czasie wymaga podejmowania szybkich decyzji i tak parametry smtp_connect_timeout i smtp_helo_timeout decyduja o tym jak długo będziemy oczekiwali na odpowiedź samego serwera i odpowiedź po wysłaniu prezentacji HELO, EHLO. Niższe wartości to krótsze czasy poświęcone na wysyłkę konkretnej wiadomości, ale też większe ryzyko szybszego odrzucenia naszej wiadomości przez ,,wolne'' serwery.

Jeżeli wysyłamy duża ilość poczty do jednego dostawcy możemy pokusić się o zmianę parametru initial_destination_concurrency, default_destination_concurrency_limit , zwiększy to limit równoczesnych prób dostarczenia poczty przy pierwszych próbach wysyłki i po automatycznym dostosowaniu się. Globalnie zaś możemy zwiększyć liczbę procesów default_process_limit obsługujacych dany transport chociażby ten wcześniej przez nas zdefiniowany dla wyłaczonego content-filter'a.

Jednak jak wiemy nie za pierwszym razem udaje się dostarczyć pocztę do odbiorcy, gdy taka sytuacja ma miejsce wówczas poczta trafia do kolejki deferred. Częstotliwości zagladania do niej definiujemy parametrami queue_run_delay, minimal_backoff_time, maximal_backoff_time odpowiednio czas zagladania do kolejki, minimalny i maksymalny czas życia wiadomości w kolejce deferred. Jeżeli mamy kilka serwerów pocztowych warto jeden z nich oddelegować do obsługi wiadomości typu deferred na zasadzie główny serwer wysyła tylko nowe wiadomości, w przypadku odrzucenia wiadomości przekazuje ja do serwera pomocniczego, który będzie się troszczył o ich wysyłkę. Parametrem za to odpowiedzialnym jest fallback_relay. Za nim jednak oddelegujemy wiadomości na taki serwer sprawdźmy jak kształtuje się kolejka deferred poleceniem: qshape deferred

Wiadomości lepiej jest wysyłać, gdy zawieraja dłuższa listę odbiorców, wówczas zamiast kilku wiadomości ograniczmy się tylko do jednej. Maksymalna liczba odbiorców per wiadomość definiowana jest parametrem default_destination_recipient_limit.

Niektóre serwery naszych odbiorców nie akceptuja zbyt wyśrubowanych parametrów, ograniczajac liczbę wysyłanych wiadomości w jednostce czasu. W przypadku takich serwerów należy wprowadzić tym razem ograniczenia w dół i tak w  parametrze default_destination_rate_delay definiujemy odstęp czasu pomiędzy kolejnymi próbami wysyłki do konkretnej domeny lub konkretnego odbiorcy. Parametr ten możemy zdefiniować w konkretnym postfixowym transport'cie dla wybranych przez nas odbiorców, zamiast wprowadzania go globalnie. Podobnie możemy zawrzeć w takim transporcie parametry opisane wcześniej a odpowiedzialne np. za liczbę jednoczesnych prób dostarczenia wiadomości.

Dodatkowo przy dużym natłoku przychodzacych wiadomości badź to z naszych serwerów badź z serwerów klientów, dla których świadczymy usługi mailling'u możemy ograniczać liczbę przyjmowanych wiadomości parametrem in_flow_delay.  Definiujemy w nim odstęp czasu pomiędzy kolejnymi próbami odebrania wiadomości.

Prócz wymienionych parametrów dopasowanych odpowiednio do skali przedsięwzięcia zwiazanego z wysyłka poczty, możemy dodać obsługę SPF oraz DKIM dla domen, z których wysyłamy pocztę sprawi to, że będziemy bardziej wiarygodni jako nadawcy i nasza kolejka pocztowa szybciej może być opróżniana.

Dodatkowo tym razem dla uzyskania większej przejrzystości logów serwera, możemy dla wybranego transportu zdefiniować parametrem syslog_name nazwę, która wyróżni nasz maillingu spośród innej ,,normalnej'' poczty.


Comments