POP3
De la Wikipedia, enciclopedia liberă
POP3 sau Protocolul Post Office – Versiunea 3 este serviciul informatic sau protocolul utilizat 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.
Cuprins |
[modifică] Scurtă Divagaţie
Acest memo nu specifică cum un client gazdă introduce poşta într-un sistem de transport, deşi o metodă consecventă cu filozofia acestui memo este prezentată mai jos: când agentul utilizator al unui client gazdă doreşte să introducă poşta în sistemul de transport, stabileşte o conexiune SMTP cu gazdă de retransmitere (relay gazdă) şi îi trimite toate mail-urile. Această gazdă de retransmitere ar putea fi, dar nu e nevoie, server gazdă POP3 pentru clientul gazdă. Bineînţeles, gazda de retransmitere (relay host) trebuie să accepte mail-urile trimise arbitrar destinatarilor primitori; această funcţionalitate nu este obligatorie pentru toate serverele SMTP.
[modifică] Operaţia de bază
Iniţial, serverul gazdă porneşte serviciul POP3 ascultând TCP portul 110. Când clientul gazdă doreşte să utilizeze serviciul, este stabilită o conexiune TCP cu serverul gazdă. 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. Ş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.
[modifică] Starea AUTHORIZATION
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
[modifică] Starea TRANSACTION
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. Prezentăm comenizile POP3 valide în starea TRANSACTION: 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 perechea CRLF. Implementări mai avansate pot include şi alte informaţii. Notă: Acest memo descurajează puternic implementările care furnizează informaţii suplimentare în “drop listing”. Alte facilităţ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 [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 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 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 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 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)
[modifică] Starea UPDATE
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 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) …
[modifică] Comenzi POP3 opţionale
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 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 [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 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 şir caractere Argumente: O parolă de server/căsuţă poştală(obligatoriu). 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 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
[modifică] Consideraţii
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.
[modifică] Sumarul comenzilor POP3
Comenzi minimale POP3:
- 1. valide în starea de AUTHORIZATION:
USER nume PASS şir_caractere QUIT
- 2. valide în starea de TRANSACTION
STAT LIST [msg] RETR msg DELE msg NOOP RSET QUIT Comenzi opţionale POP3:
- 10. valide în starea de AUTHORIZATION
APOP nume rezumat 11. valide în starea de TRANSACTION TOP msg n UIDL [msg] Răspunsuri posibile: +OK -ERR
De observat că, cu excepţia comenzilor STAT, LIST şi UIDL răspunsul dat de serverul POP3 la orice comanda este “+OK” sau “-ERR””. Şi orice text apărut după acest răspuns poate fi ignorat de client.
[modifică] Exemplu de sesiune POP3
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>
[modifică] Formatul Mesajului
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.