Krótka historia pewnej konfiguracji.

Pewnego pięknego dnia (a może był pochmurny) postanowiłem, że skończę całkowicie zabawę w kotka i myszkę z głupio-mądrymi administratorami serwerów, którzy nie mają świadomości tego, że czasem warto zerknąć do dokumentów RFC.

Sprawa była prosta - wymagać (zgodnie z dokumentem RFC 2821), aby serwer rozpoczynający rozmowę z naszym MX'em wpisał poprawne HELO/EHLO, czyli rozwiązywalny w DNS fqdn. W postfix'ie bardzo przyjemnie i elegancko można zadecydować jakie restrykcje, i w którym momencie dialogu SMTP, będziemy stosowali. Do tego konkretnego przypadku nadają się następujące dyrektywy:

• reject_invalid_helo_hostname - (odzrzuca nieprawidłowo sformułowany hostname)
• reject_non_fqdn_helo_hostname - (odrzuca hostname nie stanowiący fqdn)
• reject_unknown_helo_hostname - (odrzuca hostname, który nie posiada rekordu A lub MX w DNS)

Uwaga:
Dla wersji Postfix'a < 2.3 dyrektywy nie posiadają członu "helo", czyli reject_invalid_helo_hostname => reject_invalid_hostname.

W zależności od tego jak bardzo chcemy, żeby nasz serwer był rfc-compliant, to włączamy odpowiednie regułki. W praktyce trzeba mieć się na baczności, bo duża część serwerów dużych firm (nawet banków) niestety ma serwery przedstawiające się czymś zupełnie niedorzecznym. Gdy mocno zależy nam na dostarczaniu poczty, a mniej na stosunku ham/spam, to lepiej nie stosować powyższych regułek, ew. ustawić reject_code na 4xx i często analizować logi, wpisując do jakiejś whitelisty, wszystkie legalne, rfc-ignorant serwery. W wersjii minimalnej, spokojnie można pozostawić reject_invalid_helo_hostname, to spowoduje, że część robaków/wirusów, nie dotrze do naszego skanera, a zostanie odrzucone już przy HELO/EHLO. Jeśli mamy zamiar analizować logi w celu ustalenia, kto i do kogo chciał wysłać wiadomość, a został odrzucony na poziomie HELO/EHLO, ważne jest, żeby dyrektywy te umieścic w sekcji smtpd_recipient_restrictions, a nie w smtpd_helo_restrictions, ponieważ w tym drugim przypadku, odrzucimy hosta nie pozwalając mu podać adresów nadawcy i odbiorcy. Utrudni to nam tylko weryfikację serwera, ale przy dużym obciążeniu serwera, możemy w ten sposób pozbyć się mailbomberów i innych tego typu ataków.

Jako dodatkowe upiększenie naszej konfiguracji, warto dodać regułki sprawdzające, czy w HELO/EHLO nie dostajemy (dla zmyłki) np. localhost.localdomain albo naszej fqdn. Byłoby to bynajmniej nie eleganckie, żebyśmy się dali oszukać i wpuścili przesyłkę z takim nagłówkiem. Aby osiągnąć ten cel używamy do tego dyrektywy check_helo_access najlepiej w sekcji smtpd_recipient_restrictions (znów cenne logi do czytania wieczorami się nam zapełnią), dyrektywę tą warto umieścić powyżej tych sprawdzających poprawność składni HELO/EHLO, aby oszczędzić trochę mocy przetwarzania.