Wysyłanie poczty elektronicznej PROTOKÓŁ SMTP

Wysyłanie poczty elektronicznej PROTOKÓŁ SMTP

2 1. Krótka historia Mimo nowych moliwoci, jakie daj komunikatory, e-mail cigle zyskuje na popularnoci i znaczeniu. Z bada rynku przeprowadzonych przez IDC wynika, e w roku 2005 mona si spodziewa 36 miliardów e-maili dziennie! W roku 2000 w uyciu było około 505 milionów skrzynek poczty elektronicznej, w roku 2005 t form komunikacji ma si ju posługiwa ok. 1,2 mld uytkowników. Wszystko zaczło si w roku 1971 w sposób, który trudno byłoby nazwa spektakularnym. Technik w BBN, Ray Tomlinson, przestał e-mail midzy dwoma komputerami, które były połczone w sieci ARPAnet. Poszukujc rzadko uywanego znaku dla wyrónienia poczty elektronicznej odkrył @ i w ten sposób ustanowił symbol nowej epoki. Kolejnym krokiem milowym w historii poczty elektronicznej było opracowane w roku 1981 przez Erica Allmana oprogramowanie Sendmail. Umoliwiło ono po raz pierwszy wysyłanie za pomoc programu pocztowego wiadomoci jednoczenie do wielu sieci. Dzisiejszy sukces e-maila był nie do przewidzenia w roku 1971 i wynalazek Thomlinsona zasłuył sobie tylko na kilka wzmianek w prasie. Dzi nie sposób wyobrazi sobie ycia bez poczty elektronicznej, a dla wielu ludzi jest ona wrcz warunkiem funkcjonowania. Poczta elektroniczna opiera si na trzech protokółach SMTP do wysyłania oraz POP i IMAP do odbioru. Specyfikacj kadego protokołu opisano w jednym lub kilku RFC. 2. Simple Mail Transfer Protocol SMTP Zadaniem SMTP jest niezawodny i wydajny transport wiadomoci. Protokół ten jest niezaleny od protokołu sieciowego; zwykle stosowany jest standardowy protokół Internetu, TCP. Komunikacja odbywa si przez port 25. Za wymian wiadomoci odpowiadaj tzw. mail transfer agents (MTA). Najbardziej znanym MTA jest Sendmail. Uytkownik zwykle nie ma z nimi bezporednio do czynienia. Dostaw poczty do i z MTA zajmuj si klienty pocztowe, takie jak Outlook czy KMail. MTA komunikuj si midzy sob za pomoc zwykłych znaków ASCII. Klient wysyła polecenia do serwera, który odpowiada za pomoc kodu numerycznego i opcjonalnego cigu znaków. Simple Mail Transfer Protocol ma jednak jedn, istotn wad po wystaniu e-maila nie otrzymuje si adnej wiadomoci o jego dalszych losach. Specyfikacja przewiduje

3 wprawdzie powiadomienie nadawcy w sytuacji, gdy wiadomo nie moe by dostarczona. Nie jest okrelone jednoznacznie, jak taka wiadomo ma wyglda. Zwykle jest to e-mail z komunikatem o błdzie i nagłówkiem niedostarczonej wiadomoci. Ze wzgldu na brak standardu w praktyce rzadko udaje si ustali, gdzie i dlaczego wystpił błd. Dlatego te opracowano rozszerzenie SMTP, definiujce standardowe powiadomienia o błdach. Niestety bardzo niewiele serwerów obsługuje obecnie to rozszerzenie. 2.1. Proces SMTP Rys.: Sie o topologii magistrali ródło: Komar, B. (2002). TCP/IP dla kadego. Gliwice: Helion, strona 373 Typowe połcznie SMTP składa si z etapów: Klient SMTP inicjuje połczenie z serwerem SMTP. Klient korzysta z losowo wybranego portu o numerze powyej 1024 i łczy si z portem serwera o numerze 25. Serwer sygnalizuje akceptacj połczenia komunikatem 220 <Ready> Klient da ustanowienia sesji poprzez wysłanie polecenia HELO (ang. Hello) lub EHLO (ang. Extended Hello). Polecenie to powinno zawiera pełn nazw (FQDN) klienta. Serwer odpowiada komunikatem 250 <OK> Klient informuje serwer, kto wysyła wiadomo, wykorzystujc polecenie MAIL FROM: <Adres>, gdzie <Adres> jest adresem poczty elektronicznej uytkownika wysyłajcego. Zazwyczaj odpowiada on adresowi zwrotnemu

4 okrelonemu w programie pocztowym klienta. Serwer ponownie powinien odpowiedzie komunikatem 250 <OK>. Klient okrela nastpnie wszystkich odbiorców, do których wiadomo jest skierowana. Korzysta w tym celu z polecenia RCPT TO: <Adres>. Jeeli serwer obsługuje wielu odbiorców, dla kadego z nich przesyłane jest kolejne polecenie RCPT TO:. Odpowiedzi serwera na informacj o kadym kolejnym odbiorcy jest komunikat 250 <OK>. Klient informuje o gotowoci do przesyłania właciwej wiadomoci komunikatem DATA. Serwer odpowiada komunikatem 250 <OK>. Okrela równie cig znaków, który spodziewa si otrzyma na znak koca treci wiadomoci. Najczciej jest to [CR][LF].[CR][LF]. Potem nastpuje przesłanie do serwera teje treci. Wiadomo przesyłana jest przy uyciu znaków 7- bitowego ASCII. Jeeli towarzysz jej załczniki, musz one zosta przetworzone do tej postaci. Wykorzystuje si do tego celu mechanizm BinHex, uuencode lub MIME. Po zakoczeniu transmitowania wiadomoci, klient wysyła polecenie QUIT koczce sesj SMTP. Serwer odpowiada komunikatem 221 <C1osing>, co oznacza, e nastpiło zakoczenie sesji. Jeeli klient wysyła nastpn wiadomo, proces ponownie rozpoczyna si od polecenia MAIL FROM:. Rys.: Droga e-maila od nadawcy do odbiorcy ródło: PC World Komputer PRO. Nr 3/2003 2.2. Polecenia protokołu SMTP Polecenie definiuj sposób przesyłania e-maili. Zgodnie ze specyfikacj implementcaja SMTP musi obsługiwa co najmniej osiem polece:

5 Tabela 1. Polecenia SMTP. POLECENIE HELO MAIL RCPT DATA RSET SEND SOML SAML VRFY EXPN HELP NOOP QUIT TURN OPIS Inicjuje połczenie i identyfikuje nadawc SMTP dla odbiorcy SMTP Inicjuje transakcj pocztow Identyfikuje pojedynczego adresata Identyfikuje wiersze nastpujce po poleceniu jako dane pocztowe od nadawcy Przerywa biec transakcj pocztow Dostarcza poczt do terminala Dostarcza poczt do terminala. Jeeli ta operacja si nie powiedzie, poczta zostanie dostarczona do skrzynki pocztowej Dostarcza poczt do terminala. Poczta jest równie dostarczana do skrzynki pocztowej Weryfikuje nazw uytkownika Rozwija list dystrybucyjn Sprawia, e odbiorca wysyła przydatne informacje da, by odbiorca wysłał odpowied OK, ale w przeciwnym razie nie okrela adnych działa da, by odbiorca wysłał odpowied OK, a nastpnie zamknł kanał transmisyjny da, by odbiorca przejł rol nadawcy. Jeeli zostanie otrzymana odpowied OK, to nadawca staje si odbiorc 2.3. Kody odpowiedzi SMTP Kody odpowiedzi SMTP gwarantuj, e klient jest na bieco informowany o statusie serwera. Kade polecenie wymaga kodu odpowiedzi od serwera. Klient decyduje o sposobie dalszego postpowania wyłcznie na podstawie otrzymanych zwrotnie kodów numerycznych. Tabela 2. Kody odpowiedzi SMTP KOD ZNACZENIE 211 Odpowied stanu systemu lub pomocy systemowej. 214 Komunikat pomocy. 220 Usługa gotowa.

6 221 Usługa zamyka kanał transmisyjny. 250 dane działanie poczty OK, zakoczone. 251 Uytkownik nielokalny; przeka do cieki przekazywania. 354 Rozpocznij wprowadzanie poczty. 421 Usługa niedostpna, zamykam kanał transmisyjny. 450 dane działanie poczty nie zostało podjte: skrzynka pocztowa niedostpna. 451 dane działanie zostało przerwane. 452 dane działanie nie zostało podjte: niewystarczajca ilo pamici systemowej. 500 Błd składniowy, polecenie nierozpoznane. 501 Błd składniowy w parametrach lub argumentach. 502 Polecenie nie zostało implementowane. 503 Zła kolejno polece. 504 Parametr polecenia nie został implementowany. 550 dane działanie poczty nie zostało podjte: skrzynka pocztowa niedostpna. 551 Uytkownik nielokalny; spróbuj wykorzysta ciek przekazywania. 552 dane działanie poczty zostało przerwane: przekroczona alokacja pamici. 553 dane działanie nie zostało podjte: niedozwolona nazwa skrzynki pocztowej. 554 Transakcja nie powiodła si. 2.4. Mail Routing i DNS Gdy serwer SMTP odbierze wiadomo od klienta, odpowiada za routing e-maila. System nazw domen (DNS) odgrywa centraln rol nie tylko w dziedzinie dostpu do serwerów internetowych i FTP, lecz równie w kwestii przesyłania wiadomoci elektronicznych. W systemie DNS przewidziano specjalne wpisy dla e-maili rekordy MX. Serwer identyfikuje komputer docelowy za pomoc tak zwanego mail exchange record domeny. W tym celu pyta serwer DNS i otrzymuje list serwerów (mail exchanger), które odbieraj wiadomoci dla tej domeny. Kady mail exchanger ma okrelony

7 priorytet o długoci 16 bitów. Serwer SMTP próbuje zatem po kolei dostarczy wiadomo do którego z serwerów zgodnie z priorytetem. Zasadniczo wiadomo moe przechodzi przez wiele serwerów SMTP. Wbrew szeroko rozpowszechnionemu mniemaniu, jakoby e-maile mogły kilkakrotnie okry Ziemi, zanim w kocu dotr do odbiorcy, w rzeczywistoci z reguły przechodz tylko przez dwa serwery SMTP. Zapobieganie powstawaniu takich ptli jest włanie zadaniem rekordów MX. Mimo to w wyjtkowych przypadkach moe si zdarzy, e taka ptla powstanie, na przykład w sytuacji gdy informacje routingowe s niekompletne lub nieaktualne. Taki przypadek zachodzi na przykład przy zmianie dostawcy usług internetowych. Rys.: DNS i e-mail ródło: PC World Komputer PRO. Nr 3/2003 2.5. Multipurpose Internet Mail Extension (MIME) W treci e-maili stosuje si 7-bitowy tekst ASCII. Zawiera on 128 znaków, jednak bez narodowych znaków specjalnych. W tej wersji nie mona wic pisa z polskimi ogonkami. RFC 2045 definiuje MIME, który eliminuje problemy, gdy w e-mailu uyto innego zestawu znaków ni US ASCII.

8 Tre e-maila MIME moe by w dalszym cigu przesyłana jako tekst ASCII, bez wzgldu na zawarto. Jedynym warunkiem stosowania jest obsługa przez klienta pocztowego. MIME dodaje do nagłówka pewne elementy, które objaniaj odbiorcy struktur treci. Tabela 3. Nagłówek MIME ELEMENT PARAMETR OPIS Wersja MIME 1.0 Okrela wersj MIME. Typ zawartoci Tekst, obraz itp. Okrela zawarto e-maila. W przypadku typów tekst i multipart dochodzi informacja o zestawie znaków oraz identyfikator czci tekstowej. Content Transfer Encoding 7bit, 8bit, binary, quotedprintable Charakteryzuje algorytm kodowania danych 2.5.1. Typy MIME MIME nie tylko umoliwia przesyłanie e-maili z załcznikami, lecz jednoczenie zapewnia informacj, któr klient pocztowy wykorzystuje do wybrania właciwego programu edycyjnego. Słuy do tego element nagłówka Typ zawartoci". MIME dzieli typy danych (typy mediów) na siedem grup głównych z wieloma podgrupami. Kade rozszerzenie nazwy pliku przypisane jest do jednego z typów mediów. Tabela 4. Waniejsze typy MIME NAZWA TYP OPIS tekst plain richtext enriched tekst niesformatowany tekst z prostym formatowaniem (kursywa) uproszczona i rozszerzona forma richtext mixed wieloczłomowa tre, elementy przetwarzane s sekwencyjnie multipart parallel wieloczłonowa tre, elementy przetwarzane s rónolegle digest wycig z e-maila alternative wieloczłonowa tre o identycznej zawartoci logicznej

9 message rfc882 partial external-body zawartoci jest inna wiadomo rfc822 zawartoci jest fragment e-maila zawartocia jest wskazówka do właciwej wiadomoci application octet-stream dane binarne postscript dane postscriptowe image jpeg format iso 10918 gif compuserve graphic interchange format (gif) audio basic kodowany format 8-bitowy -law video mpeg format iso 11172 2.6. Zabezpieczenie sesji SMTP SMTP to protokół notorycznie naduywany przez hakerów do wysyłania uytkownikom najróniejszych niespodzianek. Łatwo takiego wykorzystania protokołu pocztowego wynika wprost z jego,,ufnej natury. Działanie protokołu SMTP opiera si na technice okrelanej mianem przekazywanie SMTP (ang. SMTP relaying). Klient łczy si z serwerem SMTP i przekazuje wiadomoci do odbiorcy przez ich,,odbicie na serwer SMTP. Standardowo serwer SMTP pozwala przekazywa (odbija) wiadomoci dowolnym klientom. Wraz ze wzrostem problemu nieuprawnionego wysyłania wiadomoci wiele organizacji blokuje swoje serwery SMTP, ograniczajc moliwoci korzystania z przekazywania SMTP. Typowe rozwizania to: Ograniczenie przekazywania do wybranych podsieci IP. Mona skonfigurowa serwer SMTP tak, aby przyjmował wiadomoci wyłcznie od stacji pracujcych w wybranej podsieci IP. Mimo e sprawdza si to w odniesieniu do klientów w sieci lokalnej, nie moe by stosowane przez organizacje, w której uytkownicy zmieniaj miejsca korzystania z poczty elektronicznej. Poniewa uytkownik zmieniajcy miejsce pobytu korzysta z usług rónych ISP, zdefiniowanie wszystkich wymaganych podsieci jest praktycznie niemoliwe. Wprowadzenie uwierzytelniania SMTP. Protokół SMTP przewiduje moliwo uwierzytelniania klientów jeszcze zanim zaczn oni wysyła wiadomoci. Cho

10 wydaje si to rozwizaniem najlepszym, wie si z pewnym ryzykiem, poniewa uwierzytelnianie opiera si na jawnym przesyłaniu hasła. Wyłczanie przekazywania SMTP. W przypadku serwerów poczty, takich jak Microsoft Exchange Server 2000, pozwalajcych klientom łczy i uwierzytelnia si przy uyciu rozwiza firmowych, przekazywanie SMTP mona wyłczy. Wówczas usługi specyficzne dla serwera pocztowego bd przyjmowa wyłcznie wiadomoci kierowane do Intemetu. Z opcji tej nie mona skorzysta, gdy w sieci pracuj klienty protokołu POP3 lub IMAP4. Poza ograniczeniami przekazywania, wymiana danych SMTP moe by chroniona przy uyciu SSL, czyli mechanizmów opartych na technologii klucza publicznego. Zabezpieczenia SSL opieraj si na zabezpieczonej wymianie klucza sesji uywanego do szyfrowania całoci komunikacji midzy klientem a serwerem. Kiedy klient SMTP łczy si usług SMTP serwera pocztowego, otrzymuje klucz publiczny serwera. Procedura jest nastpujca: Klient łczy si z serwerem SMTP. W miejsce standardowego portu TCP 25 wykorzystywany jest port TCP 465 Serwer SMTP przesyła klientowi swój certyfikat. Jednym z jego atrybutów jest klucz publiczny serwera Klient weryfikuje certyfikat serwera: sprawdza powizanie z zaufanym głównym organem certyfikujcym (CA), kontroluje znacznik czasu, porównuje nazw wymienion w certyfikacie z pełn kwalifikowana nazw serwera i zestawia numer seryjny z listami certyfikatów uniewanionych Po udanej weryfikacji klient generuje losowy klucz sesji, szyfruje go przy uyciu klucza publicznego serwera i wysyła klucz do serwera. Serwer z kolei odszyfrowuje klucz sesji przy uyciu własnego klucza prywatnego i zwraca potwierdzenie, bdce dla klienta zarazem potwierdzeniem tosamoci serwera Do serwera przesyłana jest nazwa uytkownika i hasło (zaszyfrowane przy uyciu klucza sesji)

1 1. Literatura 1.1. Komar, B. (2002). TCP/IP dla kadego. Gliwice: Helion. 1.1. Scrimger R., LaSalle P., Leitzke C., Parihar M., Gupta M. (2002). TCP/IP. Biblia. Gliwice: Helion. 1.1. PC World Komputer PRO. Nr 3/2003.