Amavis jako before- czy after-queue content filter?

Uwaga. Poniższy artykuł nie jest przeznaczony dla nowicjuszy. Wymagana jest spora wiedza na temat postfixa, amavisa, przepływu informacji między nimi oraz umiejętność eksperymentowania na serwerze w taki sposób, aby go nie spieprzyć.

Amavis to taki soft, który potrafi rozpakować emaila na części składowe a następnie odpalić skaner antyspamowy i antywirusowy na nich. W najpopularniejszej konfiguracji chodzi on jako after-queue content filter czyli:

1) postfix przyjmuje emaila do kolejki
2) postfix przesyła emaila z kolejki do amavisa
3) amavis skanuje emaila
4) amavis przesyła emaila z powrotem do postfixa
5) postfix dostarcza emaila dalej

Jest to konfiguracja najprostsza i najbardziej zalecana (before-queue nie jest zalecane!). Czemu? Bo istotny jest tu czas obróbki emaila przez amavisa. Przeciętny czas obróbki emaila tekstowego to ułamek sekundy nawet na sprzęcie rzędu 2GHz. Czas ten rośnie do kilku sekund w momencie jak email zawiera załączniki. W tej konfiguracji klient (zarówno outlook jak i inny serwer poczty) przekazuje emaila do postfixa i nie musi czekać na wynik skanowania przez amavisa. Trochę inaczej jest w konfiguracji before-queue:

1) postfix przyjmuje połączenie, odpala własne filtry
2) zamiast header_checks i body_checks postfix przekazuje emaila do amavisa i czeka na wynik skanowania
3) wynik skanowania jest przekazywany do klienta
4) amavis przekazuje emaila z powrotem do postfixa
5) postfix dostarcza emaila dalej

Najważniejsze jest to, że klient musi poczekać aż amavis skończy obróbkę emaila. No dobrze - ale jakie to ma znaczenie jak skanowanie trwa nawet 10 sekund? Przecież nikt tego nie zauważy. Problem zaczyna się wraz z wielkością serwera poczty. Pomyślcie co się dzieje jak jednocześnie serwer musi obsłużyć setkę połączeń - to oznacza, że amavis musi odpalić 100 procesów - po jednym na każde połączenie. Procesy te walczą ze sobą o czas procesora i o pamięć. Czyli w naprawdę skrajnym przypadku te 100 emaili musiałby czekać 1000 sekund na koniec obróbki. Co powoduje oczywiście timeouty. Jeżeli amavis działa jako after-queue to postfix cierpliwie podsyła amavisowi kolejne emaile z kolejki. Jeżeli amavis ma ustawione $max_servers = 5 i w master.cf w kolumnie maxproc przy transporcie do amavisa też jest 5 to postfix wie, ile naraz emaili amavis może obrobić i nie przesyła mu więcej aby się biedak nie zagrzał.

No dobrze, skoro after-queue jest takie genialny to po co w ogóle before-queue? istotny jest punkt 3 - "wynik skanowania jest przekazywany do klienta". Ma to znaczenie w przypadku komunikacji serwer-serwer, kiedy amavis odkryje wewnątrz emaila spam lub wirusa. W konfiguracji typu after-queue amavis może mieć tylko 2 możliwe ustawienia zmiennych $final_*_destiny: D_PASS czyli email zostanie dostarczony jakby nigdy nic oraz D_DISCARD czyli email zostanie przesłany do /dev/null. Pozostałe opcje czyli D_REJECT lub D_BOUNCE gdyby zostały użyte uczynią z serwera poczty maszynkę do wysyłania zwrotek na sfałszowane adresy nadawców, a to nie byłoby fajne.

No to teraz pytanie - w jakiej konfiguracji postawić tego amavisa? Najpierw trzeba sobie sprawdzić ile mamy jednoczesnych połączeń w godzinach szczytu:

ps -e|grep smtpd

pokaże chodzące procesy smtpd czyli procesy odpowiedzialne za odbiór emaila od klienta - czyli będzie to ilość jednoczesnych połączeń.
Następnie trzeba zajrzeć do logów amavisa, ważne jest "size" oraz czas podawany na końcu linii logu. Warto sobie wyciągnąć średnią z tych liczb - z całego tygodnia czy nawet miesiąca.
Można by nawet zrobić doświadczenie - zmniejszać $max_servers i maxproc i obserwować w godzinach szczytu czy kolejka postfixa się zatyka/rośnie czy nie.
To wszystko po to aby sobie wyczaić na ile ustawić to $max_servers. Niestety nie ma na to gotowego wzoru.

Ach, gdyby tylko istniał jakiś złoty środek...

No właśnie. Z pomocą mi ostatnio przyszła tepsa, która 1 grudnia 2009 zablokowała port 25 klientom neostrady. Co oznacza, że outlooki komunikują się z moim serwerem na porcie 587 a inne serwery na porcie 25. Co oznacza, że mogę postfixa postawić w dwóch różnych konfiguracjach! Na porcie 25 postawić before-queue a na porcie 587 after-queue!

Co to oznacza: inne serwery będą musiały poczekać na wynik skanowania i w przypadku wykrycia spamu/wirusa dostaną odpowiedni komunikat i zajmą się wygenerowaniem odpowiedniej informacji swojemu użytkownikowi. Natomiast outlooki nie będą musiały czekać, postfix przyjmie emaile do kolejki i przepcha do amavisa w pierwszej wolnej chwili. Dodam jeszcze, że jest tu mowa o serwerze firmowym, gdzie większość emaili jest generowana przez pracowników, co oznacza, że większość emaili będzie kolejkowanych i będą czekały aż amavisowi zrobi się wolne miejsce. Jeżeli amavis wykryje coś nieprawidłowego to zwróci komunikat do postfixa a postfix wygeneruje zwrotkę do (mojego) usera.

No to może bym w końcu zapodał konfigurację?

master.cf:

smtp      inet  n       -       n       -       20       smtpd
  -o smtpd_proxy_filter=127.0.0.1:10024
  -o content_filter=
  -o receive_override_options=no_address_mappings
submission inet n       -       n       -       -       smtpd
  -o smtpd_sasl_auth_enable=yes
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o receive_override_options=no_header_body_checks,no_address_mappings
  -o smtpd_sender_restrictions=reject_unknown_sender_domain,reject_non_fqdn_sender,permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o content_filter=smtp-amavis:[127.0.0.1]:10024
smtp-amavis unix - - n - 5 smtp
   -o smtp_data_done_timeout=1200
   -o disable_dns_lookups=no
   -o smtp_send_xforward_command=yes

amavisd.conf

$max_servers = 30;     # num of pre-forked children (2..30 is common), -m
$final_virus_destiny      = D_REJECT;  # (data not lost, see virus quarantine)
$final_banned_destiny     = D_PASS;   # D_REJECT when front-end MTA
$final_spam_destiny       = D_REJECT;
$final_bad_header_destiny = D_PASS;     # False-positive prone (for spam)

Czyli:
1) odpalam 30 procesów amavisa
2) odpalam maksymalnie 20 procesów smtpd chodzących na porcie 25
3) odpalam dowolną (max 100) ilość procesów smtpd chodzących na porcie 587
4) odpalam max 5 procesów przekazujących emaile z kolejki postfixa do amavisa

Ale 20+5 < 30? Zgadza się. Tu musi być znak mniejszości. Czasami amavis zabija swoje procesy potomne czyli w pewnym momencie nie dysponuje na raz 30 procesami. Czyli ilość procesów potomnych amavisa musi być zawsze większa niż ilość jednoczesnych połączeń, które postfix potrafi do niego otworzyć.

Powyższe wartości (20,5,30) zostały u mnie dobrane na podstawie ruchu w godzinach szczytu oraz dobrane do możliwości sprzętu (szczęśliwi ci, którzy posiadają quadcore lub lepiej)

Komentarze: