Protokół SMTP.doc

(170 KB) Pobierz
Protokół SMTP

PROTOKÓŁ SMTP

 

Mimo nowych możliwości, jakie dają komunikatory, e-mail ciągle zyskuje na popularności i znaczeniu. Wszystko zaczęło się w roku 1971 w sposób, który trudno byłoby nazwać spektakularnym. Technik w BBN, Ray Tomlinson, przesłał e-mail między dwoma komputerami, które były połączone w sieci ARPAnet. Poszukując rzadko używanego 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. Umożliwiło ono po raz pierwszy wysyłanie za pomocą programu pocztowego wiadomości jednocześnie do wielu sieci. Dzisiejszy sukces e-maila był nie do przewidzenia w roku 1971 i wynalazek Thomlinsona zasłużył sobie tylko na kilka wzmianek w prasie. Dziś nie sposób wyobrazić sobie życia bez poczty elektronicznej, a dla wielu ludzi jest ona wręcz warunkiem funkcjonowania.

Poczta elektroniczna opiera się na trzech protokołach - SMTP do wysyłania oraz POP i IMAP do odbioru. Specyfikację każdego protokołu opisano w jednym lub kilku dokumentach RFC.

 

Simple Mail Transfer Protocol - SMTP

Zadaniem SMTP jest niezawodny i wydajny transport wiadomości. Protokół ten jest niezależny od protokołu sieciowego; zwykle stosowany jest standardowy protokół Internetu, TCP. Komunikacja odbywa się przez port 25.

Za wymianę wiadomości odpowiadają tzw. mail transfer agents (MTA). Najbardziej znanym MTA jest Sendmail. Użytkownik zwykle nie ma z nimi bezpośrednio do czynienia. Dostawą poczty do i z MTA zajmują się klienty pocztowe, takie jak Outlook czy KMail. MTA komunikują się między sobą za pomocą zwykłych znaków ASCII. Klient wysyła polecenia do serwera, który odpowiada za pomocą kodu numerycznego i opcjonalnego ciągu znaków.

Simple Mail Transfer Protocol ma jednak jedną, istotną wadę - po wysłaniu e-maila nie otrzymuje się żadnej wiadomości o jego dalszych losach. Specyfikacja przewiduje wprawdzie powiadomienie nadawcy w sytuacji, gdy wiadomość nie może być dostarczona. Nie jest określone jednoznacznie, jak taka wiadomość ma wyglądać. Zwykle jest to e-mail z komunikatem o błędzie i nagłówkiem niedostarczonej wiadomości. Ze względu na brak standardu, w praktyce rzadko udaje się ustalić, gdzie i dlaczego wystąpił błąd.

Dlatego też opracowano rozszerzenie SMTP, definiujące standardowe powiadomienia o błędach. Niestety bardzo niewiele serwerów obsługuje obecnie to rozszerzenie.


Proces SMTP

Proces SMTP

 

Typowe połączenie SMTP składa się z następujących etapów:

·         Klient SMTP inicjuje połączenie z serwerem SMTP. Klient korzysta z losowo wybranego portu o numerze powyżej 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ść, wykorzystując polecenie MAIL FROM: -adres-, gdzie -adres- jest adresem poczty elektronicznej użytkownika wysyłającego. Zazwyczaj odpowiada on adresowi zwrotnemu określonemu w programie pocztowym klienta. Serwer ponownie powinien odpowiedzieć komunikatem 250 - ok.

·         Klient określa następnie wszystkich odbiorców, do których wiadomość jest skierowana. Korzysta w tym celu z polecenia RCPT TO: -adres-. Jeżeli serwer obsługuje wielu odbiorców, dla każdego z nich przesyłane jest kolejne polecenie RCPT TO:. Odpowiedzią serwera na informację o każdym kolejnym odbiorcy jest komunikat 250 - ok.

·         Klient informuje o gotowości do przesyłania właściwej wiadomości komunikatem DATA. Serwer odpowiada komunikatem 250 -ok-. Określa również ciąg znaków, który spodziewa się otrzymać na znak końca treści wiadomości. Najczęściej jest to [CR][LF].[CR][LF]. Potem następuje przesłanie do serwera tejże treści. Wiadomość przesyłana jest przy użyciu znaków 7-bitowego ASCII. Jeżeli towarzyszą jej załączniki, muszą one zostać przetworzone do tej postaci. Wykorzystuje się do tego celu mechanizm BinHex, uencode lub MIME.

·         Po zakończeniu transmitowania wiadomości, klient wysyła polecenie QUIT kończące sesję SMTP. Serwer odpowiada komunikatem 221 -closing-, co oznacza, że nastąpiło zakończenie sesji. Jeżeli klient wysyła następną wiadomość, proces ponownie rozpoczyna się od polecenia MAIL FROM:.

 

Droga e-maila od nadawcy do odbiorcy

 

Polecenia protokołu SMTP

Polecenie definiują sposób przesyłania e-maili. Zgodnie ze specyfikacją implementacja SMTP musi obsługiwać, co najmniej osiem poleceń:

 

POLECENIE

OPIS

HELO

Inicjuje połączenie i identyfikuje nadawcę SMTP dla odbiorcy SMTP

MAIL

Inicjuje transakcję pocztową

RCPT

Identyfikuje pojedynczego adresata

DATA

Identyfikuje wiersze następujące po poleceniu jako dane pocztowe od nadawcy

RSET

Przerywa bieżącą transakcję pocztową

SEND

Dostarcza pocztę do terminala

SOML

Dostarcza pocztę do terminala. Jeżeli ta operacja się nie powiedzie, poczta zostanie dostarczona do skrzynki pocztowej

SAML

Dostarcza pocztę do terminala. Poczta jest również dostarczana do skrzynki pocztowej

VRFY

Weryfikuje nazwę użytkownika

EXPN

Rozwija listę dystrybucyjną

HELP

Sprawia, że odbiorca wysyła przydatne informacje

NOOP

Żąda, by odbiorca wysłał odpowiedź OK, ale w przeciwnym razie nie określa żadnych działań

QUIT

Żąda, by odbiorca wysłał odpowiedź OK, a następnie zamknął kanał transmisyjny

TURN

Żąda, by odbiorca przejął rolę nadawcy. Jeżeli zostanie otrzymana odpowiedź OK, to nadawca staje się odbiorcą

 

Kody odpowiedzi SMTP

Kody odpowiedzi SMTP gwarantują, że klient jest na bieżąco informowany o statusie serwera. Każde polecenie wymaga kodu odpowiedzi od serwera. Klient decyduje o sposobie dalszego postępowania wyłącznie na podstawie otrzymanych zwrotnie kodów numerycznych.

 

KOD

ZNACZENIE

211

Odpowiedź stanu systemu lub pomocy systemowej

214

Komunikat pomocy

220

Usługa gotowa

221

Usługa zamyka kanał transmisyjny

250

Żądane działanie poczty OK, zakończone

251

Użytkownik nielokalny; przekażę do ścieżki przekazywania

354

Rozpocznij wprowadzanie poczty

421

Usługa niedostępna, zamykam kanał transmisyjny

450

Żądane działanie poczty nie zostało podjęte: skrzynka pocztowa niedostępna

451

Żądane działanie zostało przerwane

452

Żądane działanie nie zostało podjęte: niewystarczająca ilość pamięci 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 podjęte: skrzynka pocztowa niedostępna

551

Użytkownik nielokalny; spróbuj wykorzystać ścieżkę przekazywania

552

Żądane działanie poczty zostało przerwane: przekroczona alokacja pamięci

553

Żądane działanie nie zostało podjęte: niedozwolona nazwa skrzynki pocztowej

554

Transakcja nie powiodła się

 

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 dostępu do serwerów internetowych i FTP, lecz również w kwestii przesyłania wiadomości 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ą wiadomości dla tej domeny. Każdy mail exchanger ma określony priorytet o długości 16 bitów. Serwer SMTP próbuje zatem po kolei dostarczyć wiadomość do któregoś z serwerów zgodnie z priorytetem.

 

Zasadniczo wiadomość może przechodzić przez wiele serwerów SMTP. Wbrew szeroko rozpowszechnionemu mniemaniu, jakoby e-maile mogły kilkakrotnie okrążyć Ziemię, zanim w końcu dotrą do odbiorcy, w rzeczywistości z reguły przechodzą tylko przez dwa serwery SMTP. Zapobieganie powstawaniu takich pętli jest właśnie zadaniem rekordów MX. Mimo to w wyjątkowych przypadkach może się zdarzyć, że taka pętla 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.

 

DNS i e-mail

 

...

Zgłoś jeśli naruszono regulamin