Na wstępie warto przytoczyć parę faktów. Whois dla domeny grono.net:

[...]
Domain servers in listed order:
      DNS1.GRONO.NET
      DNS2.GRONO.NET

Odpytanie naszych serwerów dns o rekordy NS dla strefy grono.net

mieki@mieki-laptop:~$ host -t ns grono.net dns1.grono.net
Using domain server:
Name: dns1.grono.net
Address: 193.33.58.3#53
Aliases: 

grono.net name server dns1.grono.net.
grono.net name server dns2.grono.net.

oraz:

mieki@mieki-laptop:~$ host -t ns grono.net dns2.grono.net
Using domain server:
Name: dns2.grono.net
Address: 193.33.58.4#53
Aliases: 

grono.net name server dns2.grono.net.
grono.net name server dns1.grono.net.

Czyli jak widać, delegacja na nasze serwery jest zrobiona w sposób poprawny. Serwis grono.net posiada przyznaną przez RIPE klasę adresów 193.33.59.0/23. Jest to pula PI i rozgłaszamy ją z naszego routera (AS42782).

Jak wiadomo, powszechnym problemem w sieci internet jest wszędobylski spam. Wiadomości o treści reklamowej na przykład o powiększaniu pewnej części ciała. Najczęściej są rozsyłane z zainfekowanych wirusami (lub koniami trojańskimi) komputerów. Posiadacze zarażonego peceta nie są świadomi, że mogą rozsyłać kilkaset maili na sekundę. Odbiorcami spamu są maile użytkowników, zbierane do bazy przez spam-harvestery (czyli takie skrypty, monitorujące witryny webowe, grupy dyskusyjne i inne zasoby sieci w poszukiwaniu prawidłowych adresów email), a także pobierane są z książek adresowych popularnych programów pocztowych na zainfekowanych komputerach.

Protokół przesyłania poczty (SMTP) został zaprojektowany we wczesnych latach osiemdziesiątych XX wieku i praktycznie w niezmienionej formie pozostał do dziś. Ma on szereg błędów, których istnienie można było przewidzieć już na poziomie projektowania samego protokołu. Jednym z poważniejszych z nich jest możliwość podszywania się pod nadawcę. Do tego można użyć zwykłego programu telnet i udawać klienta pocztowego.

Poniżej zaprezentowałem próbę wysłania poczty z konta na nieistniejącej domenie:

mieki@mieki-laptop:~$ telnet mx.grono.net 25
Trying 193.33.58.136...
Connected to mx.grono.net.
Escape character is '^]'.
220 dakota.nemo.pl Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Thu, 4 Oct 2007 23:51:24 +0200 
ehlo jakasdomena.pl
250-dakota.nemo.pl Hello [82.210.166.16]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
mail from: piotr@jakasdomena.pl
250 2.1.0 piotr@jakasdomena.pl....Sender OK
rcpt to: p.milczarek@grono.net
250 2.1.5 p.milczarek@grono.net 
data
354 Start mail input; end with <CRLF>.<CRLF>
From: Piotr Z JakiejsDomeny <piotr@jakasdomena.pl>
Subject: Przykładowa wiadomosc          

Tutaj tresc wiadomosci, czy to dojdzie ?

.
250 2.6.0 <DAKOTAogkJXrRjbDt3H000001ad@dakota.nemo.pl> Queued mail for delivery
quit
221 2.0.0 dakota.nemo.pl Service closing transmission channel
Connection closed by foreign host.

Dopiero po zajrzeniu w nagłówki możemy stwierdzić, że pole From jest sfałszowane.

Received: from jakasdomena.pl ([82.210.166.16]) by dakota.nemo.pl with Microsoft SMTPSVC(6.0.3790.3959);
         Thu, 4 Oct 2007 23:52:26 +0200

podczas gdy:

mieki@mieki-laptop:~$ host jakasdomena.pl
jakasdomena.pl has address 83.133.126.177
jakasdomena.pl mail is handled by 0 jakasdomena.pl.

Czyli host 82.210.166.16 nie jest ani wpisem IN A dla jakasdomena.pl, ani wpisem MX w tej domenie (wybór domeny był całkowicie przypadkowy).

Aby zapobiec procederom tego typu jak powyższy, w Kwietniu 2006 powstał dokument RFC opisujący jak definiować na serwerach dns rekordy dotyczących uprawnień wysyłania poczty.

Typ rekordu, w jakim definiujemy które serwery mogą rozsyłać pocztę z danej domeny, a które nie, to TXT. Przykładowy rekord dla przykładowej domeny grono.net :-)

mieki@mieki-laptop:~$ host -t txt grono.net
grono.net descriptive text "v=spf1 +ip4:193.33.58.0/23 -all" // o tym teraz
grono.net descriptive text "spf2.0/mfrom,pra +ip4:193.33.58.0/23 -all" // natomiast o tym troche później

Ten rekord oznacza deklaracje mechanizmu Sender Policy Framework dla domeny grono.net. Pierwszym elementem rekordu SPF jest deklaracja wersji czyli "v=spf1", następnie występuje lista elementów dla których ustalamy politykę rozsyłania poczty.

Każdy taki element składa się z kilku części. Część pierwsza – kwalifikator – jest to mały znaczek od którego zaczyna się element, wskazujący co zrobić z pocztą przychodzącą od danego elementu. Wszystkie poniższe elementy przedstawiłem w maksymalnym uproszczeniu:

• ”+” – whitelisting – czyli bezwarunkowe zaakceptowanie poczty i oznaczenie jej jako nie SPAM
• ”-” – blacklisting – oznaczenie poczty jako niechciana/niepożądana
• ”˜” – greylisting – w skrócie: zastosuj swoje mechanizmy filtrowania poczty i detekcji spamu

Istnieje jeszcze kwalifikator ”?”, który działa podobnie do ”˜”, ale nie będziemy się zagłębiać w szczegóły. Część druga – typ obiektu:

• “a” – rekord IN A w danej domenie np +a – oznacza deklaracje o wysyłaniu poczty z rekordu (bądź rekordów) IN A dla samej domeny
• “ip4” – oznacza zakres hostów przedstawiony w postaci CIDR, bądź jeden host bez maski podsieci np. -ip4:193.33.58.0/23
• “mx” – oznacza wpis lub wpisy mx w danej domenie, na przykład -mx oznacza deklaracje, że z serwerów pocztowych nie rozsyłamy poczty :>
• “all” – oznacza wszystkie inne niezdefiniowane w SPF

Część trzecia (opcjonalna) – wartość parametru: W przypadku domeny grono.net użyty tylko raz – chodzi o “193.33.58.0/23” – czyli klasę adresów IP którą posiada Grono.net

SPF przyjął się jako standard jeżeli chodzi o politykę rozsyłania poczty. Jednakże istnieje sobie firma na świecie o nazwie Microsoft, która stwierdziła, że stworzy swój własny mechanizm polityki walki z pocztą – SenderID. Do deklaracji tego mechanizmu służy właśnie drugi rekord TXT.

Niestety, portale o których wspomniałem na samym początku wykorzystują tę drugą technologię.(Nie wnikam już kto jest rzeczonych serwisów). SenderID nie wnosi tak naprawdę nic więcej do walki ze spamem niż SPF (nawet składnia jest identyczna jeżeli chodzi o deklaracje obiektów). Faktem jest, że wprowadza bardziej szczegółowe sprawdzanie nagłówków które pojawiają się w poczcie (From: i Return Ptah:), oraz tego co jest podawane po HELO/EHLO.

Niestety po mimo zastosowania się do rad potentata z Redmond, nie ma skutecznego sposobu na dostarczenie poczty do adresata, który ma konto przykładowo na serwisie hotmail.com.

Po długich i mozolnych testach udało nam się zaobserwować 2 zachowania serwisu:
1. Poczta ląduje w folderze Junk, z którego jest automagicznie wywalana po 10 dniach
2. Poczta wcale nie dociera do adresata.
W jednym i drugim przypadku serwer smtp hotmaila zwraca:

250 <BAY0-MC10-F5snIXriu0001e384@bay0-mc10-f5.bay0.hotmail.com> Queued mail for delivery

Jeżeli poczta wpadnie do folderu junk i sprytny użytkownik ją oznaczy, że spamem nie jest(kliknie w “znam nadawcę”), kolejna poczta od tego adresata (z tego samego serwera pocztowego), nie jest wrzucana do folderu “Junk” ... ale tylko przez ok. tydzień.

Po przewertowaniu zasobów Usenetu jestem w stanie wysnuć tezę, iż serwery stosujące technologię SenderID zachowują się zgoła niedeterministycznie, albo rządzi nimi jakaś mroczna logika rozmyta, do której zwykły śmiertelnik nie ma dostępu. Na domiar tego dodam, iż ta cudowna technologia jest opatentowana oraz jej nie można stosować bez zgody Microsoftu. Próby kontaktu z kimś ze strony MS są z góry skazane na niepowodzenie. Na maile odpowiadają automaty, albo nic nie odpowiada (w sumie nie dziwne, może im ktoś problem zgłaszał, że im nie działa poczta jak powinna – drogą właśnie pocztową). Po kilku telefonach do MS w pięknym kraju nad Wisłą nie udało się znaleźć osoby kompetentnej, która by podpowiedziała jak w/w problem rozwiązać. Nawet więcej, nie udało się znaleźć osoby, która potrafi skontaktować z personą kompetentną w dziedzinie SenderID.

Dla ciekawskich dodam, iż były zmieniane TTLe rekordów w dnsach, oraz wpisy PTR serwerów dns i pocztowych, z których chcemy coś skutecznie dostarczyć do hotmaila – efekt zawsze ten sam. Zrobiliśmy to już na wszystkie możliwe sposoby – zaglądając nawet do nagłówków, poczty która do hotmaila jakimś cudem dotarła.

My chcemy tylko powiadomić o urodzinach znajomego… a nie powiększyć pewną część ciała.

Dla cierpliwych i szukających wrażeń opis jak działa (albo jak powinno działać) SenderID można znaleźć tutaj: http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx.