Sender Id – wady i zalety

Autor: Konrad Sagała

Opublikowano: 14 listopada 2006

Ciekaw jestem, czy dzisiaj spam na bramce pocztowej do firmy sięgnął 80% ruchu pocztowego, czy tylko 75%? Zaraz sprawdzę. Co prawda dobrze skonfigurowany system pocztowy jest w stanie sobie z tym poradzić w większości przypadków, ale nie zmienia to faktu, że serwer musi wykonać sporo pracy, żeby wszystkie te śmieci odfiltrować. Jak możemy mu w tym pomóc? Dobrych metod można wymienić kilka - od wprowadzenia Service Packa 2 do Exchange 2003 można zastosować większość z nich razem. Jedną z funkcjonalności, jednocześnie budzącą wiele pytań i kontrowersji, wprowadzoną do Exchange 2003 w SP2, jest Sender Id filtering.

Zawartość strony

	Wstęp
	Sender Policy Framework
	Purported Responsible Address
	Sender Id czyli dwa w jednym
	Podsumowanie

Wstęp

Co to takiego? W 2003 roku Meng Wong rozpoczął akcję informacyjną, prezentującą opracowany przez siebie protokół antyspamowy SPF (Sender Policy Framework), który został przyjęty z dużym zainteresowaniem, zwłaszcza przez dostawców usług internetowych, na co dzień borykających się z problemem spamu. Nie chcąc pozostać w tyle, Microsoft opublikował w lutym 2004 roku swój protokół – Caller Id for e-mail, który co prawda wprowadzał pewne ulepszenia (np. XML zamiast czystego tekstu), ale jednak różnił się od protokołu SPF. Żeby nie dublować wysiłków, Meng Wong podjął prace wspólnie z Microsoftem, co zaowocowało przygotowaniem w czerwcu 2004 roku dla IETF draftu specyfikacji nowego protokołu Sender Id, łączącego zalety SPF i Caller Id. Oczywiście, nie czekając na zatwierdzenie nowego standardu (najświeższe dokumenty zostały opublikowane w kwietniu 2006 i mają status experimental – Sender Id jako RFC 4406, SPF jako RFC 4408, PRA jako RFC4407, rozszerzenie SMTP wprowadzające pojęcie Submittera jako RFC 4405), społeczność internetowa rozpoczęła wdrażanie protokołu SPF, co spowodowało, że po zaimplementowaniu Sender Id w SP2 do Exchange’a 2003 nie wszystkie serwery pocztowe prawidłowo z nim współpracują.

Rysunek 1. Idea działania SenderId

Jak to działa? Jak widać na rysunku 1, Sender Id składa się z trzech elementów: opublikowanej w DNS informacji SPF, określenia adresu nadawcy PRA i porównania tych informacji oraz ewentualnego wykorzystania zastępczego nadawcy (submittera). Postaram się pokazać, że to nie takie straszne.

 Do początku strony

Sender Policy Framework

Dokument określający Sender Id – RFC4406 odwołuje się w wielu aspektach do definicji SPF opisanej w RFC4408 oraz metody określenia nadawcy na podstawie nagłówka wiadomości. Czym jest SPF? Rekord SPF jest rekordem DNS typu RR (resource record) określającym jaki host (bądź też grupa hostów) może wysyłać przesyłki pocztowe w imieniu danej domeny. Przykładowy rekord będzie wyglądał następująco:

• v=spf1 +mx a:test.lab.pl/28 -all

Oczywiście jego zapis może wyglądać różnie, w zależności od implementacji DNS i może być zapisany w pliku strefy np. w ten sposób:

• lab.pl. TXT "v=spf1 +mx a:test.lab.pl/28 -all"

Jednakże oprócz dotychczas wykorzystywanego typu TXT rekordu zasobowego (RR), opisanego w RFC1035, dokument RFC4408 wprowadza analogiczny rekord o kodzie 99 i identyfikatorze SPF. Oznacza to, że aby nie trzeba było poprawiać za jakiś czas pliku strefy dobrze jest dodać oba typy rekordów:

• lab.pl. IN TXT "v=spf1 +mx a:test.lab.pl/28 -all"
• lab.pl. IN SPF "v=spf1 +mx a:test.lab.pl/28 -all"

Nie będę cytował wszystkich opcji konfiguracyjnych, bo można je znaleźć w dokumencie RFC, a także w dokumencie przygotowanym przez Meng Wonga „Sender Authentication What To Do". Zresztą do opublikowania rekordów niepotrzebna jest pełna informacja o możliwościach dostępnych do zdefiniowania, ale dobrze jest jednak przeczytać wymieniony powyżej whitepaper. Administrator, czy nawet zwykły użytkownik, może opublikować stosowne informacje poprzez jeden z kilku dostępnych w Internecie „podpowiadaczy” – np. na stronie Microsoftu.

Użyteczne rekordy SPF, o których dobrze jest pamiętać to:

• Domain.com TXT “v=spf1 -all”

  • Wykorzystywane dla domeny, która nie wysyła poczty
  • Zastosowanie dla domen wykupionych i jeszcze nie używanych

• Domain.com TXT “v=spf1 mx -all”

  • Serwery odbierające pocztę (MXy) odpowiadają za jej wysyłkę
  • Used by many ISPs

• Domain.com TXT “v=spf1 ip4:192.0.2.0/24 –all”

  • Określenie wszystkich hostów w danej podsieci IP

 Do początku strony

Purported Responsible Address

Drugim elementem, wykorzystywanym w technologii Sender Id, jest Purported Responsible Address (PRA), czyli najbardziej prawdopodobny nadawca wiadomości. W dokumencie RFC4407 opisany jest algorytm, który pozwala uzyskać z nagłówka wiadomości informację o nadawcy, który jest najprawdopodobniej odpowiedzialny za wysłanie wiadomości. Można powiedzieć, że to przecież oczywiste kto jest nadawcą, ale jak popatrzymy sobie na zawartość nagłówka wiadomości pocztowych, to okazuje się, że może tam występować wiele informacji, mówiących o tym, że wiadomość została przekazana dalej, jest odpowiedzią na naszą wiadomość (niekoniecznie z takim samym adresem, jak ten na który wysyłaliśmy maila), została wysłana w czyimś imieniu przez automat listy dyskusyjnej, czy też wreszcie została wysłana ponownie z wykorzystaniem innego konta pocztowego niż pierwotnie. Dlatego też określenie nadawcy wiadomości pocztowej, która po drodze została poddana takiej „obróbce”, wcale nie jest proste i oczywiste.

Wykorzystując informacje nagłówka wiadomości, zdefiniowane zgodnie z RFC2822, możemy jednak spróbować określić nadawcę nawet najbardziej „zakręconego” maila. Algorytm wskazywania najbardziej prawdopodobnego nadawcy opisuje schemat widoczny na rysunku 2. Kroki 1 i 2 znajdują nagłówki Resent-Sender i Resent-From z pierwszego bloku „resent”, zgodnie z definicją w sekcji 3.6.6. dokumentu RFC2822. Ponieważ jednak nadal pracują serwery pocztowe, które zamiast RFC2822 formatują nagłówki zgodnie ze starszym, mniej precyzyjnym dokumentem RFC822, niestety określenie PRA może nie dać poprawnych wyników, o czym trzeba pamiętać używając tej technologii.

Rysunek 2. Schemat blokowy określania PRA

 Do początku strony

Sender Id czyli dwa w jednym

Znając już prawdopodobnego nadawcę, możemy zweryfikować poprawność przesyłki. Jak jednak odróżnić Sender Policy Framework od Sender Id? To proste - podstawowym wyróżnikiem jest numer wersji. Rekord SPF zgodny z technologią Sender Id będzie wyglądał następująco:

• spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all

Jak widać, w odróżnieniu od zwykłego SPF, record określony jest numerem wersji 2.0 (zamiast spf1 jak to jest opisane w RFC4408) oraz definicją do jakich celów służy rekord – w powyższym przykładzie zarówno do określania MAIL FROM jak i do weryfikacji PRA. Chociaż w tej chwili dokument określa tylko dwa identyfikatory zakresu, którego dotyczy rekord, to jest możliwe dodanie w przyszłości kolejnych obszarów zastosowań, zdefiniowanych w kolejnych dokumentach RFC.

Niezależnie od zastosowań, możemy jednak dla naszej domeny zdefiniować rekordy dla obu wersji specyfikacji, co pomoże nam zachować zgodność z serwerami, które jeszcze nie obsługują Sender Id, a rozumieją SPF. Oczywiście w przypadku zapytania DNS, wysyłanego przez serwer korzystający z technologii Sender Id, najpierw wyszukiwany jest rekord SPF w wersji 2, a dopiero w przypadku jego braku rozpatrywany jest rekord wersji 1. Po wykonaniu zapytania DNS i określeniu PRA generowany jest rezultat weryfikacji nadawcy wiadomości. W zależności od ustawień serwera, wiadomość której nadawca nie został zweryfikowany może zostać odrzucona przez serwer z komunikatem SMTP "550 5.7.1 Sender ID (xxx) yyy - zzz", gdzie xxx jest zastępowane przez oznaczenie MAIL FROM lub PRA w zależności od źródła, yyy jest dodatkowym komunikatem, generowanym przez funkcję sprawdzającą, a zzz jest opisem powodu odrzucenia. Może zostać również przepuszczona z dodatkową informacją dla systemu antyspamowego. Oczywiście, tak jak w przypadku SCL, możemy podejrzeć w Outlooku wyniki działania Sender Id po zaaplikowaniu rozszerzenia zgodnie z opisem w artykule na blogu EHLO.

W przypadku serwera Exchange 2003 SP2 możliwe są 3 akcje:

• zaznacz i prześlij dalej (Stamp and Continue)
• odrzuć (reject) - wysyła NDR do nadawcy
• skasuj (delete).

Poniższa tabela pokazuje relacje tych akcji do rezultatów działania Sender Id:

 Do początku strony

Podsumowanie

Jak widać - nie takie to straszne, jak mogłoby się wydawać. Pomimo różnych opinii i kontrowersji na temat technologii Sender Id uważam, że każdy administrator serwera Exchange powinien skorzystać z jej zalet, a jednocześnie zadbać o opublikowanie odpowiednich informacji o własnym systemie pocztowym, zwłaszcza, że Microsoft niedawno otworzył na zasadach Open Specification Promise specyfikację swojego antyspamowego frameworku Sender Id. Umożliwi to każdemu korzystanie z Sender Id bez licencji, choć należy pamiętać, że już teraz z technologii Sender Id korzysta prawie 40% użytkowników poczty elektronicznej.

Konrad Sagała (MVP) Konrad jest absolwentem Politechniki Warszawskiej wydziału Elektroniki i Technik Informacyjnych. Od 15 lat zajmuje się projektowaniem i wdrażaniem systemów informatycznych opartych o różne platformy sieciowe, od 11 lat związany z platformą Microsoft Windows Server. Do jego specjalności należą: projektowanie i zarządzanie systemami usług pocztowych i pracy grupowej MS Exchange, projektowanie i zarządzanie systemami usług katalogowych MS Active Directory, projektowanie i zarządzanie infrastrukturą sieciową, usługami bezpieczeństwa i zarządzania tożsamością (MIIS). Jest twórcą jednej z największych w Polsce struktur Active Directory i Exchange. Twórca Polskiej Grupy Profesjonalistów i Użytkowników Exchange PEPUG. Posiada certyfikaty MCSE (od 2000 r), MCSE+M, MCSE+S. Uhonorowany tytułem Microsoft MVP w kategorii Exchange Server.

Do początku strony