POP3

De la Wikipedia, enciclopedia liberă
Salt la: Navigare, căutare

POP3 sau Protocolul Post Office – Versiunea 3 este, alături de IMAP, unul din protocoalele utilizate de un calculator gazdă pentru recepționarea poștei electronice (e-mail).

Cu siguranță, tipurile nodurilor mai mici în Internet deseori nu sunt practice să întrețină un sistem de transport al mesajului (MTS). De exemplu, o stație de lucru este posibil să nu dispună de suficiente resurse (spațiu pe disc) cu scopul de a permite un server SMTP RFC 821 și asociază un sistem local de trimitere mail pentru a fi ținut rezident și să ruleze continuu. Similar, poate deveni costisitor (sau imposibil) să menții un computer interconectat la un IP-style rețea pentru o perioadă mai mare de timp (nodul duce lipsă de resursa cunoscută ca “conectivitate”). În ciuda acestora, deseori este foarte util să deservești poșta acestor noduri mai mici și deseori sprijină un utilizator agent (UA) să ajute la manipularea poștei electronice. Pentru a rezolva această problemă, un nod care întreține o entitate MTS oferă un serviciu maildrop pentru aceste noduri înzestrate mai puțin. POP3 a intenționat să permită unei stații de lucru acces dinamic la maildrop de pe un server gazdă într-un mod util. De obicei, aceasta înseamnă că protocolul POP3 este utilizat pentru a permite unei stații de lucru să primească poșta pe care serverul o stochează. POP3 nu a intenționat să furnizeze operații extinse de manipulare a poștei de pe server; normal poșta este descărcată de pe server și apoi ștearsă. Un protocol mai avansat (și mai complex), IMAP4, a fost discutat în RFC 1730. În continuare, termenul “client gazdă” (client host) se referă la o gazdă ce utilizează serviciul POP3, cât timp termenul “server gazdă” (server host) se referă la o gazdă care oferă serviciul POP3.

Operația de bază[modificare | modificare sursă]

Inițial, serverul pornește serviciul POP3 ascultând TCP portul 110. Când clientul dorește să utilizeze serviciul, este stabilită o conexiune TCP cu serverul. Când conexiunea s-a realizat, serverul POP3 trimite un salut. Clientul și serverul POP3 schimbă comenzi și răspunsuri până când conexiunea este închisă sau abandonată. Comenzile în POP3 sunt formate din caractere (modul insenzitiv), posibil să fie urmate de unul sau mai multe argumente. Toate comenzile sunt termintate prin perechea CRLF (\r\n). Șirul de caractere ce formează comanda și argumentele sunt caractere ASCII. Comenzile și argumentele sunt separate printr-un singur caracter SPACE. Comenzile au lungimea de 3 sau 4 caractere. Fiecare argument poate avea lungimea până la maxim 40 de caractere. Răspunsurile în POP3 constau dintr-un indicator de status și o comandă, posibil urmată de informații adiționale. Toate răspunsurile sunt terminate prin perechea CRLF. Răspunsurile pot fi de lungime de până la 512 caractere, incluzând și CRLF. În mod curent, sunt doi indicatori de status: pozitv (“+OK”) și negativ (“-ERR”). Serverul trebuie să trimită “+OK” și “-ERR” scrise cu litere mari (upper case). Răspunsurile la comenzi sunt multi-linie. În aceste cazuri, care sunt clar indicate mai jos, după trimiterea primei linii a răspunsului și a perechii CRLF , orice linie adițională este trimisă și fiecare linie se termină cu perechea CRLF. Când toate liniile răspunsului au fost trimise, este trimisă o linie finală, care formează un octet terminal (cod zecimal 046, “.”) și perechea CRLF. Dacă orice linie a răspunsului multi-linie începe cu acest octet terminal, linia este completată cu octeți terminali. Deci, un răspuns multi-linie se termină cu 5 octeți “CRLF.CRLF”. Când examinează un răspuns multi-linie, clientul verifică să vadă dacă linia începe cu octetul terminal. Dacă da și ceilalți octeți sunt CRLF, primul octet al liniei (octetul terminal) este scos. Dacă da și dacă CRLF urmează imediat caracterul terminal, atunci răspunsul de la serverul POP3 este terminat și linia ce conține “.CRLF” nu este considerată parte a răspunsului multi-linie. O sesiune POP3 evoluează direct printr-un număr de stări în timpul vieții ei. O dată ce conexiunea TCP a fost deschisă și severul POP3 a trimis salutul, sesiunea întră în stare de AUTHORIZATION. În această stare, clientul trebuie să se identifice serverului POP3. O dată ce clientul a făcut acest lucru cu succes, serverul își formează resursele asociate în funcție de maildrop-ul clientului, și sesiunea întră în starea de TRANSACTION. În această stare, clientul cere acțiuni serverului POP3. Când clientul a emis comanda QUIT, sesiunea întră în starea de UPDATE. În această stare, serverul POP3 eliberează orice resursă dobândită în timpul stării de TRANSACTION și spune “goodbye”. Apoi conexiunea TCP este închisă. Serverul trebuie să răspundă la o nerecunoaștere, neimplementare sau o comandă invalidă printr-un indicator de stare negativ. Serverul trebuie să răspundă unei comenzi cerute când sesiunea este într-o stare incorectă, printr-un indicator de stare negativ. Nu există o metodă generală pentru un client care să distingă un server ce nu are implementată o comandă opțională, de un server care nu dorește sau nu poate să proceseze o comandă. Un server POP3 poate avea timp de inactivitate (autologout). Ca timp trebuie să fie cel puțin 10 minute. Primirea oricărei comenzi de la client în timpul acelui interval, este de ajuns să reseteze “autologout timer”. Când timpul expiră, sesiunea nu poate intra în starea de UPDATE – serverul ar trebui să închidă conexiunea TCP fără a șterge nici un mesaj sau fără a trimite vreun răspuns clientului.

Starea AUTHORIZATION[modificare | modificare sursă]

O dată ce conexiunea TCP a fost deschisă de un client POP3, serverul POP3 emite o linie de salut. Acesta poate fi orice răspuns pozitiv. Un exemplu poate fi:

S: +OK POP3 server ready 

Sesiunea POP3 este acum în starea de AUTHORIZATION. Clientul trebuie acum să se identifice și să se autentifice serverului POP3. Două mecanisme posibile pentru aceasta sunt descrise în acest document, combinația comenzilor USER și PASS și comanda APOP. Ambele mecanisme sunt descrise în acest document. Mecanisme suplimenatare de autentificare sunt descrise în RFC 1734. Cât timp există mai multe mecansime de autentificare acestea sunt cerute de toate serverele POP3, un server POP3 trebuie să suporte, bineînțeles, cel puțin unul din aceste mecanisme. O dată ce serverul POP3 a fost determinat complet, utilizarea oricărei comenzi de autentificare a clientului, ar trebui să-i dea acces la maildrop-ul potrivit; serverul POP3 dobândește acces exclusiv pentru blocarea maildrop-ului, fiind necesară prevenirea modificării și ștergerii mesajelor înainte ca sesiunea să intre în starea UPDATE. Dacă blocajul este dobândit cu succes, serverul POP3 răspunde cu un indicator de stare pozitiv. Sesiunea POP3 intră acum în starea TRANSACTION, cu nici un mesaj marcat pentru ștergere. Dacă maildrop-ul nu a putut fi deschis din diferite motive (ex. blocajul nu a putut fi realizat, clientul nu are acces la maildrop, sau maildrop-ul nu poate fi citit), serverul POP3 răspunde cu un indicator de stare negativ. (Dacă s-a realizat blocajul și serverul POP3 intenționează să răspundă cu un indicator de stare negativ, atunci el trebuie să se deblocheze înainte de respingerea comenzii). După returnarea negativă a indicatorului de stare, serverul poate închide conexiunea. Dacă serverul nu închide conexiunea, clientul poate emite fie o nouă comandă de autenficare și să pornească din nou, fie poate emite comanda QUIT. După ce serverul POP3 a deschis maildrop-ul, este asociat un număr fiecărui mesaj și se notează mărimea fiecărui mesaj în octeți. Primului mesaj din maildrop îi este asociat numărul de mesaj “1”, celui de-al doilea “2” și așa mai departe, astfel încât celui de-al n-lea mesaj îi este asociat numărul de mesaj “n”. În POP3 comenzile și răspunsurile, toate numerele de mesaje și mărimea mesajelor sunt exprimate în baza 10 (decimal). Iată un rezumat al comenzii QUIT în starea AUTHORIZATION:

QUIT

Argumente: nici unul

Restricții: nici una

Răspunsuri posibile:

+OK

Exemple:

C: QUIT
S: +OK dewey POP3 server signing off

Starea TRANSACTION[modificare | modificare sursă]

O dată ce clientul s-a identificat cu succes serverului POP3 și serverul POP3 a fost blocat și a deschis maildrop-ul corespunzător, sesiunea POP3 este acum în starea de TRANSACTION. Clientul poate emite în acest moment oricare dintre următoarele comenzi POP3, în mod repetat. Eventual, clientul emite comanda QUIT și sesiunea POP3 intră în starea de UPDATE.

STAT[modificare | modificare sursă]

STAT

Argumente: nici unul

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Serverul POP3 emite un răspuns pozitiv într-o linie care conține informații pentru maildrop. Această linie este numită “drop listing” pentru acea casuță poștală.Cu scopul de a simplifica analiza, toate serverele POP3 au nevoie să utilizeze un format sigur pentru “drop listing”-s. Răspunsul pozitiv constă din “+OK” urmat de un singur spațiu, numărul de mesaje din maildrop, un singur spațiu, mărimea maildrop-ului în octeți. Acest memo nu determină nici o condiție ce urmează după mărimea maildrop-ului. Implementările minimale ar trebui doar să sfârșească linia de răspuns cu lități opționale ce permit clientului analiza mesajelor din maildrop sunt discutate mai târziu. De observat că acele mesaje marcate pentru ștergere nu sunt numărate în total.

Răspunsuri posibile:

+OK nn mm

Exemple:

C: STAT
S: +OK 2 320

LIST[modificare | modificare sursă]

LIST [msg]

Argumente: Un număr de mesaj (opțional), care, dacă este prezent, nu poate să se refere la un mesaj marcat pentru ștergere.

Restricții: Pot fi date doar în starea TRANSACTION

Comentariu: Dacă a fost dat un argument, serverul POP3 emite un răspuns pozitiv cu o linie ce conține informații pentru acel mesaj. Această linie este numită “scan listing” pentru mesajul respectiv. Dacă nici un argument nu a fost dat, serverul POP3 emite un răspuns pozitiv, atunci răspunsul dat este multi-linie. După +OK inițial, pentru fiecare mesaj din maildrop, serverul POP3 răspunde cu o linie ce conține informații despre acel mesaj. Această linie mai este numită “scan listing” pentru acel mesaj. Dacă nu sunt mesaje în maildrop, atunci serverul POP3 răspunde fără “scan listings” – emite un răspuns pozitiv urmat de o linie conținând octetul terminal și perechea CRLF. În scopul simplificării analizei, toate serverele POP3 sunt condiționate să utilizeze un format sigur pentru “scan listings”. Un “scan listing” conține numărul de mesaj al mesajului, urmat de un singur spațiu și mărimea exactă a mesajului în octeți. Metode pentru calcularea exactă a mărimii mesajului sunt descrise în secțiunea Formatul Mesajului. Acest memo nu determină nici o condiție referitoare la ce urmează după mărimea mesajului în “scan listig”. Implementările minimale ar trebui să termine acea linie de răspuns cu perechea CRLF. Implementările mai avansate pot include și alte informații, în urma analizei mesajului. Notă: Acest memo descurajează puternic implementările ce furnizează informații suplimentare în “scan listing”. Alte facilitați opționale ce permit clientului să analizeze mesajele din maildrop sunt discutate mai târziu. De observat că mesajele marcate pentru ștergere nu sunt listate.

Răspunsuri posibile:

+OK scan listing follows
-ERR no such message

Exemple:

C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .

C: LIST 2
S: +OK 2 200

C: LIST 3
S: -ERR no such message, only 2 messages În maildrop

RETR[modificare | modificare sursă]

RETR msg

Argumente: Un număr de mesaj (obligatoriu) ce nu se referă la un mesaj marcat pentru ștergere.

Restricții: Poate fi dată doar în faza de TRANSACTION

Comentariu: Dacă serverul POP3 emite un răspuns pozitiv, atunci răspunsul dat este multi-linie. După +OK ințial, serverul POP3 trimite mesajul corespunzator numărului de mesaj, fiind atent la completarea caracterului terminal.

Răspunsuri posibile:

+OK urmat de mesaj
-ERR no such mesaj

Exemple:

C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .

DELE[modificare | modificare sursă]

DELE msg

Argumente: Un număr de mesaj (obligatoriu) care nu poate să se refere la un mesaj marcat pentru ștergere.

Restricții: Poate fi dată doar în starea de TRANSACTION

Comentariu: Serverul POP3 marchează mesajele ca șterse. Orice viitoare referință la numarul asociat mesajului într-o comandă POP3 generează eroare. Serverul POP3 nu șterge efectiv mesajul până când sesiunea POP3 nu întră în starea UPDATE.

Răspunsuri posibile:

+OK message deleted
-ERR no such message

Exemple:

C: DELE 1
S: +OK message 1 deleted

C: DELE 2
S: -ERR message 2 already deleted

NOOP[modificare | modificare sursă]

NOOP

Argumente: nici unul

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Serverul POP3 nu face nimic, doar răspunde cu răspunsuri pozitive.

Răspunsuri posibile:

+OK

Exemple:

C: NOOP
S: +OK

RSET[modificare | modificare sursă]

RSET

Argumente: nici unul

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Orice mesaj marcat de serverul POP3 pentru ștergere este demarcat. Serverul POP3 răspunde apoi cu un răspuns pozitiv.

Răspunsuri posibile:

+OK

Exemple:

C:RSET
S: +OK maildrop has 2 message (320 octets)

Starea UPDATE[modificare | modificare sursă]

Când clientul emite comanda QUIT din starea TRANSACTION, sesiunea POP3 intră în starea UPDATE. (De observat că, dacă clientul emite comanda QUIT din starea AUTHORIZATION, sesiunea POP3 se termină, dar nu intră în starea UPDATE). Dacă o sesiune se termină din anumite motive, altele decât emiterea comenzii QUIT, sesiunea POP3 nu intră în starea UPDATE și nu șterge nici un mesaj din maildrop.

QUIT[modificare | modificare sursă]

QUIT

Argumente: nici unul

Restricții: nici una

Comentariu: Serverul POP3 șterge toate mesajele marcate pentru ștergere din maildrop și răspunde cu privire la starea acestei operații. Dacă există o eroare, ex. resursă lipsă, întâmpinată în timpul ștergerii mesajelor, s-ar putea ca niște mesaje sau nici unul din cele marcate pentru ștergere să nu fie șterse. Chiar dacă operația s-a realizat cu succes sau nu, serverul eliberează orice acces exclusiv și închide conexiunea TCP.

Răspunsuri posibile:

+OK
-ERR some deleted message not removed

Exemple:

C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)

C: QUIT
S: +OK dewey POP3 server signing off (e messages left)

Comenzi POP3 opționale[modificare | modificare sursă]

Comenzile POP3 discutate mai sus trebuie să fie suportate de toate implementările minimale de server POP3. Comenzile POP3 discutate mai jos permit clientului POP3 o mai mare libertate în lucrul cu mesajele, păstrând o implementare simplă de server POP3. Notă: Acest memo încurajează puternic implementări care să suporte aceste comenzi în locul celor ce dezvoltă mărirea listelor “drop” și “scan”. În câteva cuvinte, filozofia acestui memo este de a pune inteligența de partea clientului POP3 și nu a serverului POP3.

TOP[modificare | modificare sursă]

TOP msg n

Argumente: Un număr de mesaj (obligatoriu) care nu poate să se refere la un mesaj marcat pentru ștergere și un numar pozitiv de linii (obligatoriu).

Restricții: Poate fi dată doar în faza TRANSACTION

Comentariu: Dacă serverul POP3 emite un răspuns pozitiv, atunci răspunsul dat este multi-linie. După inițialul +OK, serverul POP3 trimite headerele mesajului, o linie goală separând headerele de corp și apoi un număr de linii separate indicând corpul mesajului, fiind atent la completarea caracterul terminal. De observat că dacă numărul de linii cerute de clientul POP3 este mai mare decât numărul de linii ale corpului mesajului, atunci serverul POP3 trimite întregul mesaj.

Răspunsuri posibile:

+OK top of mesaage follows
-ERR no such message

Exemple:

C: TOP 1 10
S: +OK
S:<the POP3 server sends the headers of the message, a blank line, and the first 10 lines of the body of message>
S: .

C: TOP 100 3
S: -ERR no such message

UIDL[modificare | modificare sursă]

UIDL [msg]

Argumente: Un număr de mesaj (optional), care, dacă e prezent, nu poate să se refere la un mesaj marcat pentru ștergere.

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Dacă un argument a fost dat, serverul emite un răspuns pozitiv cu o linie conținând acel mesaj. Această linie este numita “unique-id listing” pentru acel mesaj. Dacă nu a fost dat nici un argument și serverul emite un răspuns pozitiv, atunci răspunsul dat este multi-linie. După +OK inițial, pentru fiecare mesaj din maildrop, serverul POP3 răspunde cu o linie ce conține informații despre acel mesaj. În scopul simplificării analizei, toate serverele POP3 sunt obligate să utilizeze un format sigur pentru “unique-id listing”. O lista cu id-ul unic constă dintr-un număr de mesaj al mesajului, urmat de un singur spațiu și de id-ul unic al mesajului. Nu urmează nici o informație id-ului mesajului din lista de Id-uri unice. Id-ul unic al mesajului este un string determinat arbitrar de server, conținand 70 de caractere între 0x21 – 0x7E, care identifică unic un mesaj în cadrul unui maildrop și care persistă în timpul sesiunii. Această persistență este obligatorie chiar dacă o sesiune se termină fară a intra în stare UPDATE. Serverul nu ar trebui să reutilizeze un Id unic într-un maildrop anume, atât timp cât entitatea ce utilizează Id-ul unic respectiv există. De observat că mesajele marcate pentru ștergere nu sunt listate. Deși, în general, este preferabil ca implementările pentru server să păstreze Id-urile unice asignate arbitrar în maildrop, această specificare intenționează să permită ca Id-urile unice să fie calculate ca a hash of the message. Clienții ar trebui să poată trata situația în care două copii identice ale unui mesaj din maildrop au acelasși Id unic.

Răspunsuri posibile:

+OK urmat de lista de id-uri unice
-ERR no such message

Exemple:

C: UIDL
S: +OK
S: 1 whqtswo00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBwPh7x7
S: .

C: UIDL 2
S: +OK 2 OhdPYR:00WBw1Ph7x7

C: UIDL 3
S: -ERR no such message, only 2 messages În maildrop

USER[modificare | modificare sursă]

USER nume

Argumente: Un șir de caractere identificând o casuță poștală (obligatoriu), care este semnificativ doar serverului.

Restricții: Poate fi dată doar în starea de AUTHORIZATION după mesajul de salut al serverului POP3 sau după una din comenzile USER sau PASS terminate cu eroare.

Comentariu: Pentru autentificare utilizând comenzile USER și PASS, clientul trebuie să emită mai întâi comanda USER. Dacă serverul POP3 răspunde cu un indicator pozitiv (“+OK”), atunci clientul poate emite fie comanda PASS să completeze autentificarea, fie comanda QUIT să termine sesiunea POP3. Dacă serverul POP3 răspunde cu un indicator negativ de stare (“-ERR”) pentru comanda USER, atunci clientul poate emite fie o comandă nouă de autentificare, fie comanda QUIT. Serverul poate returna un răspuns pozitiv chiar dacă nu există nici o casuță poștală. Serverul poate returna un răspuns negativ dacă căsuța poștală există, dar nu permite autentificare de parolă tip plaintext.

Răspunsuri posibile:

+OK nume is a valid mailbox
-ERR never heard of mailbox nume

Exemple:

C: USER frated
S: -ERR sorry, no mailbox for frated here

C: USER mrose
S: +OK mrose is a real hoopy frood

PASS[modificare | modificare sursă]

PASS șir caractere

Argumente: O parolă de server/căsuță poștală(obligatoriu).

Restricții: Poate fi dată doar în starea de AUTHORIZATION imediat după o comandă USER încheiată cu succes.

Comentariu: Când un client emite comanda PASS, serverul POP3 utilizează perechea de argumente de la USER și comenzile PASS să determine dacă clientului ar trebui să i se permită accesul la maildrop-ul respectiv. Deoarece comanda PASS are exact un argument, serverul POP3 poate trata spațiile în argument ca parte a parolei, în loc de separatoare de argument.

Răspunsuri posibile:

+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop

Exemple:

C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already locked

C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose’s maildrop has 2 messages (320 octets)

APOP[modificare | modificare sursă]

APOP nume rezumat

Argumente: Un șir de caractere identificând căsuța poștală și un rezumat MD5 (amandouă obligatorii).

Restricții: Poate fi dată doar în starea de AUTHORIZATION după salutul serverului POP3 sau după una din comenzile USER sau PASS terminate cu insucces.

Comentariu: În mod normal, fiecare sesiune POP3 începe cu USER/PASS. Aceasta sfârșește serverul / id-ul user-ului specific, parola fiind trimisă în rețea. Multe implementări de client POP3 se conectează la un server POP3 în mod obișnuit – pentru a verifica mail-ul nou. În plus intervalul sesiunii inițiate poate fi de 5 minute. Deci, riscul capturării parolei este mare. Este necesară o metodă alternativă de autentificare, care să furnizeze cele două metode originale de autentificare și protejare a răspunsului, care să nu implice trimiterea parolei neprotejate în rețea. Comanda APOP furnizează această funcționalitate. Un server POP3 care implementează comanda APOP va include o marcă de timp în banner-ul mesajului de salut. Sintaxa acestei marcări a timpului corespunde lui “msg-id” din RFC 822 și trebuie să fie diferită de fiecare dată când serverul POP3 emite un banner de salut. De exemplu, într-o implementare UNIX în care sunt utilizate procese UNIX separate pentru fiecare instanță a serverului POP3, sintaxa unei mărci de timp poate fi: process-ID.clock@hostname unde “process-ID” este o valoare zecimală a PID-ului procesului, “clock” este o valoare zecimală a timpului sistemului și “hostname” este numele complet al domeniului corespunzător gazdei unde rulează serverul POP3. Clientul POP3 ia la cunoștință de această marcă de timp și apoi emite comanda APOP. Parametrul “nume” are aceași semantică exact ca parametrul “nume” din comanda USER. Parametrul “rezumat” este calculat prin aplicarea algoritmului MD5 RFC 1321 unui șir de caractere compus din marca de timp (incluzând parantezele – unghiulare) urmat de informația secretă. Informația secretă (shared secret) este un șir de caractere cunoscut numai de clientul și serverul POP3. Mare atenție ar trebui acordată pentru a împiedica o dezvăluire neautorizată a secretului, cunoașterea secretului va permite oricarei entitați să se ascundă sub acel nume de user. Parametrul “rezumat” este o valoare pe 16 octeți care este trimisă în format hexazecimal, utilizând caracterele ASCII lower-case. Când serverul POP3 primește comanda APOP, verifică rezumatul furnizat. Dacă rezumatul este corect serverul POP3 emite un răspuns pozitiv și sesiunea POP3 intră în starea TRANSACTION. Altfel, un răspuns negativ este emis și sesiunea POP3 rămâne în starea AUTHORIZATION. De observat că, lungimea informații secrete crește, deci și dificultatea. Ca atare, informațiile secrete ar trebui să fie de lungime mare (mult mai mult de 8 caractere ca în ex. de mai jos).

Răspunsuri posibile:

+OK maildrop locked and ready
-ERR permission denied

Exemplu:

S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octetes)

În acest exemplu, informația secretă este șirul “tan-staaf”. Deci, algoritmul MD5 este aplicat șirului: <1896.697170952@dbc.mtview.ca.us>tanstaaf care produce o valoare rezumat a: c4c9334bac560ecc979e58001b3e22fb

Considerații[modificare | modificare sursă]

De când caracteristicile principale descrise mai sus au fost adăugate la protocolul POP3, s-a acumulat experiență în utilizarea lor pe scară largă în operații de “post office” unde cei mai mulți utilizatori nu se cunosc unii cu ceilalți. În aceste situații și altele, utilizatorii și vânzătorii de clienți POP3 au descoperit că o combinație între comanda UIDL și neemiterea comenzii DELE, poate furniza o versiune slabă de “depozit maildrop semi-permanent” având o funcționalitate normală asociată cu IMAP. Desigur alte calităti IMAP, așa cum verificând o conexiune existentă pentru mesajele noi sosite și suportând foldere multiple pe server, nu sunt prezente în POP3. Când aceste facilități sunt utilizate ocazional de către utilizatori, există o tendință de recitire a mesajelor acumulate pe server fară limită. Acesta este clar un tip de comportament nedorit din punctul de vedere al operatorului de server. Această situație este agravată de faptul că posibilitățile limitate ale POP3-ului nu permit manipularea eficientă a maildrop-urilor care au mii de mesaje. În consecință, este recomandat ca operatorii de servere multi-users la scară largă, în special cei care au acces la maildrop doar via POP3, să considere următoarele alternative:

  • Impunând alocarea de spațiu de depozitare a maildrop-ului. Un dezavantaj al acestei opțiuni este că acumularea de mesaje poate provoca neputința utilizatorului de a primi noi mesaje în maildrop. În situațiile în care se alege această opțiune ar trebui să se asigure informarea utilizatorilor asupra acestui impediment sau epuizarea spațiului, poate prin inserarea unui mesaj potrivit în maildrop-ul userului.
  • Impunând o poliță de asigurare privind păstrarea pe server. Utilizatorii sunt liberi să stabilească această poliță de asigurare privind depozitarea și păstrarea mesajelor pe server, cele citite și cele necitite. De exemplu, un utilizator poate șterge mesajele necitite de pe server după 60 de zile și pe cele citite după 7 zile. Ștergerile de mesaj sunt în afara protocolului POP3 și nu sunt considerate o violare de protocol. Operatorii de server impunând polițele de asigurare cu privire la ștergerea mesajelor ar trebui să aibă grijă să facă toți utilizatorii conștienți de puterea acestora. Clienții nu trebuie să presupună că o poliță va șterge automat mesajele și ar trebui să continue să șteargă explicit mesajele utilizând comanda DELE când este cazul. De notat că impunerea acestor polițe de asigurare de ștergere poate fi confuză pentru utilizatorii simpli, deoarece clientul lor POP3 poate conține opțiuni de configurare de a șterge mail-ul de pe server, care nu va fi de fapt suportat de server. Un caz special al polițelor este că mesajele pot fi doar download-ate odată de pe server și sunt șterse după ce acesta a terminat operația. Aceasta ar putea fi implementată de un server POP3 prin următorul mecanism: ”urmărind un login de client POP3 care a terminat prin QUIT, șterge toate mesajele download-ate în timpul sesiunii cu comanda RETR”. Este important să nu se șteargă mesajele dacă conexiunea s-a încheiat printr-un eveniment anormal (ex. dacă QUIT nu a fost primit de la client) deoarece clientul poate nu a primit sau nu a salvat cu succes mesajele). Serverele ce implementează polițele downloadează-și-șterge pot de asemenea să dorească să dezactiveze sau să limiteze comanda TOP, deși ar putea fi utilizată ca un mecanism alternativ pentru a downloada toate mesajele.

Exemplu de sesiune POP3[modificare | modificare sursă]

  S: <wait for connection on TCP port 110>
  C: <open connection>
  S: +OK POP2 server ready <1896.697170952@dbc.mtview.ca.us>
  C: APOP mrose c4c9334bac560ecc97e58001b3e22fb
  S: +OK mrose’s maildrop has 2 messages (320 octets)
  C: STAT
  S: +OK 2 320
  C: LIST
  S: +OK 2 messages (320 octets)
  S: 1 120
  S: 2 200
  S: .
  C: RETR 1
  S: +OK 120 octets
  S: <the POP3 server sends message 1>
  S: .
  C: DELE 1
  S: +OK message 1 deleted
  C: RETR 2
  S: +OK 200 octets
  S: <the POP3 server sends message 2>
  S: .
  C: DELE 2
  S: +OK message 2 deleted
  C: QUIT
  S: +OK dewey POP3 server signing off (maildrop empty)
  C: <close connection>
  S: <wait for next connection>

Formatul Mesajului[modificare | modificare sursă]

Toate mesajele transmise în timpul sesiunii POP3 sunt sumate conform standardului pentru formatul textelor mesajelor pentru Internet RFC 822. Este important de observat că numărarea octetului pentru un mesaj de pe un server gazdă poate diferi de numărarea octetului asignat mesajului datorită convențiilor locale pentru desemnarea sfârșitului de linie (end-of-line). De obicei, în timpul stării de AUTHORIZATION a unei sesiuni POP3, serverul POP3 poate calcula mărimea fiecărui mesaj în octeți când deschide maildrop-ul. De exemplu, dacă serverul gazdă POP3 numără fiecare apariție a acestui caracter ca doi octeți. Acele linii din mesaj care încep cu octetul terminal nu au nevoie (și nu trebuie) numărate de doua ori, deoarece clientul POP3 va șterge toate caracterele de terminale când primește un răspuns multi-linie.