Praktyka
Minęło ponad pół roku od czasu wprowadzenia standardu DKIM, a mimo to wciąż niewielu administratorów stosuje tę procedurę na swoich serwerach. Dobre planowanie pozwala zintegrować procedurę DKIM z uzbrojonymi po zęby systemami poczty elektronicznej oraz ich filtrami antyspamowymi i antywirusowymi.
Korzyści płynące ze stosowania DKIM w celu filtrowania spamu są tym większe, im więcej domen będzie sygnowało wysyłane przez siebie wiadomości za pomocą odpowiedniego podpisu. Operatorzy poczty, którzy chcieliby wyposażyć swoje serwery w funkcję sygnowania i weryfikowania wiadomości wychodzących i przychodzących zgodnie z dokumentem RFC 4871, powinni się w pierwszej kolejności upewnić, czy ich własny serwer pocztowy nie jest już przypadkiem wykorzystywany do rozsyłania spamu. Uszlachetnienie podpisem elektronicznych śmieci wychodzących z własnej maszyny stanowiłoby poważny uszczerbek dla jej reputacji. Odbiorcy naszych wiadomości nie mogliby korzystać z nadawanej przez nas sygnatury do filtrowania wiadomości, a to sprawi, że podpis stałby się bezwartościowy. Jeżeli serwer jest szczelnie zabezpieczony, powinno się zaplanować, w którym momencie przesyłania e-maila wiadomość powinna być przetwarzana. Tylko w ten sposób DKIM nie spowoduje, że raz ustalony proces przesyłu danych nie zostanie wywrócony do góry nogami, a jednocześnie istniejące procesy nie zakłócą działania DKIM.
Dopiero po zakończeniu etapu planowania operator poczty generuje odpowiednie klucze, a następnie włącza je w ruch SMTP oraz dokonuje wpisów DNS. Dzięki temu system nie tylko będzie mógł nadawać sygnatury DKIN, ale także je rozpoznawać. Na koniec, by móc korzystać z informacji zawartych w takich sygnaturach w celu wychwytywania spamu oraz ataków typu phishing, trzeba odpowiednio dostosować ustawienia swojego filtra treści.
Proszę podpisać w tym miejscu
DKIM może zostać włączony do systemu pocztowego w różnych punktach
Typowy system pocztowy składa się z większej liczby elementów odpowiedzialnych za poszczególne etapy przesyłania e-maili. Serwer SMTP – w naszym artykule rolę tę będzie odgrywał Postfix – ma za zadanie przyjmowanie wiadomości przychodzących z Internetu. Oprogramowanie list mailingowych, w rodzaju programu mailman, przesyła e-maile według rozdzielnika abonentów, a moduł nadzorujący (Content Inspection Engine, tutaj: amavisd-new) zarządza weryfikacją wiadomości za pomocą filtrów takich jak SpamAssassin, oddzielając w ten sposób ziarno od plew.
Zasadniczo serwer przyjmujący może sprawdzić zgodność sygnatury z nadawcą już w trakcie sesji SMTP, jeszcze przed przyjęciem e-maila (pozycja 1 w górnej części przedstawionego schematu). Inny wariant przewiduje przeprowadzenie weryfikacji dopiero podczas filtrowania treści wiadomości (Content Filter), czyli w momencie, gdy e-mail jest już w systemie (pozycja 2). W pierwszym przypadku serwer wysyłający dostarcza przesyłkę do serwera pracującego w trybie DKIM i w ramach sesji SMTP czeka na potwierdzenie ze strony odbiorcy. Serwer przyjmujący przed udzieleniem odpowiedzi sprawdza podpis, a w przypadku niepowodzenia weryfikacji natychmiast przesyła komunikat o wystąpieniu błędu. Na rzecz takiego rozwiązania przemawia fakt, że dzięki temu serwer wie natychmiast, z czym mamy do czynienia i może poinformować o tym nadawcę. W innym wypadku odpowiedzialność za dalszy transport spoczywać będzie na serwerze poczty odbiorcy, a nadawca będzie mógł usunąć wiadomość z kolejki wiadomości oczekujących na przesłanie.
Argumentem przeciw takiemu działaniu jest to, że w praktyce rzadko udaje się wdrożyć solidny mechanizm takiej uprzedniej weryfikacji, ponieważ zanim obciążony pracą serwer zdecyduje się, czy chce przyjąć daną wiadomość, to druga strona procesu już dawno zdąży przerwać sesję SMTP. Nic dziwnego: po pierwsze strona weryfikująca musi przecież za pośrednictwem DNS pobrać odpowiedni klucz publiczny z odległych czeluści Internetu; po drugie obliczenia związane z odszyfrowaniem funkcji skrótu także zabierają CPU nieco czasu. W zależności od obciążenia po stronie serwera przyjmującego może to trwać tak długo, że czas przewidziany na przesyłkę (timeout) dobiegnie końca i strona wysyłająca przerwie posiedzenie. Z reguły nadawca ponownie spróbuje przesłać daną wiadomość, ale także wtedy weryfikacja może trwać zbyt długo, w związku z czym wiadomość zostanie zwrócona wysyłającemu.
Przede wszystkim jeżeli nie ma pewności co do tego, jakie są zasoby systemu oraz wytrzymałość na obciążenie własnego serwera poczty, to lepiej będzie dokonać późniejszej weryfikacji sygnatury (ex post). W tym celu serwer akceptuje wstępnie danego e-maila. Jest on weryfikowany przez łańcuch filtrów dopiero w momencie gdy zamknięte zostaną wszystkie procesy związane z bieżącą obsługą serwerów wysyłających. Tak czy inaczej wiadomość raz przyjęta przez serwer musi zostać przez niego przetworzona.
- Podziel się
