Jakiś czas temu zaktualizowałem Pleska na swoim serwerze (no dobra, admin mi zaktualizował) do wersji 9.2. Pośród nowości najbardziej spodobała mi się nowa opcja w ustawieniach ochrony antyspamowej: greylisting. Spam mailowy przestał istnieć w 99,99% a SpamAssassin w zasadzie nie ma nic do roboty. Co to jest greylisting? Podaję za Wikipedią:

Greylisting (lub graylisting) to metoda ochrony kont poczty elektronicznej przed spamem. Serwer poczty, który używa metody greylistingu, odrzuca maile od nierozpoznanych nadawców przy pierwszej próbie ich dostarczenia. Ponieważ odrzucenie maila realizowane jest poprzez zwrócenie serwerowi nadawcy kodu błędu oznaczającego tymczasowe problemy z odebraniem maila, to jeśli taka wiadomość została przesłana ze stałego serwera poczty, to zgodnie ze specyfikacją protokołu pocztowego, serwer ten po pewnym czasie (zależnym od ustawień serwera nadawcy) ponowi próbę wysłania wiadomość, która tym razem zostanie przyjęta przez serwer odbiorcy. Jeśli poczta pochodzi z serwera rozsyłającego spam, na ogół nie jest wysyłana ponownie. Na ogół takie serwery działają tymczasowo w celu uniemożliwienia ich identyfikacji i umieszczeniu w DNSBL.

Geneza nazwy

Słowo greylisting informuje, że mechanizm jest czymś pośrednim między whitelisting i blacklisting, oznaczającymi odpowiednio używanie białej i czarnej listy. Nadawcy znajdujący się na białej liście są automatycznie akceptowani, natomiast na czarnej – odrzucani. Greylisting jest czymś pośrednim – najpierw odrzuca nadawcę, a potem go akceptuje.

Jak to działa

Protokół SMTP przewiduje dwa rodzaje błędów: tymczasowe i permanentne. Tymczasowy błąd jest sygnalizowany, kiedy serwer chwilowo nie może przyjąć przesyłki (bo np. chwilowo zabrakło miejsca na dysku serwera albo inny program blokuje skrzynkę odbiorcy), ale możliwe że przyjmie ją później. Błąd permanentny oznacza, że przesyłka nie może zostać przyjęta ani teraz ani później (bo np. odbiorca nie istnieje). Jeżeli błąd jest tymczasowy, to serwer, który próbuje dostarczyć wiadomość, będzie co jakiś czas próbował dostarczyć ją ponownie. Greylisting polega na tymczasowym odrzucaniu wiadomości od nieznanych nadawców. Jeżeli nadawca po ustalonym czasie ponowi próbę wysłania przesyłki, to trójka (najczęściej) składająca się z nadawcy, odbiory i adresu IP wysyłającego serwera zostanie na ustalony czas dopisana do listy zaufanych trójek. Kolejna próba dostarczenia przesyłki pasująca do zapisanej trójki powiedzie się bez sygnalizowania tymczasowego błędu.

Greylisting działa dlatego, że serwery spamerów najczęściej nie zapisują nigdzie informacji, że dany serwer tymczasowo odmówił przyjęcia przesyłki. Traktują taką odmowę jak permanentną.

Kolejność dostarczania wiadomości

Ponieważ graylisting nie działa w oparciu o np. identyfikator wiadomości, zatem dość często zdarza się, iż odbiorca otrzymuje od graylistowanego nadawcy wiadomości w innej kolejności niż ten je wysłał. Dzieje się tak dla tego, iż pierwsza z wiadomości zostaje tymczasowo odrzucona i umieszczona przez serwer nadawcy w kolejce do powtórnej wysyłki, zaś kolejna nadchodząca od nadawcy wiadomość jest przez serwer odbiorcy traktowana już jako kolejna próba nadawcy i przyjmowana od razu. Po jakimś czasie (zależnym od ustawień serwera nadawcy) pierwsza wiadomość jest wysyłana powtórnie i również jest już przyjmowana bez opóźnień. Jest to normalne zjawisko w przypadku serwerów które stosują graylisting.

Od jakiegoś czasu wśród moich serwerów pojawił się jeden działający w oparciu Plesk postawiony na Debianie. Generalnie jestem zadowolony z tego rozwiązania, ale oczywiście od czasu do czasu napotykam na różne kwiatki (choć rzadko). Jednym z takich kwiatków okazał się PEAR (choć to nie jego wina, tylko Pleska).

W czym rzecz? Ano w tym, że niby mam PEAR, ale nie działa. Tzn. można instalować pakiety, ale za diabła żaden skrypt PHP nie może uzyskać dostępu do plików PEAR. Próba uruchomienia poniższego skryptu

<?php
require ("PEAR.php");
?>

kończy się tak:

Zacząłem więc po kolei sprawdzać w czym rzecz. Najpierw odpaliłem phpinfo().

include_path
PEAR znajduje się w include_path, czyli w /usr/share/php, więc powinno chodzić. No ale nie chodzi.

open_basedir
No to jesteśmy (prawie) w domu. Nadrzędna wartość open_basedir jest OK – zawiera /usr/share/php, ale LOKALNA już nie – i dlatego nie działa.

Rozwiązanie

Trzeba przygotować sobie plik vhost.conf o zawartości analogicznej do poniższej i wgrać go do katalogu /var/www/vhosts/domena.com/conf/. Jest to jedyne rozwiązanie żeby na trwałe zmienić konfigurację dla wybranego vhosta (bo musimy zmienić LOKALNĄ wartość). Broń Boże wprowadzać zmainy w pliku httpd.include!

<Directory /var/www/vhosts/domena.com/httpdocs>
php_admin_flag safe_mode off
php_admin_value open_basedir "/var/www/vhosts/domena.com/httpdocs:/tmp:/usr/share/php"
</Directory>

Na koniec trzeba powiadomić Pleska o tym, że zmieniła się konfiguracja serwera. Robimy to takim poleceniem:

/usr/local/psa/admin/bin/websrvmng -a

Podobno nie trzeba po tym nawet Apache’a restartować, ale bez tego mi nie działało. Dlatego dorzucamy jeszcze to:

/etc/init.d/apache2 restart

I teraz wszystko pięknie hula!