Know-how, prelegere, protocolul de e-mail

Tipul mesajului

Adesea este de dorit atunci când trimiteți e-mail pentru a atașa acolo un alt mesaj. Pentru a rezolva această problemă, este definit un tip special de mediu de mesaje. În particular, subtipul rfc822 este utilizat pentru a se atașa la mesajele RFC-822.

Subtipul mesajului plasează adesea restricții asupra tipurilor de codare admise. Aceste restricții sunt descrise pentru fiecare subtip specific. Poștajele de poștă electronică, sistemele de transport și alți agenți de corespondență schimbă câteodată anteturile de nivel superior în mesajele RFC-822. În special, adesea adaugă, șterg și modifică ordinea câmpurilor de antet. Aceste operațiuni sunt interzise pentru anteturile încorporate în corpul de mesaje al tipului de mesaj.

În corpul obiectului mesaj / rfc822 nu sunt permise alte codificări decât 7bit, 8bit sau binar. Câmpurile cu antet de mesaje conțin doar US-ASCII în orice registru și informațiile din corp pot fi codate. Textul non-US-ASCII din anteturile mesajului încapsulat poate fi specificat utilizând mecanismul descris în RFC-2047.

Subtipul parțial este definit pentru a permite părților de obiecte prea mari să fie împărțite în părți, care apoi sunt livrate ca mesaje de e-mail separate și restaurate automat ca o singură entitate de către agentul de destinație utilizator. Acest mecanism poate fi utilizat atunci când agentul intermediar de transport limitează dimensiunea maximă a mesajului de e-mail. Tipul mesajului / mediul parțial indică faptul că corpul conține un fragment al unui obiect mare.

Deoarece tipul de date de mesaje nu pot fi codificate sub forma base64 sau un șir citat de caractere imprimabile, poate apărea o problemă dacă mesajul / obiectele parțiale create într-un mediu care suportă un schimb binar sau 8 biți. Problema apare deoarece datele binare vor trebui împărțite în mai multe mesaje / parțiale, fiecare necesitând un transport binar. Dacă astfel de mesaje răspund gateway-ului cu o transmisie pe 7 biți, nu va exista nici o modalitate de a re-codifica aceste fragmente pentru un mediu pe 7 biți. Puteți, desigur, să așteptați sosirea tuturor componentelor, să colectați obiectul original, să îl codificați utilizând, de exemplu, baza64. după care începeți din nou. Dar chiar și un astfel de scenariu complex poate să nu fie posibil datorită faptului că fragmentele pot fi transportate în moduri diferite. Din acest motiv, sa specificat că obiectele de tipul mesaj / parțial ar trebui să aibă întotdeauna codificare transport 7bit (implicit). În special, chiar și pentru mediile care suportă schimbul binar sau pe 8 biți, este interzisă utilizarea codării transportului pe 8 biți sau binar pentru mesaje / obiecte MIME parțiale. Aceasta, la rândul său, presupune că mesajul intern nu ar trebui să utilizeze codarea 8bit sau binar. Deoarece unele agenții sunt mesaje pot selecta fragmentarea automată a mesajelor lungi, precum și datorită faptului că acești agenți pot utiliza diferite praguri de fragmentare, se poate întâmpla ca piesele după asamblare, la rândul său, va fi mesajul. Acest lucru este permis în întregime.

În câmpul Tip de conținut de tip mesaj / parțial, trebuie să specificați trei parametri. id este un identificator unic care ar trebui folosit pentru a lega fragmente între ele. numărul este un număr întreg care este numărul fragmentului. total este un întreg care caracterizează numărul total de fragmente. Numărul de fragmente este opțional și trebuie să fie prezent numai în ultimul fragment. Rețineți, de asemenea, că acești parametri pot fi specificați în orice ordine. Astfel, cel de-al doilea segment al mesajului cu 3 fragmente poate avea câmpuri de antet ale unuia dintre următoarele tipuri.

În cel de-al treilea segment, trebuie să fie specificat numărul total de fragmente.

Rețineți că numerotarea fragmentelor începe la 1, nu c 0.

Atunci când fragmentele unui obiect rupt în acest fel sunt adunate, rezultatul va fi întotdeauna obiectul original MIME care poate avea propriul câmp de antet Content-Type și, prin urmare, are orice alt tip de date.

Semantica fragmentelor de mesaje recuperate trebuie să corespundă mesajului intern, și nu mesajului în care este încorporat. Acest lucru face posibil, de exemplu, trimiterea de mesaje audio de mare ca mesaje de mai multe fragmente, astfel încât destinatarul va accepta ca un mesaj audio simplu, în loc de un mesaj care cuprinde încapsulate mesaj audio. Această încapsulare este considerată transparentă. Când se formează fragmente și se asamblează ansamblurile mesajului / mesajului parțial, antetele mesajului încapsulat trebuie combinate cu anteturile obiectelor imbricate. La punerea în aplicare a acestei proceduri, trebuie respectate următoarele reguli.

Agenții de fragmentare ar trebui să separe mesaje numai după limitele liniei. Această restricție este introdusă datorită faptului că, dacă această regulă nu este respectată, va exista o problemă de transport de stocare a semanticii mesajelor care nu se termină cu secvența CRLF. Multe moduri de transport nu sunt capabile să rezolve această problemă
Toate câmpurile din antetul mesajului original închis, cu excepția celor ale căror nume încep cu „Content-“, iar antetul specifice câmpuri de subiect, ID-ul mesajului, criptatăse MIMEVersion, trebuie copiat în noul mesaj
Câmpurile antetului mesajului încorporat, începând cu "Conținut", plus câmpurile Subiect, Mesaj-ID, Criptare și MIMEVersion, trebuie adăugate câmpurilor noului mesaj. Toate câmpurile de antet care nu pornesc de la "Conținut" (cu excepția câmpurilor Subiect, Mesaj-ID, Criptare și MIMEVersion) vor fi ignorate și ar fi eliminate
Toate câmpurile de antet ale celui de-al doilea mesaj și toate mesajele imbricate ulterioare sunt eliminate de programul de primire în timpul procesului de construire

Dacă mesajul audio este împărțit în două fragmente, prima parte poate arăta astfel:

iar a doua parte poate arăta astfel:

Apoi, atunci când mesajul fragmentat este colectat, rezultatul afișat utilizatorului ar trebui să arate ca:

Includerea câmpului Referințe în anteturile secțiunii a doua și secțiunile următoare, care indică Id-ul mesajului din secțiunea anterioară, poate fi util pentru un cititor de e-mail care poate urmări legăturile. Cu toate acestea, generarea de câmpuri Referințe este opțională.

În cele din urmă, trebuie remarcat faptul că câmpul Criptată antet este depășită din cauza introducerii unui PEM e-mail confidențială (confidențialitate îmbunătățită de mesaje; RFC-1421, RFC-1422, RFC-1423, RFC-1424), dar regulile descrise mai sus, indiferent de ce , descrie modul corect de prelucrare a acestuia, dacă apare în contextul transformării directe și inverse a mesajului / fragmente parțiale.

Când un obiect MIME este de tip mesaj / corp exterior, acesta constă dintr-un antet, două secvențe CRLF și un antet pentru mesajul încapsulat. Dacă apare o altă pereche de secvențe CRLF, aceasta va completa antetul mesajului încapsulat. Cu toate acestea, deoarece corpul mesajului încapsulat în sine este extern, acesta nu apare după antet. De exemplu, luați în considerare următorul mesaj:

Zona de la capăt, care poate fi numită corp fantomatic, este ignorată pentru majoritatea mesajelor cu un corp exterior. Cu toate acestea, acesta poate fi utilizat pentru a stoca informații auxiliare pentru astfel de mesaje, la fel ca în cazul în care tipul de acces este server-mail. Singurul tip de acces descris în acest document și care utilizează o fantomă. Este un server de poștă electronică, dar pe viitor alte tipuri pot fi rezolvate.

Capacele încapsulate în toate obiectele mesajului / corpului exterior trebuie să includă un câmp de antet Content-ID pentru a furniza un identificator unic care servește la trimiterea datelor. Acest identificator poate fi folosit în procesul de cache și pentru recunoașterea datelor de intrare atunci când tipul de acces este serverul de poștă electronică.

Rețineți că, așa cum este specificat aici, jetoanele care descriu date externe ale corpului, cum ar fi numele fișierelor și comenzile serverului de mail, trebuie să fie scrise utilizând setul de caractere US-ASCII.

Tipuri de acces ftp și tftp

Tipul de acces FTP sau TFTP indică faptul că corpul mesajului este disponibil ca fișier utilizând protocoalele FTP [RFC-959] sau TFTP [RFC-783]. respectiv. Următorii parametri sunt necesari pentru aceste tipuri de acces.

NAME (nume). Numele fișierului care conține corpul de date
SITE (nod). Un computer cu care poate fi obținut un fișier utilizând acest protocol. Acesta trebuie să fie un nume înregistrat, nu un pseudonim
Înainte de extragerea oricăror date utilizând FTP. utilizatorul trebuie să efectueze procedura de autentificare (introduceți numele și parola) pe mașina specificată în parametrul SITE. Din motive de securitate, numele și parola nu sunt specificate de parametrii de tip acces, trebuie să fie primite direct de la utilizator

În plus, următoarele opțiuni sunt opționale:

DIRECTOR (director). Directorul din care trebuie să fie preluat fișierul cu numele specificat de parametrul NAME
MODE (mod). Un șir de caractere care este independent de registrul de intrare și indică modul care ar trebui să fie utilizat la extragerea informațiilor. Valorile valide ale parametrilor tipului de acces TFTP valid sunt NETASCII, OCTET și MAIL, așa cum au fost definite pentru protocolul TFTP [RFC-783]. Valorile valide ale parametrilor pentru tipul de acces FTP sunt ASCII, EBCDIC. IMAGE si LOCALn, unde "n" - un număr întreg, de obicei 8. Acestea corespund tipurilor de reprezentare "A", "E" "I" și "L n", ca protocolul FTP specificat [RFC-959]. Rețineți că BINARY și TENEX nu sunt valori valide pentru MODE, ci folosiți în schimb OCTET. IMAGE sau LOCAL8. Dacă nu este specificat MODE, implicit este NETASCII pentru TFTP și ASCII în toate celelalte cazuri

Tip de acces la fișierul local

Tipul de acces local-file indică faptul că corpul de date este disponibil ca fișier pe computerul local. Pentru acest tip de acces sunt definiți doi parametri suplimentari.

NAME (nume). Numele fișierului care conține corpul de date. Acest parametru este necesar pentru tipul de acces la fișierul local
SITE (nod). Un specificator de domeniu pentru un anumit computer sau un set de mașini care au acces la acest fișier de informații. Acest parametru opțional este utilizat pentru a descrie indicatorul local la date, adică Un nod sau un grup de noduri din care este disponibil acest fișier. Ca caractere spionaj într-un nume de domeniu, asteriscurile pot fi utilizate, la fel ca în "* .bellcore.com" pentru a indica un grup de computere de la care datele sunt disponibile direct

Accesați tipul de server de mail

Tipul de acces la serverul de poștă electronică specifică faptul că corpul de date este disponibil pe serverul de e-mail. Pentru acest tip de acces sunt definiți doi parametri suplimentari.

Deoarece serverele de poștă electronică acceptă o varietate de sintaxe, dintre care unele sunt multiline, comanda completă care trebuie trimisă serverului de e-mail nu este inclusă ca parametru cu câmpul cu antetul de tip conținut. În schimb, este înregistrat ca un corp fantomatic. când tipul de suport corespunde mesajului / corpului exterior. iar tipul de acces este mail-server.

Spre deosebire de alte tipuri de acces, accesul la serverul de mail este asincron și are loc într-un moment arbitrar în timp. Din acest motiv, este important să existe un mecanism prin care datele primite pot fi mapate la mesajul original / corpul extern. Serverele MIME de e-mail ar trebui să utilizeze același câmp Content ID în mesajul de răspuns care a fost folosit în obiectele sursă mesaj / corpul exterior, pentru a facilita această mapare.

Articole similare

Pagina anterioară