Uwierzytelnianie nadawcy bezpieczeństwo czy zagrożenie

Uwierzytelnianie nadawcy bezpieczeństwo czy zagrożenie Tomasz Nidecki Artykuł opublikowany w numerze 2/2006 magazynu hakin9. Zapraszamy do lektury całego magazynu. Wszystkie prawa zastrzeżone. Bezpłatne kopiowanie i rozpowszechnianie artykułu dozwolone pod warunkiem zachowania jego obecnej formy i treści. Magazyn hakin9, Software-Wydawnictwo, ul. Piaskowa 3, 01-067 Warszawa, pl@hakin9.org

Okolice Uwierzytelnianie nadawcy bezpieczeństwo czy zagrożenie Tomasz Nidecki stopień trudności Spam, phishing i inne oszustwa e-mailowe stają się coraz bardziej uciążliwe i niebezpieczne. Dlatego coraz więcej mówi się o różnych metodach uwierzytelniania nadawcy w poczcie elektronicznej. Niestety, większość z nich zamiast pomóc, wprowadza tylko nowe zagrożenia. Protokół SMTP i infrastruktura poczty elektronicznej są całkiem nieprzystosowane do dzisiejszych brutalnych realiów. Wszelkie rozwiązania w zakresie zabezpieczeń e-maila to tylko niezbyt eleganckie łaty. Jedynym sposobem na skuteczne zwalczenie spamu, phishingu czy joe-jobs (wysyłanie e-maili z tak sfałszowanym adresem nadawcy, by spam obciążał niewinną osobę) jest stworzenie zupełnie nowej infrastruktury poczty elektronicznej. Dotychczasowe próby wprowadzanie większych zmian w infrastrukturze Internetu kończyły się jednak spektakularnym fiaskiem. Nie dość, że trudno było ustalić, które rozwiązanie zastosować, to nawet jeśli się to udawało, przekonanie wszystkich do jego użycia okazywało się prawie niemożliwe. Dobrym przykładem jest DNSSEC mimo iż wszyscy wiedzą, że klasyczny protokół DNS jest dziurawy i czym prędzej trzeba się go pozbyć, jak dotąd nie udało się wprowadzić bezpieczniejszej alternatywy. Nic więc dziwnego, że również i w kwestii protokołu SMTP pojawiają się coraz to nowsze koncepcje mające zapewnić uwierzytelnienie nadawcy i przez to zwiększające bezpieczeństwo poczty. Jednak firmy i instytucje podejmujące takie wysiłki zachowują się co najmniej niepoważnie. Spieszą się, bo nadużyć przybywa; starają się wykorzystać jak najwięcej istniejących mechanizmów, by migracja była łatwiejsza; nie myślą jednak o konsekwencjach wprowadzania niesprawdzonych i nieprzemyślanych rozwiązań. SPF wady i zalety Metodą uwierzytelniania nadawcy, która jak dotąd zyskała największą popularność, jest SPF. Stosuje ją do ochrony wiele popularnych serwerów pocztowych (w Polsce między innymi Interia, Gazeta). Pierwotne znaczenie skrótu Z artykułu dowiesz się... jakie strategie uwierzytelniania nadawcy zostały wdrożone i opracowane, dlaczego uwierzytelnianie nadawcy nie powinno być stosowane do czasu znalezienia skutecznej i bezpiecznej metody. Powinieneś wiedzieć... powinieneś znać podstawy protokołu SMTP i poczty elektronicznej. 2 hakin9 Nr 2/2006 www.hakin9.org

Uwierzytelnianie nadawcy za i przeciw Dlaczego SPF jest zły SPF ma uniemożliwić fałszowanie adresy nadawcy. Chroni jednak tylko adres kopertowy, nie zaś adres z nagłówka From:. Z kolei programy pocztowe takie, jak Outlook Express wyświetlają tylko ten drugi, niechroniony adres, a adres kopertowy można zobaczyć jedynie przeglądając źródło wiadomości. Tak więc SPF jest całkowicie nieskuteczny mimo jego stosowania użytkownicy będą oszukiwani. SPF miał z założenia chronić przed spamem. Badanie firmy CipherTrust z 2004 roku wykazało, że już w tym czasie, kiedy SPF nie był jeszcze zbyt popularny, więcej spamu wychodziło z domen z rekordami SPF, przez uwierzytelnione serwery, niż z domen bez takich wpisów lub z serwerów nieuwierzytelnionych. Spamerzy po prostu sami zaczęli stosować SPF, aby zagwarantować dostarczenie poczty. Używają go nawet częściej, niż przeciętni użytkownicy. SPF jest niezgodny z wieloma standardami internetowymi. Uniemożliwia przekierowanie poczty przed doręczeniem (pre-delivery forwarding). Istnieje co prawda metoda SRS, która została wymyślona w celu zapobieżenia temu problemowi, ale ta metoda jest jeszcze bardziej niedoskonała, niż sam SPF. Dodatkowo SPF opiera się na dziurawym protokole DNS, co znacznie ułatwia oszustom fałszowanie rekordów. Podsumowując: SPF nie chroni przed podszywaniem się, nie chroni przed spamem. Utrudnia komunikację i narusza standardy. Po co więc go używać? SPF to Sender Permitted From, ale wraz ze wzrostem popularności projektu przemianowano go na Sender Policy Framework. SPF umożliwia określenie, czy host próbujący przesłać e-mail z danym adresem kopertowym (nadawcy) ma uprawnienia do wykorzystywania w tym adresie danej nazwy domeny. Spamerzy od lat stosują fałszowanie adresów nadawców, podszywając się pod istniejące lub nieistniejące konta najczęściej w dużych serwisach pocztowych jak Yahoo! czy Hotmail. Takie podszywanie się jest banalnie SPF ryzyko dla dostawców Internetu proste, ze względu na budowę protokołu SMTP. Jedyne, co spamer musi zrobić, to użyć dowolnego (poprawnego syntaktycznie) adresu nadawcy, a poczta zostanie przyjęta przez serwer odbiorcy. SPF wykorzystuje istniejącą infrastrukturę DNS. Informacje o tym, które serwery są uprawnione do wykorzystania danej domeny w adresie nadawcy, przechowywane są w adresach TXT tej domeny (w DNS-ie). Można założyć, że użytkownik konta Hotmail będzie wysyłać pocztę przez serwer SMTP Hotmaila, a nie przez Jeśli na naszym serwerze pocztowym zastosujemy ochronę SPF, do naszych klientów nie dojdzie żaden list z konta wykorzystującego przekierowanie przed doręczeniem (chyba, że serwer przekierowujący stosuje niedopracowany, niezgodny ze standardami i trudny do zaimplementowania SRS). Administratorzy serwerów przekierowujących mogą się zezłościć i całkowicie zablokować połączenia z naszym serwerem. Nasi użytkownicy będą wściekli i wybiorą innego dostawcę kont pocztowych, ponieważ znajomi nie będą mogli się z nimi skontaktować. Jeśli nasz serwer nie będzie odbierał poczty z domen bez rekordów SPF, większość listów zostanie przez nasz serwer odrzucona. Administratorzy serwerów pocztowych tych domen mogą się jeszcze bardziej zezłościć i całkowicie zablokować połączenia z naszym serwerem. Nasi klienci będą naprawdę wściekli, że połowa poczty nie dochodzi do nich, a więc wybiorą innego dostawcę. Jeśli skorzystamy z ochrony SPF, poinformujemy wszystkich wokół: Jeśli chcesz się ze mną porozumieć, musisz spełnić pewne warunki... To z pewnością nie pomoże w interesach. Zdenerwujemy innych administratorów, rozwścieczymy naszych użytkowników, a nasz serwer nadal nie będzie chroniony ani przed spamem ani przed oszustwami (bo SPF jest nieefektywny). Stosując SPF stracimy wiele, a nic nie zyskamy. serwer Yahoo! (choć w rzeczywistości nic prócz SPF nie stoi na przeszkodzie, by korzystał z tego ostatniego). Strukturę DNS wykorzystano, by ułatwić implementację SPF i nie wprowadzać dodatkowych mechanizmów. Zalety Wydawałoby się, że SPF jest niezłym rozwiązaniem problemu podszywania się pod nadawców. Jeśli dana domena publikuje rekordy SPF, a odbiorca wykorzystuje SPF do uwierzytelnienia nadawcy, to nie otrzyma żadnego e-maila ze sfałszowanym adresem kopertowym z tej domeny. Jeśli więc ebay publikuje rekord SPF dla domeny ebay.com (a faktycznie publikuje), a phisher spróbuje wysłać przynętę do serwera interia.pl chronionego przez SPF, to żaden z użytkowników poczty Interii nie otrzyma phishingowych przynęt z fałszywym adresem kopertowym należącym do ebay.com. Jest jasne, że taki schemat zadziała stuprocentowo skutecznie tylko, jeśli wszystkie domeny na świecie uczestniczące w wymianie poczty elektronicznej będą publikować rekordy SPF oraz jeśli wszystkie serwery pocztowe na świecie będą stosować SPF do weryfikacji nadawcy. Jednak nie wszyscy właściciele czy administratorzy domen i serwerów pocztowych wiedzą, że powinni opublikować rekord SPF lub chronić serwer za pomocą tej metody. Spośród tych co wiedzą jest wielu, którzy świadomie rezygnują z tego rozwiązania, by nie ograniczać użytkowników. Poza tym nie każde oprogramowanie SMTP można przystosować do ochrony poczty za pomocą tego systemu. Istnieje spora liczba rozwiązań do aktualnie stosowanych serwerów, ale w większości przypadków są to łaty, proxy i narzędzia zewnętrzne, a nie elementy wbudowane. Dlatego też wdrożenie SPF to często wiele pracy dla administratora. Wszystko to sprawia, że SPF jest mało skuteczny w eliminowaniu zjawiska podszywania sie pod nadawców poczty. Przy projektowaniu tego rozwiązania poczyniono złe założenia, opierające się na konieczności wykorzystywania systemu przez www.hakin9.org hakin9 Nr 2/2006 3

Okolice wszystkich pragnących uczestniczyć w wymianie poczty. A nie trzeba chyba przypominać, że SPF nie jest nawet standardem internetowym. Wady Praktyka jest jednak daleka od teorii. Okazuje się bowiem, że SPF w ogóle nie chroni użytkowników przed fałszerstwami. Nie chroni też przed phishingiem ani atakami joe-job. Jest całkowicie nieskuteczny. Powód jest prosty programy pocztowe wyświetlają adres nadawcy z nagłówka From:, a nie z adresu kopertowego. Ten drugi można zobaczyć dopiero po wyświetleniu źródła wiadomości (w nagłówku Return-Path:). Oszust może więc podać poprawny adres kopertowy i fałszywy (na przykład klienci@inteligo.pl) adres From:. Serwer poczty chroniony przez SPF będzie musiał taki list zaakceptować, a użytkownik w swoim Outlook Expressie zobaczy fałszywy adres nadawcy. Inną poważną wadą SPF jest fakt, że mimo antyspamowego rodowodu, rozwiązanie to jest całkowicie nieskuteczne w zwalczaniu niechcianej poczty i nie powinno być nigdy nazywane zabezpieczeniem antyspamowym. To metoda walki z podszywaniem, która z założenia ma chronić właściciela domeny przed wykorzystaniem jej w złych intencjach. Może ochronić odbiorcę przed otrzymywaniem listów z fałszywymi adresami kopertowymi, ale z pewnością nie powstrzyma spamerów przed napychania naszych skrzynek łajnem. Aby zrozumieć przyczynę takiego stanu rzeczy, przyjrzyjmy się następującemu przykładowi. Na potrzeby artykułu przyjmijmy bardzo optymistyczne założenie, że 50 procent wszystkich domen uczestniczących w wymianie poczty elektronicznej publikuje dane SPF (choć w rzeczywistości jest to pewnie tylko około 10 procent według raportu firmy CipherTrust z końca 2004 r., tylko 5 procent domen spośród uczestniczących w wymianie poczty publikowało wtedy rekordy SPF), a dodatkowo aż 50 procent serwerów pocztowych jest chronionych za pomocą SPF. Jak spamerzy i oszuści omijają SPF Spamer: znajduje dowolną domenę bez rekordu SPF. Używa jej w kopertowym adresie nadawcy. Ochrona SPF jest bezużyteczna, ponieważ większość chronionych serwerów akceptuje pocztę z domen bez rekordów SPF. Spamer: wysyła pocztę z adresem kopertowym nadawcy <> (zgodnie z RFC musi zostać zaakceptowana). Spamer: kupuje domenę do spamowania za 40 PLN na rok (np. w godaddy.com), korzysta z darmowego serwera DNS (na przykład freedns.sgh.waw.pl), publikuje rekord SPF dla tej domeny, zaczyna spamować. Ochrona SPF jest bezużyteczna. Oszust: znajduje domenę bez rekordu SPF, podaje w kopertowym adresie tę właśnie domenę, umieszcza fałszywy (np. support@citibank.com) adres w nagłówku From:. Każdy użytkownik zobaczy wyłącznie fałszywy adres. Chronione serwery mogą stosować dwie strategie w odniesieniu do poczty pochodzącej z domen niepublikujących rekordów SPF zaakceptować pocztę lub ją odrzucić. Połowa domen (zgodnie z naszymi optymistycznymi założeniami) nie publikuje takich rekordów. Logiczne więc, że serwer odrzucający e-maile z takich domen automatycznie traci połowę przychodzącej poczty. Żaden administrator serwera pocztowego nie może sobie na to pozwolić, a przy tym niedobrze zmuszać innych do publikowania rekordów SPF by mogli się z nami komunikować. Takie podejście niszczy ideę poczty internetowej i czyni SPF monokulturą. Trzeba też pamiętać, że nasze założenia były bardzo optymistyczne. W rzeczywistości odrzucanie poczty z domen niepublikujących rekordów SPF (czyli wg badania CipherTrust około 90%) byłoby samobójstwem dla administratora serwera pocztowego. Równie dobrze mógłby po prostu wyłączyć cały system. Załóżmy więc, że stosowane jest drugie podejście, czyli akceptowanie poczty z domen bez SPF. Z punktu widzenia spamera komunikacja z tak zabezpieczonym serwerem to bułka z masłem. Wystarczy, że znajdzie dowolną domenę bez rekordu SPF i może swobodnie wykorzystać ją w adresie nadawcy. Innym sposobem będzie użycie specjalnego adresu kopertowego <>, który zgodnie z RFC musi zostać zaakceptowany (a w ogóle nie zawiera nazwy domenowej). Spamer może też kupić domenę za 40 PLN rocznie i opublikować rekord SPF w darmowym serwerze DNS, zezwalając jednocześnie wszystkim na wykorzystanie jej do fałszowania adresów nadawcy. Wspomniane już badanie CipherTrust z 2004 roku wykazało, że ponad połowa całej poczty odbieranej przez serwery chronione za pomocą SPF z domen publikujących rekordy SPF to... spam! Poważne problemy Jak widać, choć SPF może odrobinę pomóc w ochronie marki, to jest zupełnie nieskuteczny w ochronie przed spamem. Nieskuteczność sama w sobie nie jest jednak dużym problemem. Takim problemem jest jednak fakt, że SPF bardzo poważnie zaburza działanie poczty, o czym większość administratorów dowie się przeglądając logi zawierające odbicia (bounce) od serwerów chronionych przez SPF. Najpoważniejszym problemem SPF jest fakt, że uniemożliwia stosowanie pre-delivery forwarding czyli przekierowania poczty przed doręczeniem (patrz Rysunek 1). Przekierowania są stosowane od wielu lat i zaimplementowane we wszystkich serwerach poczty (chociażby mechanizm dot-forward). Każdy serwer chroniony za pomocą SPF będzie odrzucał przekierowane listy, chyba że domena użyta w adresie nadawcy publikuje rekord SPF, który zezwala każdemu na jej użycie. Jeśli zaś jakakolwiek domena publikuje taki rekord, może być wykorzystywana przez oszustów i spamerów. Zmniejsza to skuteczność całego systemu i naraża na umieszczenie domeny na czarnych listach. 4 hakin9 Nr 2/2006 www.hakin9.org

Okolice Większość kont pocztowych umożliwia użytkownikom stosowanie przekierowań. To logiczne po co odbierać pocztę z dziesięciu różnych kont, jeśli można wszystkie listy przekierować na jedno. Poza tym wiele firm opiera swoje usługi na kupowaniu atrakcyjnych domen i udostępnianiu użytkownikom darmowych, atrakcyjnych aliasów e-mailowych. To także logiczne, ponieważ zasoby niezbędne do utrzymania darmowych aliasów są wielokrotnie niższe, niż te niezbędne do utrzymania kont pocztowych. Aby przeciwdziałać temu problemowi, zaproponowano kontrowersyjne rozwiązanie zwane SRS (Sender Rewriting Scheme), które jest kiepską łatą na kiepską łatę. Projekt ten sugeruje, aby podczas przekierowywania poczty, serwer przekierowujący nadpisywał adres kopertowy nadawcy tak, aby oryginalne informacje o nadawcy zostały zachowane (i odtworzone przy odbiciu), lecz by część domenowa pochodziła od serwera przekierowującego. Na przykład jeśli serwer poczty znikad.com przekierowuje pocztę od jasio@gdzies.net, to nadpisany według schematu SRS adres nadawcy wyglądałby mniej więcej jak SRS0=sumakontrolna=dataigodzina=gdzies.net=jasio@znikad.com. Po kilku przekierowaniach taki adres stanie się za długi dla standardu SMTP (64 znaki w części lokalnej, zgodnie z RFC 2821) i będzie odrzucany przez wiele serwerów. W dodatku powszechne stosowanie SPF wymagałoby zaimplementowania SRS w każdym serwerze SMTP stosującym przekierowywanie. SPF ma też wiele innych poważnych wad. Wykorzystuje istniejący rekord DNS, który przeznaczono do użycia w zupełnie innych celach. Jest niezgodny z RFC 1123, RFC 974 i RFC 2821. Utrudnia życie podróżującym użytkownikom, ponieważ zostają zmuszeni do korzystania z serwera SMTP dostawcy konta pocztowego i nie mogą korzystać z własnych, lokalnych usług SMTP lub usług innych operatorów. Opiera się na wadliwej usłudze DNS (DNS jest dziurawy jak sito, co udowodniono wielokrotnie), więc rekord SPF również Rysunek 1. Dlaczego SPF uniemożliwia pre-delivery forwarding można sfałszować (chociażby stosując atak DNS poisoning). Stosowanie SPF dyskryminuje osoby nie chcące go wdrożyć, wprowadza ryzyko utraty poczty i grozi monopolem. Co gorsza, administratorzy serwerów pocztowych, w tym tak poważnych firm jak największe polskie portale internetowe, skuszeni przez media implementują SPF zanim przeanalizują gruntownie na co się decydują! Nie używajmy więc SPF. Dopóki nie pojawi się sensowny sposób uwierzytelnienia nadawcy, jesteśmy skazani na niebezpieczny protokół SMTP. Ale wdrażając SPF postąpimy jak lekarz, który amputuje pacjentowi nogę, bo pszczoła użądliła pacjenta w piętę. Przyszłość i alternatywne sposoby Przyszłość nie wygląda różowo. Mimo istnienia wielu interesujących projektów, zmuszono nas by żyć z SPF i całym dobrodziejstwem jego inwentarza. Zmusili nas nie autorzy SPF (którzy są sensownymi ludźmi i są świadomi niedoskonałości ich systemu), lecz Microsoft. Mocno promowany i powoli wdrażany projekt Sender ID jest bowiem oparty na szkielecie SPF. Wszyscy wiemy, jaką władzę dzierży Microsoft dzięki dominującej pozycji na rynku IT. Wszystko, co Microsoft wprowadzi w swoich produktach, niezależnie od tego czy jest to logiczne, odpowiedniej jakości i czy przestrzega standardy, i tak zostanie zaakceptowane przez szarą masę użytkowników, ponieważ zwykle firma z Redmond czyni takie rozwiązania częścią domyślnej konfiguracji Windows. Jeśli więc w następnej wersji Windows w Outlook Express zostaną wbudowane mechanizmy ochrony przez Sender ID, będziemy musieli stosować Sender ID, aby porozumiewać się ze zdecydowaną większością użytkowników Internetu. Obrzydliwe, ale nie byłby to pierwszy przypadek, gdy takie działa- 5 hakin9 Nr 2/2006 www.hakin9.org

Uwierzytelnianie nadawcy za i przeciw O autorze Tomasz Nidecki jest redaktorem prowadzącym magazynu hakin9. Ma bogate doświadczenie w mediach i informatyce, sięgające połowy lat osiemdziesiątych, kiedy to uzbrojony w przedpotopowe Commodore 64 uczestniczył w pierwszych sieciach (BBS, Fidonet) i pisał dema w asemblerze. Jego wykształcenie obejmuje zarówno studia dziennikarskie, jak i informatyczne na Uniwersytecie Warszawskim. Od niemal 15 lat związany z prasą informatyczną i komputerami. Poza redagowaniem i publicystyką zajmuje się także administrowaniem serwerami pocztowymi. Jego zainteresowania informatyczne wiążą się głównie z pocztą elektroniczną (szczególnie ochroną przed spamem). Od około pięciu lat aktywnie działa w różnych polskich organizacjach walczących ze spamerami. Na dwóch ostatnich konferencjach IT Underground prowadził wykłady o ochronie przed spamem. W Sieci http://homepages.tesco.net/~j.deboynepollard/fga/smtp-spf-is-harmful.html więcej informacji o powodach, dla których warto porzucić SPF, http://www.taugh.com./mp/lmap.html dlaczego proponowane metody uwierzytelniania nadawców są szkodliwe, http://bradknowles.typepad.com/considered_harmful/2004/05/spf.html interesujący artykuł o wadach SPF, http://www.openspf.org/objections.html odpowiedź twórców SPF na niektóre zarzuty, http://antispam.yahoo.com/domainkeys infrastruktura uwierzytelniania nadawcy Yahoo!, http://www.microsoft.com/mscorp/safety/technologies/sender ID/default.mspx infrastruktura Microsoft Sender ID, http://www.pfir.org/tripoli-overview TRIPOLI: An Empowered E-Mail Environment, http://www.ftc.gov/bcp/workshops/spam/supplements/eprivacygp.pdf dokument poświęcony Trusted Email Open Standard (TEOS), http://cobb.com/spam/teos.html więcej o projekcie TEOS. nia lidera rynku wymusiły złe rozwiązanie zamiast dobrego. Zawsze jest nadzieja, że Microsoft zrozumie, iż Sender ID to zły pomysł i że powinno się pomyśleć o alternatywie. Ale to tylko pobożne życzenia. Niestety inne interesujące projekty związane z uwierzytelnianiem nadawcy znane są nielicznym, a już z pewnością nie są tak promowane w mediach, jak SPF czy Sender ID. Nawet jeśli faktycznie są lepsze, to i tak wkrótce zostaną zapomniane. Opracowane przez Yahoo! rozwiązanie DomainKeys jest w dużej mierze podobne do SPF. Choć dodaje nową warstwę bezpieczeństwa, oparte jest na podobnym podejściu także używa DNS do dystrybucji. Stwarza jednak dodatkowe problemy. Dodatkowa warstwa bezpieczeństwa wykorzystuje klucze prywatne i publiczne do podpisywania wiadomości wychodzących z serwera. DomainKeys powoduje problemy przy korzystaniu z list dyskusyjnych, a ponadto bardzo obciąża serwery pocztowe (z powodu konieczności stosowania podpisów kryptograficznych). Istnieją też inne projekty, na przykład Tripoli. Rozwiązanie to oparto na koncepcji certyfikowania zewnętrznego (przez inne podmioty) oraz różnych poziomów certyfikacji. Tripoli nie proponuje żadnych gotowych rozwiązań, a projekt jest nadal w bardzo wczesnej fazie rozwoju. Oznacza to, że nie da sie określić, w którym kierunku pójdą jego autorzy oraz czy projekt zapewni sensowne sposoby radzenia sobie z opisywanym problemem. Zapowiada się jednak interesująco. Podobnie wygląda sprawa z projektem Trusted Email Open Standard (TEOS). Jest on starszy niż Tripoli i proponuje bardzo dużo zmian w infrastrukturze poczty. Oryginalna propozycja została opublikowana ponad trzy lata temu i można ją traktować jako ciekawy szkielet do tworzenia przyszłych rozwiązań. Jednak szanse na implementację tego rozwiązania są znikome. Co możemy zrobić? Przerażające jest, że wszyscy znaczący dostawcy zaczynają stosować SPF. Przerażające jest, że media, w tym renomowane serwisy antyspamowe, popierają projekt mimo jego małej efektywności i błędnych założeń. Niestety, użytkownicy mają na tę sytuację niewielki wpływ. Coraz więcej komercyjnych i darmowych serwisów pocztowych nie tylko publikuje rekordy SPF dla swoich domen (co samo w sobie nie jest złe), ale także chroni serwery za pomocą SPF (co jest złe, bo zmusza innych do stosowania tego rozwiązania). Robiąc to, mówią do nas: Zastosuj SPF, albo nie będziesz mógł komunikować się z nami. Brzmi to jak: Korzystaj z naszej sieci komórkowej, albo nie dodzwonisz się do żadnego z naszych abonentów. Jak możemy pomóc? Otwarcie sprzeciwiając się wprowadzaniu rozwiązań, które ograniczają wolność Internetu. Aby zapobiec monopolowi, możemy na przykład odrzucać pocztę z serwerów chronionych przez SPF niejako w rewanżu za odrzucanie naszych e-maili. Im więcej blokad, tym więcej klientów zgłosi swoje niezadowolenie i tym szybciej zdadzą sobie sprawę, że zmuszanie innych administratorów do robienia czegoś, co będzie warunkiem komunikacji, to bardzo zły pomysł. Możemy także zmienić wszystkie nasze rekordy SPF tak, by pozwolić każdemu serwerowi pocztowemu na przesyłanie e-maili z naszym adresem domenowym. W ten sposób zachowamy ideę przekierowywania poczty, jednocześnie znacznie zmniejszając skuteczność SPF i zniechęcając do jego stosowania. Wybór nie jest prosty, ale przyszłość starej i zasłużonej usługi e-mail jest w naszych rękach. www.hakin9.org hakin9 Nr 2/2006 6