[an error occurred while processing this directive]
![[Photo of the Author]](../../common/images/BrunoSousa.jpg)
Bruno Sousa
<bruno/at/linuxfocus.org>
O Autorze:
Bruno studiuje w Portugalii. Wolny czas poświęca Linuksowi i fotografii.
Tlumaczenie na jezyk polski:
Artur R. Sierp <artursp(malpa)o2.pl>
Zawartość:
|
Wprowadzenie do SPF
![[Illustration]](../../common/images2/article354.gif)
Notka:
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.
_________________ _________________ _________________
|
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
Dyskusja dotycząca tego artykułu
Komentarze do dyskusji:
2004-12-10, generated by lfparser version 2.50
![[LinuxFocus-icon]](../../common/images/logolftop_319x45.gif){kind=small}
