Sistemul de posta electronica

Sistemul de posta electronica

Introducere si scurt istoric

Posta electronica, sau e-mail, cum este ea cunoscuta de catre numerosii sai utilizatori, exista de peste trei decenii. Primul sistem de posta electronica consta din protocoale de transfer de fisiere, cu conventia ca prima linie a fiecarui mesaj (adica fisier) sa contina adresa receptorului. În timp, limitarile acestei abordari, relativ simpliste, au devenit din ce in ce mai evidente si incomode in utilizarea sistemului. Printre principalele neajunsuri ale acestei abordari pot fi amintite urmatoarele:

Expedierea unui mesaj catre un grup de persoane era complicata. Aceasta facilitate este frecventa utilizata in cadrul institutiilor si companiilor, necesitatea acestei facilitati fiind evidenta.

Neavand o structura bine definta interna, prelucrarea automata a mesajelor era dificila.

Expeditorul nu stia niciodata daca mesajul a ajuns sau nu la destinatie.

Interfata utilizator era slab integrata cu sistemul de transmisie, cerand utilizatorilor ca mai intai sa editeze un fisier, apoi sa paraseasca editorul si sa apeleze programul de transfer de fisiere.

Nu era posibila transmiterea de mesaje care sa contina combinatii de text, desene sau voce, sau orice alte tipuri de fisiere.

Ulterior au fost propuse sisteme de posta electronica mai complicate. În 1982 au fost publicate propunerile cu privire la e-mail ale ARPANET, sub numele de RFC821 (protocolul de transmisie) si RFC822 (formatul mesajelor). În prezent acestea au devenit standardele de facto utilizate in schimbul de mesaje electronice la nivelul Internetului. Desi au fost propuse mai multe standarde, cum ar fi de exemplu recomandare X.400 a CCITT, preluata de OSI pentru sistemul MOTIS, competitia si implementarile practice ale sistemelor de posta electronica au confirmat standardul definit de cele doua RFC-uri mentionate anterior. Motivul succesului lui RFC822 nu este dat de faptul ca ar fi deosebit de bun, ci datorita deficientelor de proiectare (complexitate crescuta) a sistemului X.400 astfel incat eventualele implementari ale acestui standard ar fi greoaie.

                    Serviciile sistemului de posta electronica

Aceste sisteme constau de obicei din doua subsisteme:

         Mail User Agent - MUA - agentii-utilizator, reprezentand programe care permit utilizatorilor sa citeasca si sa trimita scrisori prin posta electronica

         Mail Transfer Agent - MTA - agentii de transfer de mesaje, care transporta mesajele de la sursa la destinatie.

Agentii-utilizator sunt de cele mai multe ori programe locale, care furnizeaza o metoda de a interactiona cu sistemul de e-mail pe baza unor comenzi, meniuri sau printr-o interfata grafica specializata. Agentii de transfer de mesaje sunt, in mod tipic, demoni de sistem (programe care se executa la nivel de servicii), care se executa in fundal si transfera mesajele prin sistem.

Privind in general activitatea de transmitere, vehiculare si receptionare a unui mesaj electronic, sistemele de posta electronica furnizeaza cinci functii principale de baza, dupa cum urmeaza:

Compunerea - se refera la procesul de creare a mesajelor si a raspunsurilor. Desi pentru corpul mesajului poate fi folosit orice editor de texte, sistemul insusi poate acorda asistenta la adresare si la completarea numeroaselor campuri antet atasate fiecarui mesaj. De exemplu, cand se raspunde la un mesaj, sistemul poate extrage adresa initiatorului din mesajul primit si o poate insera automat in locul potrivit din cadrul raspunsului.

Transferul - se refera la vehicularea mesajului de la autor la receptor. În linii mari, aceasta necesita stabilirea unei conexiuni la destinatie, sau la o masina intermediara, emiterea mesajului si eliberarea conexiunii. Sistemul de posta ar trebui sa faca acest lucru singur, fara a fi necesara interventia utilizatorului.

Raportarea - se refera la informarea initiatorului despre ce s-a intamplat cu mesajul, de exemplu daca aceasta a ajuns sau nu la destinatie sau daca au aparut intarzieri in livrarea lui.

Afisarea mesajelor primite este necesara pentru ca utilizatorii sa-si poata citi mesajele receptionate. În anumite cazuri apare necesitatea unor conversii sau trebuiesc apelate programe de vizualizare speciala, de exemplu daca mesajul este criptat pentru securizarea informatiilor sau informatiile continute nu sunt in format text lizibil, ci imagine sau sunet.

Dispozitia este pasul final al cursului unui mesaj electronic si se refera la ceea ce face receptorul cu mesajul, dupa ce a fost receptionat. Posibilitatile includ eliminarea sa inainte de a-l citi, eliminarea sa dupa citire, salvarea sa s.a.m.d. Ar trebui de asemenea sa fie posibila regasirea si recitirea de mesaje deja salvate, trimiterea lor mai departe, sau procesarea lor in alte moduri.

În plus fata de serviciile de baza mentionate anterior, majoritatea sistemelor de e-mail dispun de o gama variata de trasaturi avansate. În continuare sunt mentionate cateva dintre ele. Cand utilizatorii se deplaseaza sau cand sunt plecati pentru o perioada de timp, pot dori ca posta lor sa fie trimisa acolo unde se gasesc, asa ca sistemul ar trebui sa fie capabil sa faca acest lucru automat, aceasta numindu-se redirectarea mesajelor. Majoritatea sistemelor permit utilizatorilor sa-si creeze cutii postale (mailboxes) pentru a pastra mesajele sosite, cat si cele trimise. Sunt necesare comenzi de creare si distrugere a cutiilor postale, de inspectare a continutului acestora, de inserare si de stergere de mesaje din cutii postale s.a.m.d.

Este adesea nevoie sa fie trimis un acelasi mesaj mai multor persoane. Acest lucru da nastere ideii de lista de posta (mailing list), care este o lista de adrese de posta electronica. Cand un mesaj este trimis la lista de posta, copii identice ale sale sunt expediate fiecaruia dintre cei de pe lista.

O alta idee importanta este cea de inregistrare a mesajelor, pentru a permite initiatorului sa stie daca mesajul sau a ajuns. Alternativ, se poate dori notificarea automata a mesajelor care nu pot fi livrate. În orice caz, initiatorul ar trebui sa aiba un oarecare control asupra raportarii a ceea ce s-a intamplat.

Alte caracteristici evoluate sunt copii la indigo ale mesajelor expediate altor persoane, posta de prioritate mare, posta secreta (criptata), receptori alternativi, daca cel primar nu este disponibil.

Conceptul care sta la baza tuturor sistemelor moderne de e-mail este distinctia dintre plic si continutul sau. Plicul incapsuleaza mesajul. Contine toata informatia necesara pentru transportul mesajului, cum ar fi destinatia, adresa, prioritatea, nivelul de securitate, toate acestea fiind distincte de mesajul in sine. Agentii de transfer de mesaje folosesc plicul pentru rutare (dirijare), asa cum face si un oficiu postal clasic.

Mesajul din interiorul plicului contine doua parti: antetul si corpul. Antetul contine informatie de control pentru agentii utilizator. Corpul mesajului se adreseaza  in intregime utilizatorului uman.

           Agentul utilizator

Sistemele de posta electronica au doua parti esentiale: agentii-utilizator si agentii de transfer de mesaje. Un agent utilizator este de obicei un program (uneori numit cititor de posta sau client de posta electronica) care accepta o varietate de comenzi pentru compunerea, primirea si raspunsul la mesaje, cat si pentru manipularea cutiilor postale. Unii agenti-utilizator au o interfata grafica sofisticata, dirijata prin meniuri sau icoane, in timp ce altele accepta comenzi de cate un caracter, date de la tastatura. Functional insa, toti clientii de posta electronica utilizati trebuie sa fie similari. Clienti de e-mail pot fi asadar programe independente care ruleaza pe calculatorul utilizatorului iar cele mai comune exemple sunt: MS Outlook, Netscape Messenger, Qualcomm Eudora, Mozilla Thunderbird, etc. sau programe gazduite de un server web cu suport pentru aplicatii, comun numite "webmail".

                    Formatele mesajelor

Sistemul e-mail ASCII de baza utilizeaza RFC 822. În cadrul acestui sistem mesajele constau dintr-un plic simplu (descris in RFC 821), un numar de campuri antet, o linie goala si apoi corpul mesajului. Fiecare camp antet se compune (din punct de vedere logic) dintr-o singura linie de text ASCII, continand numele campului, o virgula si, pentru majoritatea campurilor, o valoare. RFC 822 este un standard vechi si nu distinge clar plicul de campurile antet, cum ar face un standard nou. La o utilizare normala, agentul-utilizator construieste un mesaj si il transmite agentului de transfer de mesaje, care apoi foloseste unele dintre campurile antet pentru a construi plicul efectiv, o combinatie de mesaj si plic.

Principalele campuri antet, legate de transportul de mesaje, sunt descrise in tabelul de mai jos.

Campul To: ofera adresa DNS a receptorului primar. Este permisa de asemenea existenta de receptori multipli.

Campul Cc: da adresa oricarui receptor secundar. În termenii livrarii, nu este nici o diferenta intre un receptor primar si unul secundar. Este in intregime o deosebire psihologica, ce poate fi importanta pentru persoanele implicate, dar este neimportanta pentru sistemul de posta. Termenul Cc.: (Carbon copy - copie la indigo) este putin depasit, din moment ce calculatoarele nu folosesc indigo, dar este bine inradacinat.

Campul Bcc: (Blind carbon copy - copie confidentiala la indigo) este la fel ca si Cc:, cu exceptia ca aceasta linie este stearsa din toate copiile trimise la receptorii primari si secundari. Acest element permite utilizatorilor sa trimita copii unei a treia categorii de receptori, fara ca receptorii primari si secundari sa stie acest lucru.

Campurile From si Sender precizeaza cine a scris si respectiv cine a trimis mesajul. Acestea pot sa nu fie identice. De exemplu, se poate ca un director executiv sa scrie un mesaj, dar ca secretara lui sa fie cea care il trimite efectiv. În acest caz, directorul executiv va fi afisat in campul From si secretara in campul Sender. Campul From este obligatoriu, dar campul Sender poate fi omis daca este identic cu From. Aceste campuri sunt necesare in cazul in care mesajul nu poate fi livrat si trebuie returnat transmitatorului.

Campul Received contine informatii care sunt adaugate de fiecare agent de transfer de mesaje de pe traseu. Linia contine identitatea agentului, data si momentul de timp la care a lost primit mesajul si alte informatii care pot fi utilizate pentru gasirea problemelor in sistemul de dirijare sau pentru analiza caii urmate de un mesaj de la sursa pana la destinatar.

Campul Return-Path este adaugat de agentul final de transfer de mesaje si are ca scop sa indice cum se ajunge inapoi la transmitator. În teorie, aceasta informatie poate fi adunata din toate antetele Received. (cu exceptia numelui cutiei postale a transmitatorului), dar rareori este completata astfel si de obicei contine chiar adresa transmitatorului.

În plus fata de campurile mentionate anterior, mesajele RFC 822 pot contine de asemenea o varietate de campuri antet, folosite de agentii-utilizator sau de receptorii umani.

Campul Reply-To este uneori utilizat cand nici persoana care a compus mesajul, nici cea care l-a trimis nu vrea sa vada raspunsul. De exernplu, un director de marketing scrie un mesaj prin e-mail pentru a spune clientilor despre un nou produs. Mesajul este trimis de o secretara, dar campul Reply­-To contine lista sefilor departamentelor de vanzari, care pot raspunde la intrebari si pot primi comenzi.

RFC 822 precizeaza ca lista antetelor poate fi extinsa de catre orice utilizator, creandu-si propriul antet. Este mandatoriu ca aceste antete personalizate sa inceapa cu litera X pentru a face distinctia intre antetele necesare sistemului de posta electronica si cele care sunt utilizate in scopuri personale.

Un bun exemplu pentru aceste antete este utilizarea lor in cadrul sistemelor de detectie automata a mesajelor nedorite, numite spam. Exista multe metode de a detecta aceste mesaje folosind proceduri inteligente iar aceasta detectie poate inteveni in mai multe locuri pe parcursul unui mesaj, de la expeditor la destinatar. Mesajele pot fi marcate ca "spam" cu ajutorul unui antet, de exemplu X-spam-flag pe baza caruia un agent de transfer de mesaje poate lua decizia de nu trimite mai departe acel mesaj sau un agent utilizator poate directiona mesajul respectiv spre o casuta postala special destinata acestui scop (de a primi mesajele marcate ca fiind nedorite). Acelasi sistem poate fi implementat si pentru marcarea si apoi filtrarea mesajelor care contin virusi care se raspandesc via sistemul de posta electronica.

MIME - Multipurpose Internet Mail Extensions (extensii de posta cu scop multiplu)

La inceputurile ARPANET, posta electronica consta exclusiv din mesaje de tip text, scrise in engleza si exprimate in ASCII. Pentru acest context, RFC 822 realiza sarcina complet: specifica antetele, dar continutul este lasat in intregime pe seama utilizatorilor. În zilele noastre, aceasta abordare nu mai este adecvata pentru Internetul care se intinde in lumea intreaga si permite vehicularea informatiilor celor mai diverse. Problemele includ transmisia si receptia de mesaje in limbi cu accente (de exemplu franceza si germana), mesaje in alfabete ne-latine (de exemplu ebraica si rusa), mesaje in limbi fara alfabet (de exemplu chineza si japoneza), mesaje care nu contin deloc text (de exemplu audio si video).

O solutie posibila a fost propusa in RFC 1341 si actualizata in RFC 1521. Aceasta solutie, numita MIME (Multipurpose Internet Mail Extensions), este in prezent larg utilizata. Ideea fundamentala a MIME este sa continue sa foloseasca formatul RFC 822, dar sa adauge o structura corpului mesajului si sa defineasca reguli de codificare pentru mesajele non-ASCII. Deoarece respecta RFC 822, mesajele MIME pot fi trimise utilizand programele si protocoalele de posta electronica existente.

MIME defineste cinci noi antete de mesaje, ilustrate in tabelul de mai jos. Primul dintre acestea specifica pur si simplu agentului-utilizator care primeste mesajul ca este vorba de un mesaj MIME si ce versiune de MIME utilizeaza. Orice mesaj care nu contine un antet MIME-Version este presupus ca fiind un mesaj in text pur, in engleza, si este procesat ca atare. Antetele specifice MIME sunt prezentate in tabelul de mai jos.

Antetul Content-Description este un sir de caractere ASCII specificand ce este in mesaj. Acest antet este necesar pentru ca receptorul sa stie daca merita sa decodifice si sa citeasca mesajul.

    Antetul Content-Id identifica continutul. Utilizeaza acelasi format ca anetul standard Message-Id.

Antetul Content-Transfer-Encoding arata cum este impachetat pentru transmisie corpul mesajului, intr-o retea care poate ridica obiectii la majoritatea caracterelor diferite de litere, cifre si semne de punctuatie. Sunt furnizate cinci scheme de codificare. Cea mai simpla schema se refera chiar la textul ASCII. Caracterele ASCII utilizeaza 7 biti si pot fi transportate direct prin protocolul de e-mail, atat timp cat nici o linie nu are mai mult de 1000 de caractere. Urmatoarea schema ca simplitate este cam acelasi lucru, dar utilizeaza caractere de cate 8 biti, reprezentand toate valorile de la 0 la 255 inclusiv. Aceasta schema de codificare incalca protocolui (original) de e-mail utilizat in Internet, dar este folosita de unele parti ale Internetului, care implementeaza niste extensii ale protocolului original. În timp ce declararea codificarii nu o face sa devina legala, faptul ca o avem explicita poate cel putin sa lamureasca lucrurile atunci cand ceva merge prost. Mesajele utilizand codificarea de 8 biti trebuie inca sa respecte lungimea maxima a liniei, care este standard.

Este chiar mai rau in cazul mesajelor care utilizeaza codificarea binara. Aceste mesaje sunt fisiere binare arbitrare, care nu numai ca utilizeaza toti cei 8 biti, dar nu respecta nici limita de llnie de 1000 de caractere. Programele executabile de exemplu intra in aceasta categorie. Nu se acorda nici o garantie ca mesaje binare vor ajunge corect, dar multi le trimit oricum.

Modalitatea corecta de a codifica mesaje binare este de a utiliza codificarea in baza 64, numita uneori armura ASCII. În aceasta schema, grupuri de cate 24 de biti sunt impartite in patru unitati de cate 6 biti, fiecare dintre aceste unitati fiind transmisa ca un caracter ASCII legal. Codificarea este ,A' pentru 0, ,B' pentru 1, s.a.m.d.; urmate de cele 26 de litere mici, cele 10 cifre, si in cele din urma + si / pentru 62 si respectiv 63. Secventele == si = sunt utilizate pentru a arata ca ultimul grup a continut doar 8 sau respectiv 16 biti. Se ignora secventele carriage return si line feed, astfel ca ele pot fi inserate dupa dorinta, pentru a pastra liniile suficient de scurte. Utilizand aceasta schema pot fi trimise sigur fisiere binare arbitrare.

Pentru mesajele care sunt aproape in intregime ASCII si contin putine caractere ne-ASCII, codificarea in baza 64 este oarecum ineficienta. În locul acesteia se utilizeaza o codificare numita quoted-printable-encoding (codificare afisabila marcata). Aceasta este o codificare de tip ASCII de 7 biti, avand toate caracterele cu cod mai mare de 127 codificate sub forma unui semn egal urmat de valoarea caracterului reprezentata prin doua cifre hexazecimale. Rezumand, datele binare ar trebui trimise codificate in baza 64 sau sub forma quoted-printable. Cand exista motive intemeiate pentru a nu utiliza una dintre aceste scheme, este posibil sa se specifice in antetul Content-Transfer-Encoding o codificare definita de catre utilizator.

Ultimul antet este cu adevarat cel mai interesant. El specifica natura corpului mesajului. În RFC 1521 sunt definite sapte tipuri, fiecare avand unul sau mai multe subtipuri. Tipul si subtipul sunt separate prin caracterul "/" slash, ca de exemplu Content-Type: video/mpeg. Tabelul de mai jos ilustreaza cateva exemple din aceasta categorie.

Subtipul trebuie precizat explicit in antet, nu sunt furnizate valori implicite. Lista initiala de tipuri si subtipuri specificate in RFC 1521 este prezentata in tabelul anterior, insa de atunci au fost adaugate multe altele, introducandu-se intrari aditionale de fiecare data cand a fost necesar.

           Transfer de mesaje

          Sistemul de transfer de mesaje se ocupa de vehicularea mesajelor primite de la  agentul utilizator al expeditorului pana la livrarea finala catre agentul utilizator al destinatarului. Vehciularea mesajelor se face prin intermediul agentilor de transfer de mesaje si acestia pot fi mai multi in calea de transfer.

SMTP-Simple Mail Transfer Protocol (protocol simplu de transfer de posta)

În cadrul lnternetului posta electronica este livrata prin stabilirea de catre masina sursa a unei conexiuni TCP la portul 25 al masinii destinatie. Întreaga conversatie dusa de cele doua procese se desfasoara conform protocolului SMTP, special specificat in acest sens. Aceasta inseamna ca agentii de transfer se comporta fie ca un client, fie ca si server, postura lor depinzand de sensul in care are loc transmiterea mesajului. Acesti agenti sunt cel mai frecvent demoni, servicii instalate pe un sistem considerat server.

SMTP este un protocol simplu de tip ASCII. Dupa stabilirea conexiunii TCP la portul 25, masina transmitatoare, operand in calitate de client, asteapta ca masina receptoare, operand ca server, sa vorbeasca prima. Serverul incepe prin a trimite o linie de text, declarandu-si identitatea si spunand daca este pregatit sau nu sa primeasca mesaje. Daca nu este, clientii elibereaza conexiunea si incearca din nou mai tarziu, dupa o asteptare predefinita.

Daca serverul este dispus sa primeasca e-mail, clientul anunta de la cine vine mesajul si cui ii este adresat. Daca un asemenea receptor exista la destinatie, sau serverul deserveste la primire si domeniul DNS din care face parte destinatarul, serverul ii acorda clientului permisiunea sa trimita mesajul. Apoi clientul trimite mesajul si serverul il confirma. În general nu este necesara atasarea unei sume de control deoarece TCP furnizeaza un flux sigur de octeti. Daca mai exista si alte mesaje, acestea sunt trimise tot acum. Cand schimbul de mesaje, in ambele directii, s-a incheiat, conexiunea este eliberata.

Chiar daca protocolul SMTP este bine definit (de RFC 821), mai pot aparea cateva probleme. O problema este legata de lungimea mesajelor. Unele implementari mai vechi nu pot sa lucreze cu mesaje mai mari de 64KB. O alta problema se refera la expirari de timp (timeout). Daca acestea difera pentru server si client, unul din ei poate renunta in timp ce celalalt este inca ocupat, intrerupand conexiunea in mod neasteptat. În sfarsit, in rare situatii, pot fi lansate schimburi infinite de mesaje. De exemplu, daca masina 1 pastreaza lista de posta A si masina 2 lista de posta B si fiecare lista contine o intrare pentru cealalta, atunci orice mesaj trimis oricareia dintre cele doua liste va genera o cantitate nesfarsita de trafic de e-mail.

Pentru a rezolva unele din aceste probleme, in RFC 1425 s-a definit protocolul SMTP extins (ESMTP). Clientii care doresc sa-l utiiizeze trebuie sa trimita initial un mesaj EHLO in loc de HELO, de exemplu pentru inceputul conversatiei. Daca acesta este rejectat, atunci serverul este unul standard de tip SMTP si clientul va trebui sa procedeze in mod obisnuit. Daca EHLO este acceptat, inseamna ca sunt permise noile comenzi si noii parametri.

Posta electronica utilizand SMTP lucreaza cel mai bine cand atat transmitatorul cat si receptorul se gasesc in Internet si pot accepta conexiuni TCP intre transmitator si receptor. Cu toate acestea, multe masini care nu sunt in Internet doresc sa trimita si sa primeasca mesaje de la alte sisteme aflate in Internet. Unele institutii sau companii isi protejeaza total reteaua proprie de accesele din Internet. O alta problema poate sa apara in momentul in care se doreste vehicularea unui mesaj intre doua sistem de posta electronica diferite ca si standard, de exemplu expeditorul este conform RFC 822 iar receptorul X.400.

Aceste probleme sunt rezolvate prin utilizarea portilor de e-mail de la nivelul aplicatie. În figura de mai jos gazda 1 intelege doar TCP/IP si RFC 822, in timp ce gazda 2 stie doar OSI TP4 si X.400. Cu toate acestea ele pot schimba mesaje utilizand o poarta de e-mail. Procedura este ca gazda 1 sa stabileasca o conexiune de TCP cu poarta si apoi sa transfere acolo un mesaj (1) utilizand SMTP. Demonul portii pune apoi mesajul intr-un tampon de mesaje destinate gazdei 2. Ulterior se stabileste o conexiune de TP4 (echivalentul OSI pentru TCP) cu gazda 2 si se transfera mesajul (2), folosind echivalentul OSI pentru SMTP. Tot ce are de facut procesul de tip poarta este sa extraga mesajele sosite dintr-o coada si sa le puna in

alta.

              Livrarea finala

Agentii de transfer de mesaje finali, ultimii din calea de vehiculare a unui mesaje sunt cei care depoziteaza mesajul primit intr-o cutie postala, specifica destinatarului. De cele mai multe ori, o cutie postala reprezinta un fisier sau o structura  de fisiere pe discul unui sistem sau inregistrari intr-o baza de date. Operatia prin care un agent de transfer plaseaza mesajul in cutia postala se numeste livrare locala. În continuare, agentii utilizator trebuie sa consulte cutia postala pentru a recupera mesajul primit in vederea prelucrarii acestuia spre afisare destinatarului.

Un protocol simplu, utilizat pentru aducerea mesajelor dintr-o cutie postala aflata la distanta, este POP3 (Post Office Protocol - protocol de posta) si este definit in RFC 1225. Poseda comenzi pentru conectarea si deconectarea utilizatorilor, aducerea si stergerea mesajelor. Scopul lui POP3 este sa aduca e-mail de la distanta si sa-l depoziteze pe masina locala a utilizatorului, spre a fi citit mai tarziu.

IMAP (Interactive Mail Access Protocol - protocol interactiv de acces la posta) este un protocol de livrare mai sofisticat, definit in RFC 1064. A fost proiectat pentru a ajuta utilizatorii care folosesc mai multe calculatoare, ca de exemplu o statie de lucru la birou, un PC acasa si un calculator portabil pe drum. Ideea de baza aflata in spatele IMAP este ca serverul de e-mail sa pastreze un depozit central de mesaje la care accesul sa poata fi realizat de pe oricare masina. Astfel, spre deosebire de POP3, IMAP nu copiaza e-mailul pe masina personala a utilizatorului, deoarece acesta poate avea mai multe. IMAP prezinta si alte numeroase facilitati cum ar fi posibilitatea indexarii mesajelor primite, cautarea mesajelor, organizarea cutiei postale intr-o structura arborescenta (gestiune de directoare), lucruri pe care de exemplu POP3 nu le permite.

Un al treilea protocol de livrare este DMSP (Distributed Mail System Protocol - protocol distribuit pentru sistemul de posta), parte a sistemului PCMAIL, descris in RFC 1056. Acesta nu presupune ca tot e-mailul se afla la nivelul unui singur server, ca la POP si IMAP. În schimb, permite utilizatorilor sa descarce e-mailul de la sever la o statie de lucru, PC sau portabil, si apoi sa se deconecteze. Utilizatorul poate citi mesajele si scrie raspunsurile cat timp este deconectat de la server. Ulterior, cand se reconecteaza, posta este retransferata si sistemul este resincronizat.

          Structura generala a unui sistem de posta electronica

Luand in considerare toate aspectele parcurse pana in acest punct, se poate schita o diagrama care sa prezinte structura globala a unui sistem de posta electronica.

Descriere a functionarii

Expeditorul interactioneaza cu agentul de transfer de pe statia de lucru proprie pentru trimiterea unui mesaj electronic. Acest agent (MUA), programul, preia meajul, il formateaza conform standardelor prin construirea si adaugarea antetelor si prin codificarea MIME a informatiilor non ASCII, daca acest lucru este necesar. Mesajul este mai departe trimis prin SMTP agentului de transfer local (MTA-ul din reteaua in care se afla utilizatorul) spre a fi expediat. Acest agent realizeaza interogarile DNS necesare identificarii sistemului catre care se va face expedierea. Dupa rezolvarea acestor interogari, MTA-ul local deschide o conexiune SMTP catre agentul de transfer de la distanta si incearca expedierea mesajului, incapsuland mesajul primit de la agentul utilizator intr-un plic specific mesajului prin construirea antetelor necesare. Agentul MTA distant preia acest mesaj si printr-o operatie de livrare locala plaseaza mesajul primit in cutia postala a destinatarului, dupa ce sunt extrase informatiile specifice agentului de transfer (sunt inlaturate antetele referitoare la plicul mesajului). În momentul in care destinatarul isi va accesa programul agent utilizator propriu, prin intermediul protocoalelor POP3 sau IMAP, vor fi recuperate mesajele primite din cutia postala, inclusiv mesajul caruia i-a fost ilustrat drumul mai sus. Astfel, destinatarul va putea citi acest mesaj, dupa ce agentul utilizator va extrage informatiile de antet si va decodifica informatiile codate MIME, daca acestea exista.

Daca destinatarul dispune si de un sistem webmail destinat utilizarii sistemului de posta electronica, acesta va putea trimite mesaje via SMTP prin MTA-ul configurat si va putea inspecta continutul cutiei postale proprii prin POP3 sau IMAP, in functie de capabilitatile sistemului webmail pe partea de client de posta electronica.