|  |
| --- |
| OSI modelis |
| 
7: Lietojumslānis |
| * NNTP
* SIP
* SSI
* DNS
* FTP
* Gopher
* HTTP
* NFS
* NTP
* SMPP
* SMTP
* SNMP
* Telnet
* DHCP
* NETCONF
* RTP
* SPDY
 |
| 
6: Pasniegšanas slānis |
| * MIME
* XDR
* TLS
* SSL
* (vairāk)
 |
| 
5: Sesijas slānis |
| * programmkanāls
* NetBIOS
* SAP
* L2TP
* PPTP
* SOCKS
 |
| 
4: Transporta slānis |
| * TCP
* UDP
* SCTP
* DCCP
* SPX
 |
| 
3: Tīkla slānis |
| * IP (IPv4, IPv6)
* ICMP
* IPsec
* IGMP
* IPX
* AppleTalk
 |
| 
2: Datu posma slānis |
| * ATM
* SDLC
* HDLC
* ARP
* CSLIP
* SLIP
* GFP
* PLIP
* IEEE 802.3
* Frame Relay
* ITU-T G.hn DLL
* PPP
* X.25
* Network switch
 |
| 
1: Fiziskais slānis |
| * EIA/TIA-232
* EIA/TIA-449
* ITU-T V-Series
* I.430
* I.431
* telefona līnija
* PDH
* SONET/SDH
* PON
* OTN
* DSL
* IEEE 802.3
* IEEE 802.11
* IEEE 802.15
* IEEE 802.16
* IEEE 1394
* ITU-T G.hn PHY
* USB
* Bluetooth
* Hubs
 |
| * s
* d
* l
 |

**Multipurpose Internet Mail Extensions** (angļu valodā "interneta pasta vairākmērķu paplašinājumi") jeb **MIME** ir interneta standarts, kas paplašina e-pasta vēstules formātu. Galvenie paplašinājumi:

* teksts iespējams kodējumā, kas atšķiras no US-ASCII;
* vēstulei var pievienot ne teksta piesaistnes;
* vēstuli atļauts veidot no vairākiem ķermeņiem
* galvenes informācija iespējama no ASCII atšķirīga kodējuma.

MIME ir aprakstīts sešos RFC : RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 un RFC 2077.

MIME standartā definētie satura tipi tiek izmantoti arī ārpus e-pasta, piemēram, HTTP protokolā.

Ievads
------

E-pasta sūtīšanas protokols SMTP pieļauj vēstules tikai 7 bitu ASCII kodējumā. Tas bija pietiekami, rakstot tikai ar latīņu alfabēta burtiem. Citās valodās, kas izmantoja latīņu alfabētu, kurā iekļautas diaktriskās zīmes (izmantoti 8 biti kā ASCII papildkodējums), rakstīto nevarēja korekti attēlot e-pasta vēstulē (8. bits tika nonullēts). To atrisināja ar SMTP paplašinājumu 8BITMIME, kas tika publicēts 1994. gadā (RFC 1652).

E-pasta vēstules pamatformāts ir definēts RFC 2822, kas nosaka, kādā veidā jāveido sūtījuma galvenes lauki un ķermenis. MIME paredzēti papildu galvenes lauki, kurā paziņo par satura tipu, vēstules ķermeņa teksta kodējumu. MIME ir ietverts kodēšanas mehānisms galvenes laukiem, piemēram, "*Subject*", kas ļauj galvenē izmantot citu valodu simbolus.

MIME standarts ir paplašināms. Tajā ir noteikts, kādā veidā var reģistrēt jaunus satura tipus un citas MIME atribūtu vērtības.

MIME tika izstrādāts tādā veidā, lai eksistējošie pasta serveri varētu darboties bez izmaiņām, ļaujot sūtīt parasta teksta vēstules abos virzienos kā agrāk. Tas tika panākts, izmantojot papildu RFC 822 veida galvenes laukus visiem MIME atribūtiem un veidojot MIME galvenes laukus neobligātus ar vērtībām pēc noklusējuma, kas nodrošināja, ka MIME neatbilstošus sūtījumus korekti interpretēts MIME atbalstošs klients. Bez tam, vienkāršu MIME teksta vēstuli MIME neatbilstošs klients pareizi interpretētu, pat nezinot MIME lauku nozīmi, un tekstu, kas saturētu ASCII simbolus, lietotājs varētu izlasīt.

MIME galvenes
-------------

### MIME versija

Galvene `MIME-Version` norāda, ka sūtījums ir formatēts MIME standartā. Tā vērtība parasti ir "1.0". Galvene tiks parādīta:

```
MIME-Version: 1.0
```

### Satura tips

`Content-Type` rāda sūtījuma satura interneta medija tipu, kas sastāv no tipa un apakštipa. Piemēram:

```
Content-Type: text/plain
```

Izmantojot vairākdaļu tipu, MIME ļauj veidot vēstuli no vairākām daļām, kas izkārtotas koka struktūrā, kurā lapu mezgli ir ar nevairākdaļas tipu, un nelapu mezgliem ir kāds no vairākdaļu tipa. Šis mehānisms atbalsta:

* vienkāršus teksta sūtījumus, izmantojot `text/plain` (tā ir arī noklusējuma vērtība);
* tekstu ar pievienojumiem (`multipart/mixed` ar `text/plain` un citām neteksta daļām);
* atbildes sūtīšanu ar pievienotu oriģinālu (`multipart/mixed` ar `text/plain` daļu un oriģinālo vēstuli kā `message/rfc822` daļu);
* alternatīvo saturu, tādu kā vēstules sūtīšanu gan vienkāršā tekstā, gan citā formātā, piemēram HTML (`multipart/alternative` ar saturu `text/plain` un `text/html` formātā);
* attēlus, audio, video un lietojumprogrammas (piemeram, `image/jpg`, `audio/mp3`, `video/mp4`, and `application/mswork`);
* daudzas citas sūtījuma konstrukcijas.

### Satura sūtīšanas kodējums

1992. gada jūnijā (RFC 1341, vēlāk tika aizstāts ar RFC 2045) tika noteiktas MIME metodes, kā attēlot bināros datus ASCII teksta formātā. Galvene `Content-Transfer-Encoding` rāda, kura kodēšanas metode tiek lietota:

* izmantojami normālam *SMTP*:
	+ `7bit` — līdz 998 oktetiem rindā ar kodu no 1 līdz 127, kur ir atļauti tikai CR un LF (attiecīgi 13 un 10) kā daļa no CRLF rindas beigām. Šī ir vērtība pēc noklusējuma.
	+ `quoted-printable` — lieto, lai kodētu 8 bitu simbolus formā, kas apmierina *7bit* noteikumus. Paredzēts, ja dati pamatā sastāv no *US-ASCII* simboliem, bet ir arī neliels daudzums baitu, kuru kodi ir virs 127.
	+ `base64` — lieto, lai kodētu 8 bitu simbolus formā, kas apmierina *7bit* noteikumus. Pamatā izmanto 8 bitu neteksta datiem, bet reizēm arī teksta datiem, kuros bieži ir ne *US-ASCII* simboli.
* izmantojami *SMTP* serveriem, kas atbalsta *8BITMIME SMTP* paplašinājumu:
	+ `8bit` — līdz 998 oktetiem rindā, kur ir atļauti tikai CR un LF (attiecīgi 13 un 10) kā daļa no CRLF rindas beigām.
* izmantojami *SMTP* serveriem, kas atbalsta *BINARYMIME SMTP* paplašinājumu (RFC 3030):
	+ `binary` — jebkurā oktetu secībā.

Kodētie vārdi
-------------

Pēc RFC 2822 standarta sūtījuma galvenes nosaukumiem un vērtībām vienmēr jābūt ar ASCII simboliem; vērtībām, kuras satur ne ASCII datus, jālieto MIME kodēto vārdu sintaksi (RFC 2047). Šī sintakse izmanto ASCII simbolus, ar kuriem parāda gan oriģinālo rakstzīmju kopu (*charset*), gan satura pārkodēšanas shēmu, kas parāda, kādā veidā simboli tikuši pārkodēti ASCII kodējumā.

Formāts ir: "`=?rakstzīmju kopa?kodējums?pārkodētais teksts?=`".

* rakstzīmju kopa var būt jebkura, kas reģistrēta IANA. Parasti tā ir tā pati, kas izmantota vēstules ķermenī.
* kodējums var būt vai nu "Q" (Q-kodējums jeb *quoted-printable* kodējums) vai "B" (base64 kodējums).
* pārkodētais teksts ir attiecīgi Q-kodējumā vai *base64* kodējumā.

Kodētajā vārdā jautājuma zīme "?" un vienādības zīme "=" ir rezervētie simboli, tad tie ir jāpārveido citādi. Arī atstarpes rakstzīmi nevar tieši attēlot, jo vecāki parseri var nevēlami sadalīt vārdu. Lai samazinātu pārkodēto tekstu un padarītu to vieglāk lasāmu, atstarpe tiek aizvietota ar pasvītrojuma rakstzīmi, bet līdz ar to pasvītrojumu nevar tieši attēlot.

Piemērs:

```
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=
```

ko var interpretēt kā "*Subject: ¡Hola, señor!*".

Kodēto vārdu formātu nevar izmantot galvenes nosaukumam (piem. `Subject`). Galvenes nosaukumi vienmēr ir angļu valodā. Ja tiek skatīta vēstule ar citas valodas e-pasta klientu, tad galvenes nosaukumus klienta programma var parādīt pārtulkotus, ja tai ir tāda funkcija.

Vairākdaļu sūtījumi
-------------------

MIME vairākdaļu sūtījuma `Content-type:` galvenē ir jānorāda robežatdalītājs `boundary`. Šai simbolu virknei nav jāparādās nevienā no vēstules daļām, tā atrodas starp daļām, ka arī sūtījuma ķermeņa sākumā un beigās. Piemēram:

```
MIME-version: 1.0
Content-type: multipart/mixed; boundary="frontier"

This is a multi-part message in MIME format.
--frontier
Content-type: text/plain

This is the body of the message.
--frontier
Content-type: application/octet-stream
Content-transfer-encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--
```

Katra daļa sastāv no pašas satura galvenes (neviens vai vairāki `Content-` galvenes lauki) un ķermeņa. Vairākdaļu saturs var būt ligzdojams. `Content-Transfer-Encoding` jābūt `7bit`, `8bit` vai `binary`. Vairākdaļu blokam kā veselam nav rakstzīmju kopas, no ASCII atšķirīgi simboli daļas galvenē tiek pārveidoti pēc kodēto vārdu sistēmas, un daļas ķermenim ir rakstzīmju kopa, kas noteikta satura tipā (`content-type`.

Piezīmes:

* pirms pirmā robežatdalītāja atrodas zona, kuru ignorē MIME atbalstoša klientprogramma. Šī zona parasti paredzēta, lai informētu lietotājus, kuri izmanto vecus ne MIME klientus.
* vēstules sūtītāja klientprogramma pati izvēlas robežatdalītāju, kurš nekonfliktē ar ķermeņa tekstu. Parasti to veido no garas gadījumsimbolu virknes.

### Vairākdaļu apakštipi

MIME standarts paredz dažādus vairākdaļu sūtījuma apakštipus, kuru raksturo vēstules daļas un to saistību vienai ar otru. Apakštipu norāda visa sūtījuma `Content-Type` galvenē. *RFC* sākotnēji definēja četrus apakštipus: `mixed`, `digest`, `alternative` un `parallel`. Minimālā prasība pasta programmām ir tāda, ka tām jāatbalsta `mixed` un `digest`, citi apakstipi nav obligāti. Citi apakštipi tika definēti vēlāk.

Zemāk ir apskatīti biežāk lietotie apakštipi.

#### Mixed

`Multipart/mixed` tiek lietoti, lai sūtītu failus ar iekļautām dažādām `Content-Type` galvenēm (jeb kā pievienojums). Ja tiek pārsūtīti attēli vai citi viegli lasāmi faili, vairums mūsdienu klientprogrammu var tos attēlot iekļautajā skatītājā. Citādi tie tiks piedāvāti kā pievienojumfaili. Pēc noklusējuma satura tips katrai daļai ir `text/plain`

Definēts RFC 2046, sekcija 5.1.3

#### Digest

`Multipart/digest` ir vienkāršs veids, kā sūtīt saliktas teksta vēstules. Pēc noklusējuma satura tips katrai daļai ir `message/rfc822`

Definēts RFC 2231, sekcija 5.1.5

#### Alternative

`Multipart/alternative` rāda, ka katra daļa ir "alternatīva" versija vienam un tam pašam (vai līdzīgam) saturam, katra dažādā formātā, kas noteikts tās `Content-Type` galvenē. Šis formāts ir paredzēts, lai formatētam saturam līdzi tiktu "dots" arī oriģināls, ar "uzticamāko" (vienkārša teksta variantā) vispirms, un "mazāk uzticamo" beigās. Sistēma attēlošanai izvēlas labāko sūtījuma daļu, ja labāko daļu klientprogramma nespēj apstrādāt, tiek parādīta vienkāršākā daļa. Tas dod iespēju vēstuli vienkāršāk izlasīt lietotajiem, kuru klienti neatbalsta vairākdaļu sūtījumus.

Visbiežāk alternatīvo veidu izmanto HTML e-pasta sūtīšanai. To sagatavo no divām daļām: pirmajā ir vienkāršais teksts (`text/plain`), otrajā ir teksts, formatēts HTML (`text/html`). Ja klients neatbalsta HTML formatēšanu, tas parādīs vēstuli kā vienkāršu tekstu, HTML atbalstošs parādīs līdzīgu kā HTML lapu.

Definēts RFC 2046, sekcija 5.1.4

#### Related

`Multipart/related` izmanto, lai informētu, ka sūtījuma daļas nav jāapskata individuāli, bet gan ka tās ir daļas no viena vesela. Vēstule sastāv no "saknes" daļas (pēc noklusējuma pirmās), kas norāda uz citām iekļautajām daļām, kuras savukārt var saistīt citas daļas. Sūtījuma daļas parasti saista ar daļas galveni `Content-ID`. Atsauces sintakse nav noteikta, un to nosaka atkarībā no kodējuma vai protokola, kuru izmanto saistāmajā daļā.

Šo apakštipu plaši izmanto, lai sūtītu vēstuli kā tīmekļa lappusi kopā ar attēliem. Saknes daļai jāsatur HTML dokuments, un tajā ietvertie attēlu tagi atsaucas uz attēliem, kas ir saglabāti nākamajās daļās.

Definēts RFC 2387

#### Report

`Multipart/report` ir sūtījuma tips, kas paredzēts e-pasta servera informēšanai. Tas ir sadalīts divās daļās, no kurām viena ir `text/plain` (vai cits viegli lasāms satura tips), bet otra ir `message/delivery-status`, kura satur īpaši e-pasta serverim formatētus datus.

Definēts RFC 3462

#### Signed

`Multipart/signed` lieto, lai sūtījumam pievienotu ciparu parakstu. Tas sastāv no divam daļām: ķermeņa daļas un paraksta daļas. Ir iespējami daudzi paraksta tipi, piemeram, `application/pgp-signature`, `application/x-pkcs7-signature`.

Definēts RFC 1847, sekcija 2.1

#### Encrypted

`Multipart/encrypted` izmanto, lai sūtītu šifrētu vēstuli. Pirmā daļa satur kontrolinformāciju, kas nepieciešama, lai atšifrētu `application/octet-stream` otro daļu.

Definēts RFC 1847, sekcija 2.2

#### Form Data

`Multipart/form-data` ir paredzēts vērtību nosūtīšanai ar formas palīdzību. Sākotnēji tas ir definēts kā daļa no HTML 4.0, un tiek plaši lietots, lai nodotu failus ar HTTP.

Definēts RFC 2388

Atsauces
--------

RFC 1426SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. February 1993.
RFC 1847Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 2045MIME 1. daļa: Format of Internet Message Bodies.
RFC 2046MIME 2. daļa: Media Types. N. Freed, Nathaniel Borenstein. November 1996.
RFC 2047MIME 3. daļa: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.
RFC 4288MIME 4. daļa: Media Type Specifications and Registration Procedures.
RFC 4289MIME 4. daļa: Registration Procedures. N. Freed, J. Klensin. December 2005.
RFC 2049MIME 5. daļa: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
RFC 2231MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
RFC 2387The MIME Multipart/Related Content-type
RFC 1521Mechanisms for Specifying and Describing the Format of Internet Message Bodies

Ārējās saites
-------------

* IANA reģistrēto MIME mediju tipu saraksts
* Rakstzīmju kopu saraksts
* Detalizētāks MIME apskats (1993)
* Pareizi konfigurēta servera MIME tipi
* W3 School's Multimedia MIME Reference
* Open Source C++ Mime Email Parser

|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 

| * s
* d
* l
Elektroniskais pasts |
| --- |
|  |
| Formāts | 
* e-pasta adrese
* MIME
* HTML e-pasts

 |
|  |
| Protokoli | 
* IMAP
* LMTP
* POP3
* SMTP
* UUCP

 |
|  |
| Vēstuļu aģenti | 
* MDA
* MSA
* MTA
* MUA

 |
|  |
| Klienti | 
* *Eudora Mail*
* *Evolution*
* *Fidolook*
* *Foxmail*
* *KMail*
* *Microsoft Outlook*
* *Mozilla Thunderbird*
* *Opera Mail*
* *Outlook Express*
* *The Bat!*
* *Sylpheed-Claws*

 |
|  |
| Serveri | 
* Sendmail

 |

 |