Atunci când e-mailul este trimis de multe ori, este necesar să includeți o altă literă în interiorul literei. Pentru aceasta, se folosește tipul de "mesaj".
Subtipul principal este "rfc822" - nu necesită parametri în câmpul Content-Type. Subtipurile suplimentare - "parțial" și "corp exterior" - presupun prezența parametrilor.
Principalul subtip este "message / rfc822"
Acest subtip indică faptul că corpul mesajului conține un atașament în RFC standard de 822, cu toate acestea, spre deosebire de RFC stratul superior 822 antet pentru fiecare piesă, care este RFC scrisoare 822, nu are nevoie de un câmp „De la“, „Subiect“ și la cel puțin un câmp "To".
În ciuda utilizării numărului "822", corpul care are subtipul "mesaj / rfc822" poate include informații suplimentare în conformitate cu standardul MIME. Cu alte cuvinte, mesajul "mesaj / rfc822" poate fi o scrisoare MIME.
Subtipul "mesaj / parțial"
Acest subtip este definit pentru a asigura posibilitatea trimiterii unor obiecte foarte mari sub forma mai multor părți separate, care sunt "lipite" automat de programul de mail al destinatarului. Acest mecanism poate fi util atunci când gateway-urile de poștă intermediară limitează dimensiunea individuală a mesajelor trimise. astfel Acest subtip indică faptul că litera conține numai o parte dintr-un mesaj mare.
Pentru acest subtip, trebuie să specificați trei parametri:
- "id" este un identificator unic care vă permite să găsiți restul mesajului.
- "număr" este un număr care indică numărul piesei mesajului.
- "total" este un număr întreg care înseamnă numărul total de piese. Este necesar numai în ultima parte și este opțională (deși recomandată) pentru părțile anterioare. Acești parametri pot urma în orice ordine.
Exemplu: Partea 2 a unui mesaj privat de 3 litere are următoarele opțiuni antet:
Dar partea 3 trebuie să conțină parametrul "total":
Trebuie notat că numărarea părților începe cu 1, nu cu 0.
Atunci când piese similare rupte sunt asamblate împreună, ele formează o literă completă MIME, conținutul căruia poate fi de orice alt tip și, în consecință, câmpul cu antet de tip Content-Type descriind acest tip.
Semantica unei scrisori parțiale ar trebui să fie aceeași ca într-o scrisoare obișnuită cu conținut de acest tip și nu ca într-o scrisoare conținând o scrisoare "internă". Aceasta permite, de exemplu, trimiterea unui fișier audio mare, sub forma a câtorva mai mici, care rămân, totuși, vizibile pentru destinatar ca litere audio obișnuite, și nu ca litere audio încorporate.
Când se asamblează astfel de mesaje la destinație, trebuie luate în considerare următoarele reguli:
(1) Toate câmpurile de antet din partea 1, cu excepția începând cu „Content-“ și speciale „ID-ul mesajului“, „criptat“ și „MIME-Version“ trebuie să fie copiat în antetul noi (total) litere.
(2) Numai câmpurile de antet imbricate litere care încep cu „Content-“, precum și câmpul „ID-ul mesajului“, „criptat“ și „MIME-Version“, trebuie să fie adăugate la antetul unei noi scrisori comune, toate celelalte domenii ar trebui să fie ignorate.
(3) Titlurile celei de-a doua părți și ale pieselor următoare sunt complet ignorate.
De exemplu, dacă o literă cu date audio a fost împărțită în două părți, prima ar putea arăta astfel:
Iar al doilea poate arăta astfel:
După ce mesajul divizat este re-creat pentru a fi afișat destinatarului, ar trebui să arate astfel:
Comentarii despre codificare organism MIME litere încheiat în cadrul mesajului corpului / partiala: ca tipul de date „mesajul“ niciodată nu poate fi codificat în Base64 sau Quoted-tipărit, poate să apară următoarea problemă în cazul în care tipul de mesaj / partiala literele organism, în care suportă transportul pe 8 biți. Datele binare vor fi împărțite în mai multe mesaje / obiecte parțiale, fiecare dintre acestea fiind obligat să fie transportate în formă binară. Dacă aceste obiecte au trebuit să treacă prin poarta de acces la mediul transportului pe 7 biți, acestea nu au putut fi recodate în formă seimbitnuyu fără a aștepta sosirea tuturor părților mesajului, colectarea acestora împreună, și apoi codificarea unui mesaj în codificare pe 7 biți (Base64 sau citat-printable) . Deoarece există posibilitatea ca diferitele părți să meargă în moduri diferite (prin intermediul unor gateway-uri diferite), o astfel de decizie nu este acceptabilă. Prin urmare, MIME determină faptul că scrisorile de tip mesaj / parțial trebuie să aibă o codificare pe 7 biți și o valoare corespunzătoare a câmpului de codare a transferului de conținut. Chiar și pentru sistemele de transport care susțin "8-bit" și "binar", este interzisă utilizarea acestora pentru mesaje / date parțiale.
Mulți agenți de e-mail pot fragmenta automat literele mari.
Includerea câmpului "Referințe" în anteturile părții a doua și ulterioare referitoare la identificatorul părții anterioare poate fi utilă pentru programele de poștă electronică care înțeleg și procesează legături. Cu toate acestea, prezența acestui câmp nu este necesară.
Câmpul antet "Criptare" nu este folosit, dar regulile de mai sus oferă o interpretare corectă a acestuia dacă apare atunci când procesează mesaje / fragmente parțiale.
Subtipul "mesaj / corp exterior"
Scrisoarea (o parte a literei) a acestui subtip cuprinde un antet, două capete de linii consecutive și un antet al literei închise. Dacă există o altă pereche de capete de linie, aceasta înseamnă sfârșitul antetului literei închise. Cu toate acestea, deoarece corpul literei închise este extern, nu urmează sfârșitul antetului. De exemplu,
Regiunea de la capăt, care poate fi numită "corp fantomatic", este ignorată pentru majoritatea literelor subtipului "corp exterior". Cu toate acestea, pot fi plasate informații suplimentare, de exemplu, în cazul în care parametrul "tipul de acces" este egal cu "serverul de poștă electronică". În toate celelalte cazuri, corpul fantomatic este ignorat.
Singurul parametru întotdeauna necesar pentru "mesaj / corp exterior" este "tip de acces". Parametrii rămași pot sau nu pot fi obligatorii, în funcție de valoarea parametrului "tip acces".
Valoarea acestui parametru este un cuvânt insensibil în cazul literelor, adică mecanismul de acces prin care fișierul sau datele pot fi preluate. Valorile pot fi, dar nu se limitează la: FTP, ANON-FTP, TFTP, AFS, LOCAL-FILE și MAIL-SERVER. Viitoarele valori posibile, altele decât cele experimentale, începând cu "X", ar trebui înregistrate la IANA.
În plus, următorii trei parametri sunt opționali pentru toate metodele de acces:
EXPIRARE - Data (sintaxa "data-timp" RFC 822 permite 4 cifre în acest câmp), după care nu este garantată existența datelor externe.
SIZE - dimensiunea (în octeți) a datelor. Permite destinatarului să decidă dacă să cheltuiască resurse pentru citirea datelor externe. Dimensiunea este specificată pentru forma canonică a datelor (adică înainte de aplicarea oricărei transformări).
PERMIS - un câmp insensibil la caz, care indică dacă clientul așteaptă sau nu suprascrie datele. În mod implicit, sau când acest parametru are valoarea "citit", se presupune că clientul nu are acest drept și că dacă datele sunt citite o dată, nu vor mai fi necesare. Dacă PERMISIA are valoarea "read-write", orice copie locală nu poate fi considerată decât o cache. "citirea" și "scrierea" sunt singurele valori predefinite pentru PERMIS.
Nivelele antetului în toate caroseria mesajului / corpului exterior TREBUIE să includă câmpul antetului Content-ID pentru a specifica un identificator unic indicând datele externe.
Legenda care descrie datele corpului extern, cum ar fi numele de fișiere sau comenzile serverului de mail, trebuie să fie în setul de caractere US-ASCII.
Ca și mesajul / tipul parțial, corpul mesajului / tipul corpului extern trebuie să aibă o valoare de codificare a transferului de conținut de "7-biți" (implicit). În special, chiar și în sistemele care suportă transportul pe 8 biți, este interzisă aplicarea codării de transfer de conținut "8-bit" și "binar" pentru datele de tip de mesaj / corpul exterior.
Tipurile de acces "ftp" și "tftp"
Tipul de acces prin FTP sau TFTP înseamnă că corpul mesajului este disponibil ca fișier extern prin FTP [RFC-959] sau respectiv TFTP [RFC-783]. Următorii parametri suplimentari sunt necesari pentru aceste tipuri de acces:
NAME - Numele fișierului care conține corpul mesajului.
Înainte de a începe citirea datelor FTP, în mod normal, utilizatorul trebuie să primească login și parola pentru mașina specificată în parametrul "site". Din motive de securitate, datele de conectare și parola nu sunt specificate ca parametri Content Type și trebuie primite de la destinatarul mesajului.
Sunt definiți următorii parametri opționali:
DIRECTOR - directorul care conține corpul mesajului de pe aparatul de la distanță.
MODE - Un șir insensibil pentru litere care indică modul de transfer de date. Valorile valide pentru tipul de acces TFTP sunt:
NETASCII, OCTET și MAIL. Pentru FTP tipuri de acces: ASCII, EBCDIC, IMAGE si LOCALn, unde n - număr întreg zecimal, în mod tipic 8. Aceste valori corespund tipurilor de reprezentare A, E, I și Ln. definit FTP-protocol. Rețineți că "BINARY" și "TENEX" nu sunt valori valide pentru parametrul MODE. În schimb, ar trebui folosite "OCTET", "IMAGE" sau "LOCAL8". Dacă lipseste parametrul MODE, valoarea implicită este "NETASCII" pentru TFTP și "ASCII" pentru FTP.
Modul de acces "anon-ftp"
Metodele de acces "local-file" și "afs"
Metoda de acces "fișier local" înseamnă că corpul mesajului este disponibil ca fișier pe mașina locală. "afs" înseamnă că organismul este disponibil ca fișier prin sistemul comun de fișiere AFS. În ambele cazuri, este necesar numai parametrul necesar:
NAME - Numele fișierului care conține corpul mesajului.
Metoda de acces "mail-server"
Se aplică atunci când corpul mesajului este accesibil prin serverul de poștă electronică. Parametrul necesar pentru această metodă de acces:
Deoarece serverele de e-mail necesită o varietate de sintaxe diferite, dintre care unele pot fi multi-linie, comanda completă care urmează să fie trimise la serverul de email nu este inclus ca un parametru într-o singură linie câmp „tip de conținut“. În schimb, acesta este plasat într-un corp imaginar, în cazul în care valoarea câmpului „tipul de conținut“ un „/ extern corpul mesajului“, iar parametrul „de acces-tyoe“ are o valoare de „e-mail-server“.
Un parametru opțional pentru această metodă de acces este:
Standardul MIME nu definește sintaxa pentru accesarea serverului de e-mail. Prin urmare, permite includerea unei comenzi complete pentru serverul de mail din corpul imaginar.
Spre deosebire de alte modalități de acces, accesul prin serverul de e-mail nu este sincron și datele pot fi obținute într-un moment imprevizibil în viitor. Din acest motiv, este important să existe un mecanism care să asigure că datele primite de la serverul de e-mail sunt inserate în mesajul original. Mail-server atunci când trimit datele solicitate trebuie să utilizeze aceeași valoare a câmpului Content-ID în antetul mesajului cu datele returnate, care a fost în original „incorporal“, scrisoarea pentru a facilita funcționarea acestui mecanism.
Exemple și explicații suplimentare
Dacă corpul exterior al mesajului este accesibil prin mai multe mecanisme diferite, expeditorul poate include mai multe părți ale mesajului / tipului de corp exterior într-o literă de tip multipart / alternativă.
Antetele literelor comune și închise (care au un corp exterior) trebuie să respecte aceleași reguli ca pentru mesaj / tip parțial, pentru a evita confuzia.
Deoarece corpul extern nu este trimis sub formă de poștă, acesta nu trebuie să satisfacă cerințele de lungime a liniilor și are o formă de 7 biți, poate fi doar un fișier binar. Prin urmare, câmpul Content-Transfer-Encoding nu este necesar, deși prezența sa este permisă.
Tipul de literă „mesaj / extern-corp“ organism prelucrat în praguri și sintaxa de bază a RFC standard de 822, în special, tot ceea ce merge la prima pereche secvențială a liniei se termină (CRLF), un antet de mesaj, și tot ceea ce vine după o " imaginar "al literei, care este ignorat pentru majoritatea tipurilor de acces.
Sintaxa oficială a câmpului de antet "tip de conținut" pentru datele de tip "mesaj" este după cum urmează:
Articole similare
Trimiteți-le prietenilor: