http://soltysiak.com
..Królowa Kinga została swięta bo Bolesław był wstydliwy..
SMTP w skrocie - co mowi nasz program pocztowy?
Wstep
Tresc zawarta w tym artykule jest z pewnoscia znana wielu osobom, jednak zdecydowalem sie to opisac gdyz mam nadzieje, ze moze to wplynac na wiele osob tak jak to odkrycie wplynelo na mnie. A to bylo bardzo interesujace.
Glownym celem mojego przedstawienia sposobu komunikacji w protokole SMTP miedzy klientem a serwerem jest fundamentalny fakt, ze odbywa sie ona jak rozmowa. Uzywane sa slowa - komendy, na ktore dostajemy odpowiedzi. Co wiecej wiekszosc protokolow Internetowych realizuje komunikacje za pomoca komunikatow czytelnych dla czlowieka. Np. HTTP, FTP, Ident, POP3, IMAP czy IRC.
Schemat
Zdecydowalem sie przedstawic przebieg pojedynczej transakcji polegajacej na
wyslaniu jednej wiadomosci przez nadawce. Bedzie to przypadek
nie wykorzystujacy technologii takich jak STARTTLS czy SMTP-AUTH. Sa to
rozszerzenia, ktore w nie sa niezbedne do zrealizowania przykladu i
przedstawienia fundamentow. Dodatkowo nie rozwodze sie tutaj
nad kwestiami technologii takich jak SPF,
RBL czy open relay.
Oto przebieg:
- Przywitanie
- Opisanie nadawcy
- Opisanie adresata
- Przeslanie tresci przesylki
- Pozegnanie
Przyklad
Przyklad zrealizowany na podstawie prawdziwego polaczenia do mojego
wlasnego serwera SMTP jednak wszystkie adresy zostaly zmienione na fikcyjne.
Dane transakcji:
Serwer SMTP do ktorego sie podlaczamy nazywa sie: smtp.mail.com
Adres nadawcy przesylki: nadawca@yahoo.com
Adres adresata przesylki: odbiorca@mail.com
Uzyta konwencja:
K poprzedza komunikaty wyslane przez klienta.
S poprzedza komunikaty wyslane przez serwer.
Kolejne etapy oddzielam pusta linia, w rzeczywistosci nie stosuje
sie tego, chociaz mozna.
S: 220 smtp.mail.com ESMTP # Serwer sie przywital K: ehlo domena.com # my tez, jestesmy z domena.com S: 250-smtp.mail.com # Serwer przedstawia co obsluguje S: 250-STARTTLS # jw. S: 250-AUTH LOGIN PLAIN # jw. S: 250-AUTH=LOGIN PLAIN # jw. S: 250-PIPELINING # jw. S: 250 8BITTIME # jw. K: mail from: <nadawca@yahoo.com> # Okreslamy adres nadawcy S: 250 ok # Serwerowi to pasuje K: rcpt to: <odbiorca@mail.com> # Okreslamy adres adresata S: 250 ok # To tez mu pasuje K: data # Chcemy przeslac przesylke S: 354 go ahead # Serwer sie zgadza K: From: Stefan # Wysylamy naglowki SMTP K: To: Halinka # Nie musza istniec zadne, ale K: Subject: kasztany # zasadniczo te 3 sa najwazniejsze K: # Po naglowkach idzie tresc K: Kochana Halinko, # Ominalem tutaj MIME, kodowanie i K: # inne wynalazki, w prostym mailu to K: dziekuje Ci za kasztany. # nie takie potrzebne K: To tyle, papa. # K: Twoj Stefek. # K: . # . i enter oznacza koniec maila S: 250 ok 1096137870 qp 20251 # Serwer mowi, ze zakolejkowal K: quit # Zegnamy sie S: 221 smtp.mail.com # Serwer tez sie pozegnalCala transakcja zostala przeprowadzona przy uzyciu programu telnet, ktorym zalogowalem sie na port, na ktorym nasluchuje serwer SMTP. Jest to domyslnie port 25. Zatem: telnet smtp.mail.com 25
Niedokladnosci w tym przykladzie
- Podany przyklad podaje bardzo ubogie naglowki SMTP w przesylce. Pole From i To nawet nie zawieraja adresow email. W istocie naglowki sa bogatsze: zawieraja date, kodowanie, i inne pieczatki. Mimo to, taki mail musi dojsc. A to dlatego, ze to co jest potrzebne do samego transportu maila jest zawarte w tym co jest przed komenda data. To co jest po niej jest nie dla serwera przekazuajcego poczte, ale juz dla ostatecznego czytnika poczty.
- Przyklad nie ujawnia potencjalnych problemow jakie mozemy miec osobiscie gdybysmy go przeprowadzali: niektore serwery sprawdzaja wpisy revdns, inne revdns i korespondujace wpisy dns. Inne serwery sprawdza czy nadawca pasuje do rekordu SPF dla tej domeny, inne sprawdza czy w ogole przekazuja poczte dla danej domeny, inne sprawdza czy FQDN podany w ehlo jest rozwiazywalny, inne sprawdza czy zgadza sie z faktycznym FQDN nadawcy, itp...
