Wprowadzenie do SPF

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

Software Development

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

original in en Bruno Sousa

en to pl Artur R. Sierp

AboutTheAuthor:[A small biography about the author]

Bruno studiuje w Portugalii. Wolny czas poświęca Linuksowi i fotografii.

Abstract:[Here you write a little summary]

SPF oznacza Sender Policy Framework (przyp. tł.: co w wolnym tłumaczeniu oznacza "Szkielet Polityki Bezpieczeństwa Nadawcy"). W swej istocie stara się on być standardem zabezpieczającym przed fałszowaniem adresów e-mail. Ten artykuł jest krótkim wprawadzeniem do SPF oraz opisuje jego zalety i wady.

ArticleIllustration:[One image that will end up at the top of the article]

ArticleBody:[The main part of the article]

SPF miał swój początek w roku 2003. Jego twórca Meng Weng Wong zebrał najlepsze cechy Reverse MX i DMP ( Designated Mailer Protocol) powołując do życia SPF.
SPF używa return-path ( ścieżki powrotnej ) lub MAIL FROM ( list od ) występujące w nagłówku wiadomości email. Wszyskie MTA (serwery zajmujące sie dostarczaniem poczty) używają tego nagłówka, chociaż pojawiła sie nowa propozycja sygnowana przez Micro$oft (brrr, brrr) zwana PRA (Purported Responsible Address). PRA odzwierciedla w tym przypadku adres nadawcy.
Kiedy więc połączymy razem SPF i PRA otrzymamy Sender ID (numer indentyfikujący nadawcę). Sender ID pozwala użytkownikowi , który otrzymał email, na sprawdzenie nadawcy poprzez zawartości nagłówka (MAIL FROM)- za pomocą SPF, a dokładniej mówiac to MTA sprawdza (MAIL FROM) a MUA dokonuje sprawdzenia za pomocą mechanizmu PRA.
Aktualnie SPF aby działać poprawnie potrzebuje DNSa. Dokładniej mówiąc rekord "reverse MX" musi być dostępny na DNS, aby możliwe było jednoznaczne określenie maszyny wraz z domeną z której został wysłany list. Różni sie to od "zwykłego" MX , używanego obecnie, pozwalającego na określenie jedynie domeny z której pochodzi nadawca listu.

Czego SPF wymaga do prawidłowego działania?

Aby chronić swój system za pomocą SPF musisz:

Skonfiguruj swój DNS dodając rekord TXT, gdzie o znajdujące sie tam informacje bedzie pytać SPF.
Skonfiguruj swój serwer pocztowy (qmail, sendmail) pod kontem SPF, co oznaczać będzie weryfikację każdej wiadomości na serwerze.

Najpierw swoją uwagę skupimy na punkcie pierwszym , czyli na serwerze DNS odpowiedzialnym za daną domenę. W tej części artykułu opiszemy szczegóły rekordu TXT. Jedyną rzeczą z która sie spotkasz jest składnia plików konfiguracyjnych twojego serwera DNS. Nie obiawiaj sie tego tak bardzo, gdyż na oficjalnej stronie SPF znajduje się wspaniały opis , który poprowadzi Cie za rączke. h2>Rekord TXT dla SPF Format rekordu TXT dla SPF przedstawia się następująco:

		v=spf1 [[pre] type [ext] ] ... [mod]

Znaczenie każdego parametru jest następujące:

Parametr

Opis

v=spf1

Wersja SPF. Kiedy używasz Sender ID to ustaw : v=spf2

pre

Kody powrotu. Zwracane podczas wystąpienia dopasowania:

Możliwe wartości:

Wartość	Opis
+	Domyślne. Oznacza przejście testu.
-	Oznacza nie przejście testu.
~	Miekki błąd (Soft fail). Wartość normalnie przypisywana kiedy test nie jest ostateczny.
?	Neutralny. Wartość normalnie przypisywana kiedy test nie jest ostateczny.

type

Definicje typów użytych podczas weryfikacji.

Możliwe wartości:

Wartość	Opis
include	przyłacza domeny do testu. podaje się go w formie include:domain
all	kończy sekwencje testu. Dla przykładu: podajemy -all i wówczas jeżeli wszystkie dotychczasowe (do wystąpienia all) testy nie pasują , wówczas cały test zawodzi. Gdy natomiast nie jesteśmy pewni co do tego rozwiązania , możemy podać ?all wówczas winik testu jest przyjmowany jako zaakceptowany.
ip4	Używa protokołu IP4 podczas weryfikacji. Używany w formie ip4:ipv4 lub ip4:ipv4/cidr do zdefiniowania zasięgu. Gdzie np.: ipv4 to 192.168.1.0. Ten protokół jest najbardziej zalecany.
ip6	Używa protokołu IP6 podczas weryfikacji.
a	Używa domenowych nazw podczas weryfikacji. Czyta w DNS rekord A RR Używany w formie a:domain, a:domain/cidr lub a/cidr.
mx	Używa DNS MX RR podczas weryfikacji. Rekord MX RR definiuje odbierający MTA. Dla przykładu: jeżeli nie będzie to ten sam MTA służący do wysyłanie, wówczas test bazujący na MX zawiedzie. Używany w formie mx:domain, mx:domian/cidr lub mx/cidr.
ptr	Używa DNS PTR RR podczas weryfikacji. W tym przypadku jeżeli nazwa hosta znajduje się w domenie wówczas komunikacja zostaje zweryfikowana pozytywnie. Używany w formie ptr:domain.
exist	Test na istnienie domeny. Używany w formie exist:domain.

ext

Definiuje opcjonalne rozszeżenie do danego typu. Jeżeli zostanie ominięte to wówczas użyta jest prosta forma (a, mx lub ptr)

mod

To jest ostatni typ i występuje jako modyfikator.

Modyfikator	Opis
redirect	Przekazuje sposób weryfikacji SPF zapisaną w podanej domenie. Używany w formie redirect=domain.
exp	Ten rekord musi wystąpić jako ostatni i pozwala na zmiane wysyłanej informacji o błędzie. IN TXT "v=spf1 mx -all exp=getlost.example.com" getlost IN TXT "Nie masz autoryzacji do wysyłania z tej domeny"

Hey, jestem ISP (tł.: "dostawcą usług sieciowych")

Oczywiście dostawcy mogą mieć trudności ze swoimi klientami którzy używają POPa zamiast SASL SMTP.
Dlatego, jeżeli jesteś ISP i kłopotem jest dla Ciebie SPAM, albo podszywanie sie pod konta, to wówczas rozważ zmiane polityki dytyczącą poczty i zacznij używać SPF.
Podam Ci kilka kroków które musisz rozważyć:

Po pierwsze skonfiguruj swój MTA aby używał SASL.
Poinformuj swoich użytkowników o polityce jaką wprowadzasz ( na spf.pobox.com znajdziesz przykłady).
Daj swoim użytkownikom czas na przywyknięcie. Znaczy to tyle, że ustawiając SPF w DNS zastosuj softfail (~all) zamiast bezwarunkowego (-all)

Dzięki temu ochronisz swoje serwery, swoich klientów i ręszte przed zalewem Spamu.

Na oficialnej stronie SPF znajdziesz wiele cennych informacji. A więc na co czekasz?

Czy są sytuacje na które muszę zwrócic szczególną uwagę?

SPF jest idealnym rozwiązaniem broniącym przeciwko oszustwom, chociaż posiada jedną wadę: tradycyjny forwarding po prostu nie działa. Nie możesz otrzymanej poczty przekazać dalej. Musisz za każdym razem zmienić adres nadawcy. Odpowiednie łaty dla popularnych MTA znajdziesz na stronie SPF . Mówiąc prościej: jeżeli umieścisz w DNS zapisy dotyczące SPF, musisz ustawić MTA tak, aby zmieniały adres nadawcy, nawet wówczas gdy nie sprawdzasz reguł SPF.

Wnioski

Możesz pomyśleć, że wdrażanie SPF może być conajmniej zagmatwane. Ale tak naprawdę nie jest skomplikowane i na stronach dotyczących SPF znajdziesz wiele przykładów które pomogą Ci w osiągnięciu celu.

Jeżeli masz dość spamu wówczas SPF może okazać sie bardzo pomocnym, chroniąc twoją domenę przed podszywaniem się, a wszystko co musisz zrobić to dodać kilka linijek tekstu do konfiguracji serwera DNS i odpowiednio skonfigurować serwer pocztowy.

Korzyści które dostarcza SPF są naprawdę duże. Chociaż, jak powiedziałem komuś, kiedyś - " nie ma różnicy miedzy nocą a dniem ". Korzyści ze stosowania SPF przyjdą z czasem, gdy inni zaczną ten mechanizm stosować.

Wspominając o Sender ID, jako krewniku SPF, nie rozszerzyłem opisu na jego temat. Prawdopodobnie już znasz powód - tak, polityka Micro$oftu jest zawsze taka sama - patenty na oprogramowanie. W odnośnikach znajdziesz pozycje dotyczącą SenderID

W następnym artykule porozmawiamy na temat konfiguracji MTA, a więc zapraszam.

Mam nadzieję, że przydało Ci sie to krótkie wprowadzenie do SPF. Jeżeli jesteś zainteresowany dowiedzieć i nauczyć się więcej, to skorzystaj z poniższych odnośników, których sam używałem podczas pisania tego artykułu.

Odnośniki

The official site of SPF.
The official FAQ of SPF.
The official wizard of SPF.
The position of the openspf.org about SenderID.
An excellent article about SenderId and SPF.
warn your users about the SASL convertion
HOWTO - Define an SPF Record