Henri Sivonen, korkeakouluharjoittelija, Kansallisarkisto
Henri Sivonen on laatinut tämän dokumentin Kansallisarkistossa kesällä 2002. Dokumentti sisältää Sivosen Kansallisarkistolle esittämän näkemyksen. Dokumentti ei välttämättä edusta Kansallisarkiston kantaa (eikä välttämättä edes Sivosen nykyistä kantaa).
Lait tai säädökset saattavat joissain tapauksissa edellyttää sähköpostiviestien arkistointia. Sekä [MoReq] että [DoD] edellyttävät valmiutta arkistoida sähköpostiviestejä tai pikemminkin niiden kokoelmia. Vaikka sähköpostiviestit ovat lähtökohtaisesti digitaalisia ja viestien otsakkeissa on metadataa valmiina, sähköpostien arkistointiin liittyy silti lukuisia ongelmia:
Unixin perinteinen Berkeleyn mbox-formaatti[mbox] on yleisin kokoelmaformaatti sähköpostitiedostoille. Siinä postilaatikollinen viestijä tallennetaan yhteen tiedostoon. Käytännössä kaikki Unixin kaltaisilla järjestelmillä toimivat sähköpostiohjelmat osaavat lukea sitä ja monet käyttävät sitä myös natiiviformaattinaan. Eudoran Macintosh- ja Windows-versiot käyttävät mbox-formaattia sillä muutoksella, että rivinvaihdot ovat järjestelmän käytännön mukaisia eivätkä Unix-käytännön mukaisia. Jotkin ohjelmat (mm. Netscape Messenger, Apple Mail, Eudora) käyttävät omia hakemistorakenteitaan toiminnan nopeuttamiseksi, mutta nämä apurakenteet voidaan luoda varsinaisesta mbox-tiedostosta. Jotkin ohjelmat pitävät liitteet mbox-formaatissa mutta toiset irrottavat liitteet erillisiksi tiedostoiksi.
Joidenkin postituslistojen arkistot ovat saatavilla mbox-formaatissa.
mbox-formaatin etu on se, että monien ohjelmien postilaatikot ovat jo valmiiksi mbox-muodossa ja mbox-tiedostoja voidaan selata tavallisilla sähköpostiohjelmilla.
mbox-formaatissa viestierottimena toimii rivi, joka alkaa ”From”. mboxista on muutamia variantteja, joiden erona on viestissä esiintyvien ”From”-alkuisten rivien käsittely. Yleesnä ”From”-alkuisten rivien alkuun lisätään merkki (väli tai >).
maildir on kehitetty mbox-formaatin luotettavuusongelmien ratkaisemiseksi.[maildir] mboxin luotettavuusongelmat liittyvät samanaikaisuuden hallintaan postilaatikon sisältöä muutettaessa. Niillä ei ole vaikutusta, jos mbox-formaattia käytetään arkistossa siten, että postilaatikkoa luetaan yhdestä prosessista käsin.
maildir-formaatissa viestit tallennetaan erillisinä tiedostoina. maildir ei ole sama kuin Netwaren ja Pegasus Mailin käyttämä tallennustapa. Nimeämiskäytäntö on eri. Arkistoon voitaisiin formaatiksi määritellä se, että postilaatikko on hakemisto, jossa on miten tahansa uniikisti nimettyjä tiedostoja, joista jokainen sisältää yhden viestin. Tällöin tavallinen maildir-formaattia lukeva ohjelma ei kuitenkaan sellaisenaan kelpaisi katseluohjelmaksi.
On oletettavissa, että mbox pakkautuu zip-tiedostoon hieman paremmin kuin maildir.
mbox ja maildir taltioivat viestejä niiden luonnollisessa RFC 822- tai MIME-formaatissa. Kaikki sähköpostijärjestelmät eivät ole natiivisti MIME-järjestelmiä. Jos viestit eivät jo ole MIME-formaatissa, niille pitää tehdä muunnos MIME-formaattiin. Käytännössä kaikista sähköpostijärjestelmistä on nykyään olemassa MIME-yhdyskäytävät, joiden muunnosmenetelmiä voidaan pitää tarkoitukseen riittävän hyvinä.
Viestien taltioimiseen voitaisiin kehittää muitakin formaatteja. Voitaisiin kehittää esim. XML-pohjainen formaatti, joka esittäisi samat asiat kuin MIME, mutta joka olisi jäsennettävissä XML-jäsentimellä. Tällöin säästyttäisiin MIME-jäsentimen ylläpidolta lukutarkoitukseen. MIME-jäsennintä tarvitsisi ylläpitää vain arkistoon ottoa varten. Kuitenkin arkistoformaateille asetetut yleisyyskriteerit puoltavat MIME-formaatin käyttöä.
Joskus Internet-sähköpostissakin voi vielä nykyäänkin saapua RFC 822 -muotoisia viestejä, jotka eivät ole MIME-viestejä. Arkistointimenettelyn yhtenäisyyden vuoksi nämäkin kannattanee muuntaa MIME-viesteiksi. Joissain tapauksissa muutos on jo tehty automaattisesti postin välityksen yhteydessä. Viralliseti epä-MIME-viesteissä ei saa käyttää kuin ASCII:ta. Kuitenkin epä-MIME-viestien koodaus saattaa olla ISO-8859-1. Käytännössä lienee turvallisinta käsitellä epä-MIME-viestejä kuten niiden koodaus olisi Windows-1252.
Käytännössä kaikki suomalaisten suomen, englannin tai ruotsinkieliset sähköpostiviestestit on koodattu jollain seuraavista merkkikoodauksista (character encoding, MIME ”charset”):
Kuitenkin kirjeenvaihto joillain muilla kielillä (mm. kreikalla tai ehkä tulevilla EU-kielillä) saatetaan yleensä suorittaa muita koodauksia käyttäen siitäkin huolimatta, että merkit voitaisiin esittää UTF-8:lla. Jos halutaan tukea muitakin kuin tavallisia suomen, englannin ja ruotsinkielisessä viestinnässä käytettyjä koodauksia, tuettavien koodausten määrä kasvaa huomattavasti. Euroopassa käytettyjen 8-bittisten koodausten tukeminen on kuitenkin kohtuullisen suoraviivaista, kunhan kuvaus koodauksesta Unicodeksi on saatavilla Unicode Consortiumilta.
Koodausten tukemiseen voidaan löytää ainakin kolme mahdollista strategiaa:
Valinnoissa vastakkain ovat pitkäaikaissäilytyksen ja lukemisen suoraviivaisuus ja toisaalta viestien säilyttäminen mahdollisimman alkuperäisinä.
Lisäksi automaattisen konversion tuloksena saattaa esiintyä erikoiskoodaus unknown-8bit, joka ei ole mikään tietty koodaus. (RFC 1428) Tällöin koodaus pitää arvata tai päätellä. Ks. jäljempänä kohta tekstiliitteistä.
MIME:ssä lähtödata on luokiteltu kolmeen luokkaan: 7bit (riviorientoitunutta tekstiä, jossa tavun kahdeksas bitti on käyttämätön), 8bit (riviorientoitunutta tekstiä, jossa tavusta käytetään kaikki bitit merkityksellisinä) ja binary (tavuvirta, jonka ei tarvitse olla riviorientoitunut).
Entisaikojen sähköpostinvälitysjärjestelmät kykenivät välittämään vain 7bit-luokkaan kokonaisuudessaan kuuluvia viestejä. Nykyisin 8bit on myös turvallista Internet-sähköpostissa. Sen sijaan binary-luokan dataa ei edelleenkään ole tapana lähettää sellaisenaan sähköpostissa.
MIME-määrityksissä esitetään kaksi transformaatioalgoritmia, joilla 8bit- ja binary-luokkiin kuuluvat tavujonot voidaan koodata vain 7bit-luokaan kuuluvia merkkejä käyttäen. Nämä koodaukset ovat quoted-printable ja base64. Yleensä quoted-printablea käytetään silloin, kun halutaan koodata luokan 8bit dataa ja base64:ää käytetään, kun halutaan koodata luokan binary dataa. Jotkin postiyhdyskäytävät muuntavat omin päin 8bit-datan quoted-printableksi ja päinvastoin. Binary-luokan data on tapana koodata base64:lla alunalkaen ja välitetään yleensä perille asti koodausta muuttamatta.
Quoted-printable ja base64 ovat kumpikin hyvin yksinkertaisia koodauksia eikä niiden tukeminen arkistossa ole ongelma dekoodausvalmiuden ylläpidon kannalta. Erilaiset koodaukset lähinnä vaikeuttaisivat tekstihakuja ja lisäisivät tallennustilavaatimuksia. (Base64-koodaus kasvattaa tiedostojen kokoa noin 33%!) Toisaalta, jos liitteet käsitellään erikseen, ei ole oikein tarpeellista pitää arkistodataa base64-koodattuna. Datan arkistointi quoted-printablena taas ei tuo juurikaan todistusarvoetua verrattuna datan arkistointiin 8bit-muodossa. Vastaanottajalle tullut muoto ei kuitenkaan ole välttämättä sama kuin lähettäjän sähköpostiohjelmasta lähtenyt koodaus, ja quoted-printable on vain datan koodaustapa eikä sillä sinänsä pitäisi olla mitään merkitystä sisällön kannalta.
Nykyiset mbox-lukuohjelmat sallivat 8bit-datan mbox-tiedostoissa.
Ehdotan, että arkistoonvientiä tukevissa ohjelmissa tuetaan quoted-printablen ja base64:n lisäksi myös uuencode- ja BinHex 4.0 -koodauksia, mutta ettei näitä koodauksia päästetä AIP:iin asti, jottei niitä tarvitsisi tukea myöhemmin arkistojen selausohjelmissa.
MIME sallii viestirungon lähettämisen muussakin muodossa kuin text/plainina. Jotkin ohjelmat tukevat text/enriched-formaattia. Nykyisin monet sähköpostiohjelmat voivat lähettää ja esittää text/html-viestirunkoja. Suuri osa näistä ohjelmista on konfiguroitu oletusarvoisesti siten, että teknisesti tietämätön käyttäjä saattaa lähettää text/html-viestirungon mahdollisia yhteensopivuusongelmia erikseen tiedostamatta. Onneksi oletusarvoisesti text/html:n lisäksi lähetetään yleensä kuitenkin myös text/plain-versio. Sen sijaan text/enriched on tapana lähettää ilman text/plain-vaihtoehtoa.
Text/html-viestirungot ovat tyypillisesti epävalideja ja rakenteeltaan köyhiä. Yleensä tavalliset käyttäjät jaksavat muuttaa fontin korostuksia (lihavointi, kursivointi, väri) ja mahdollisesti fontin kokoa (täysin tarpeettomasti). Muita HTML:n ominaisuuksia esiintyy lähinnä mainoksissa ja Webistä kopioiduissa WWW-sivuissa. (Jotkin selaimet sallivat WWW-sivun lähettämisen toiselle käyttäjälle sähköpostissa. Siitäkin huolimatta, että pelkän URL:in voisi lähettää.) Kuvat paketoidaan viestiin mukaan MHTML-määrityksen (RFC 2557) mukaan.
On mahdollista, että viestissä on text/html-rungon lisäksi vaihtoehtoinen text/plain-runko. Tyypillisesti text/html-viestejä lähettävissä ohjelmissa on oletusarvona sekä text/html:n että text/plain:in lähettäminen. Yleensä vaihtoehtoinen versio on lähettäjän sähköpostiohjelman automaattisesti generoima eikä lähettäjä ole edes varmistanut konversion laatua.
Text/html-rungoille tyypillinen huono tekninen laatu tekee niistä mm. arkistoinnin kannalta epätoivottavia. Niitä ei voi lukea vain virheetöntä HTML:ää tukevalla ohjelmalla. Lukemiseen tarvitaan tägisoppaa lukeva ohjelma. Lähestymistapoja on kolme yleistä: nykyaikaisen täyden WWW-selaimen layout enginen käyttö (Outlook, Netscape 6 ja 7 Mail, Mozilla Mail), vanhanaikaisen rajoittuneen layout enginen käyttö (Apple Mail) ja yksinkertainen vain kappaleiden, rivinvaihtojen, lohkolainausten ja yksinkertaisten korostusten tunnistaminen (Eudora, Pegasus Mail, pine). Jos text/html:ää halutaan arkistoida, pitäisi ylläpitää tägisoppaa edes jälkimmäisen lähestymistavan verran tukevaa lukuohjelmaa.
Monesti lainausmenettely on hyvin kömpelö text/html-viesteissä. Looginen valinta lainausten ilmaisemiseen olisi <blockquote>-elementti, mutta jotkin text/html-soppaa generoivat ohjelmat (esim. Outlook Express, Netscape Messenger ja Mozilla Mail) käyttävät <blockquote>-elementtiä yleiseen sisentämiseen. Lainaus saatetaan ilmaista esim. <blockquote>-elementillä, jonka style-attribuutin avulla on muutettu elementin esitystä CSS:llä tai jolla on epästandardi type="cite" -attribuutti. Sisennys-<blockquote> ja lainaus-<blockquote> eivät kuitenkaan erotu kaikissa tapauksissa. Niinpä jotkin text/html-soppaa lähettävät sähköpostiohjelmat, kuten Outlook Express, eivät tue text/html-viesteissä Internet-viestinnän hyväksyttyä lainaustapaa muistuttavaa lainaamista, vaan lisäävät edellisen viestin kokonaisuudessaan vastauksen loppuun erottimen alapuolelle. (Ainakaan en itse keksinyt, miten Outlook Expressillä kirjoitetaan lainatun text/html-viestin sekaan lisää tekstiä siten, ettei uusi teksti näytä lainatulta.) Lainausongelmien vuoksi text/html-viesteistä ei välttämättä voida ohjelmallisesti tunnistaa lainattuja osia.
Eräs keino text/html:n arkistoinnin välttämiseen on se, että pidetään vaihtoehtoisia text/plain-runkoja niin hyvin informaatiosisällön esittävinä, että arkistoidaan vain ne. Viestin vastaaottajakin olisi saattanut nähdä vain text/plain-version (sähköpostiohjelmasta ja ohjelman asetuksista riippuen). Silloin ongelmaksi jäisivät vain ne viestit, joissa ei ollut text/plain-vaihtoehtoa mukana. Tosin esim. Outlook Express ja Netscape 4.x Messenger jättävät linkkien URL:it pois text/plain-versiosta! Niinpä näillä ohjelmilla kirjoitetuista viesteistä ei saada linkkien URL:eja talteen text/plainina, ellei muunnosta tehdä itse. Taas esim. Mozillan kohdalla konversiota ei kannata tehdä itse, koska Mozillan itsensä tuottama text/plain-versio on parempi kuin esim. lynx -dump:illa tehty versio. Toki konversion voisi tehdä Mozillalla, mutta Mozillan valjastaminen konvertteriksi olisi työläämpää kuin Lynxin käyttäminen.
Kuvia sisältävät MHTML-viestit sisältävät sisäisiä viittauksia, jotka hajoavat, jos viestin osat dekoodataan liitteiden tavoin tavallisesti tiedostojärjestelmään erillisiksi tiedostoiksi. MHTML-viestejä ei voi siis syöttää suoraan WWW-selaimelle, joka ei osaa lukea MHTML-kokonaisuuksia yhdestä tiedostosta. MHTML-viestien lukemiseen on kolme menetelmää:
Jos katsotaan, että arkistoon riittää text/plainiksi konvertoitu versio, ensimmäinen menettely on riittävä. Jos kokonaisuudesta halutaan säilyttää muutakin, pitäisi tehdä konversio kunnolliseksi (X)HTML:ksi tai sitten tulostaa kuva jomman kumman jälkimmäisenä mainitun menetelmän avulla. Esim. Mozilla Mailista voisi ainakin teoriassa rakentaa työkalun, joka avaisi MHTML-viestin ja tulostaisi sen PostScriptiksi. En ole kuitenkaan ollenkaan vakuuttunut MHTML-viestien ulkonäön arkistoinnin tarpeellisuudesta, kun otetaan huomioon, millainen vaiva siitä koituisi.
Alkuperäisen tägisopan arkistoinnissa olisi riskinsä. Silloin säilyvyyden voisi määritellä siten, että viestien erilaiset ominaisuudet säilyvät jos säilyvät sikäli kuin lukuohjelma viestejä osaa lukea. Nykyiset MHTML:ää tukevat ohjelmat tukevat perusmuotoilun osalta aika hyvin toistensa tägisoppaa, mutta esim. taulukot saattavat mennä rikki yksinkertaisemmissa ohjelmissa. Kuitenkaan tulevien ohjelmien tuesta nykyiselle tägisopalle ei ole takeita.
Ehdotan, että viestirungot arkistoidaan vain text/plain-muodossa (tai text/plain; format=flowed -muodossa).
MHTML-toteutusten statuksta vuonna 2000 on käsitelty [MHTML-status]:ssä, joka tosin näyttää jääneen luonnosasteelle. Luonnoksessa ei käsitellä lainkaan viestien markupin validiutta tai tägien käytön ja niiden määritellyn merkityksen vastaavuutta (tai pikemminkin vastaavuuden puutetta).
Minimaalinen määritystä (RFC 1896) noudattava text/enriched-toteutus vain muuntaa rivinvaihdot sääntöjen mukaan ja poistaa muotoilukomennot parametreineen – siis tekee viestistä tavallista tekstiä siten, etteivät muotoilukomennot näy. Ehdotan, että text/enriched-viestit muunnetaan minimaalisella määrityksessä vaaditulla tavalla text/plain; format=flowed -muotoon (eli muunnetaan rivinvaihdot format=flowed -rivinvaihdoiksi ja poistetaan muotoilukomennot).
Sähköpostiliitteet ovat sikäli ongelmallisia, etteivät ne välttämättä tule jonkin arkistoivia asiakirjoja tuottavan viraston (tms.) omasta työnkulusta, vaan ne voivat tulla jostain täysin epäyhteensopivasta ulkoisesta lähteestä. Tämän vuoksi liitteiden käsittelyn automatisointi on vaikeaa, ja käsin tehtävä arkistointikin on todennäköisesti laadultaan hyvinkin vaihtelevaa sen mukaan, mitä työkaluja ja konversio-osaamista on käytettävissä.
Kun liite sattuu olemaan valmiiksi arkistoon hyväksytyssä formaatissa, lienee selvintä arkistoida se sellaisenaan, vaikka teoriassa onkin mahdollista, että tiedoston kirjoittanut ohjelma on ollut huono ja tiedostossa on vikoja, jotka vaikeuttavat tiedoston lukemista myöhemmin. Ainakin tavallisesti arkistoon oton yhdeydessä tehtävät formaattikohtaiset testit pitäisi siis tehdä. Jos testeissä havaitaan ongelmia, tiedosto on pakko tutkia tarkemmin ja konvertoida tapauskohtaisesti johonkin muuhun formaattiin sikäli kuin mahdollista. Yleensä arkistointi edes jossain muodossa on mahdollista, jos vastaanottaja on saanut tiedoston auki.
On kuitenkin mahdollista, että sähköpostin liitteenä saapuu tiedosto, jota kerta kaikkiaan ei osata avata mitenkään järkevästi. Tällöin sitä ei voida arkistoidakaan paitsi tavujonona, jonka sisältöä ei ymmärretä. (Ainakin teoriassa joku voi lähettää kiusallaan liitteenä satunnaista dataa.) Valinta siitä, heitetäänkö lukukelvottomat liitteet pois vai arkistoidaanko alkuperäiset tavut siltä varalta, että joskus tulevaisuudessa joku haluaisi käyttää aikaa juuri jonkin tietyn liitteen aukomiseen, riippuu kai lähinnä siitä, sallivatko tiettyä arkistointitilannetta koskevat lait, asetukset tai muut asetukset lukukelvottomien dokumenttien pois heittämisen.
Jos liite pääsee läpi JFIF-tiedostojen tavallisesta ingest-testistä, säilytetään tiedosto sellaisenaan. Jos ei pääse, vika on luultavasti sen verran vakava, ettei sitä voida korjata automaattisesti (paitsi ehkä siinä tapauksessa, että tiedosto on Photoshopista tallennettu CMYK-JPEG).
Jos liite pääsee läpi PNG-tiedostojen tavallisesta ingest-testistä, optimoidaan pakkaus pngcrush-ohjelmalla ja arkistoidaan kuva.
Jos liite pääsee läpi Group 4 TIFF -tiedostojen tavallisesta ingest-testistä, säilytetään tiedosto sellaisenaan.
Muunnetaan arkistoformaatiksi hyväksyttyyn bittikarttaformaattiin (esim. ImageMagickilla).
Kun pelkkää tekstiä esiintyy liitteinä, sen merkkikoodauksesta ei yleensä ole saatavilla luotettavaa ohjelmallisesti luettavaa tietoa. Myöskään ei tiedetä sitä, millä logiikalla rivinvaihtoja on käytetty. Virheiden välttämiseksi asia pitäisi antaa ihmisen selvitettäväksi.
Suomenkielisen tekstin kohdalla ASCII:n ulkopuolisista merkeistä yleisin on pikku-ä ja todennäköiset koodaukset ovat Windows-1252 (ja ISO-8859-1, joka on edellisen osajoukko), MacRoman, UTF-8, ISO-8859-15 ja UTF-16. UTF-16 on helppo erottaa muista. Jos koodaus ei ole UTF-16, katsotaan, miksi merkkikoodaukseksi tulkitsemalla pikku-ä näkyy oikein. Windows-1252:n (tai ISO-8859-1:n) ja ISO-8859-15:n erottamiseen toisistaan pitää tarkastella myös sitä, kummaksi koodaukseksi tulkitsemalla tulos on koodausten eroavaisuuksien kohdalla järkevämpi.
Pikku-ä -testi voitaisiin kyllä tehdä ohjelmallisesti, mutta testi olisi epäluotettava. Jos tiedostossa onkin vaikka englantia tai koodaus ei olekaan mikään odotetuista, arvauksen pohjalta tehdyt jatkotoimet voivat tuottaa vielä vaikeammin ymmärrettäviä tuloksia. Asia voitaisiin kyllä hoitaa siten, että tietokone tekisi arvauksen ja kysyisi ihmisoperaattorilta, onko arvaus järkevä.
Esimerkkejä pikku-ä:n virheellisistä ilmentymistä löytyy [charcode]:sta.
Rivinvaihtojen käytön tarkka analysointi edellyttäisi työkalua, joka esittäisi ihmiselle dokumentin eri tavoilla käsiteltynä ja kysyisi, mikä tavoista on järkevin.
Jos PDF:n sisäisistä luontiohjelmatiedoista löydetään hyväksi tunnetun ohjelman tunniste ja lisäksi dokumentti läpäisee tavallisen ingest-testin, arkistoidaan PDF sellaisenaan. Muussa tapauksessa pitäisi yrittää ihmisen valvomaa konversiota bittikartoiksi.
Ehdotan manuaaliseksi liitteidenkonvertointimenettelyksi sitä, että vastaanottaja työtehtäviensä ohessa liitteen avattuaan (käytettävissä olevalla ohjelmalla) tallentaa sen johonkin arkistoon hyväksyttyyn formaattiin käytettävissä olevan ohjelman sallimalla menetelmällä. Tällöin tullaan arkistoineeksi sitä, minkä vastaanottaja todella sai otettua vastaan, eikä välttämättä sitä, mitä lähettäjä yritti lähettää. Jos haluttaisiin arkistoida sitä, mitä lähettäjä lähetti, tarvittaisiin yhteistyötä lähettäjän kanssa.
Jos arkistointi halutaan tehdä siten, että voidaan todistaa, ettei vastaanottaja ole itse vaikuttanut arkistointiin (sähköpostit esim. arkistoidaan suoraan postipalvelimelta ennen kuin ne toimitetaan vastaanottajan postilaatikkoon), vastaavat konversiotoimet pitää teettää jollakulla toisella.
RFC 2046 sallii viestien pilkkomisen moneksi message/partial -viestiksi. Jos tällaisia viestejä esiintyisi, ne sisältäisivät todennäköisesti liitteitä. Siispä osittaiset viestit pitäisi arkistoon viennin yhteydessä yhdistellä, jotta liitteet voitaisiin käsitellä tavalliseen tapaan. Onneksi pilkottuja viestejä esiintyy erittäin harvoin, koska monet sähköpostiohjelmat eivät tue pilkottuja viestejä.
Lopputuloksena syntyy seuraavanlaisia yhdistelmiä:
Koska US-ASCII -merkkivalikoiman UTF-8 -esitys on sama kuin US-ASCII -esitys, arkistopostilaatikon kaikkia viestejä voidaan käsitellä kuten ne olisivat UTF-8 -koodattuja. US-ASCII:kin voitaisiin siis merkitä UTF-8:ksi, mutta US-ASCII -merkinnän käytöllä ainakin vältetään turha otsakkeiden muuttaminen silloin, kun lähtöviesti on jo US-ASCII:ta.
UTF-8 -muunnoksessa on olemassa teoreettinen riski. UTF-8 -koodaus pidentää merkkijonoja verrattuna 8-bittisiin koodauksiin. Jos viestissä on rivi, jonka pituus on lähellä sallittua maksimia, UTF-8-koodaus voisi pidentää rivin yli sallitun rajan. Riski on teoreettinen siksi, että viesteissä rivin mitta noudattaa yleensä suositusta ja on enintään 78 merkkiä pitkä. Jos suositusta on noudatettu, UTF-8 ei kasvata rivin kokoa yli 998:n tavun mittaiseksi. 998 tavun maksimi on kuitenkin etupäässä vanhojen siirtojärjestelmien tekninen rajoitus. Jos määritellään niin, että arkistossa rivi voi olla pidempi ja valitaan lukuohjelmat siten, ettei rivin pituudesta ole haittaa, ei UTF-8:ksi koodaaminen muodosta edes teoreettista ongelmaa.
[maildir] qmailin maildir-manuaalisivu. URL: http://www.qmail.org/man/man5/maildir.html
[mbox] qmailin mbox-manuaalisivu. URL: http://www.qmail.org/qmail-manual-html/man5/mbox.html
[MHTML-status] Sending HTML in E-mail – Status Report 2000. (luonnos) R. Hentze ja A. Muto. 2000. URL: http://dsv.su.se/jpalme/ietf/mhtml-testing/mhtml-status.txt
[charcode] A tutorial on character code issues. Jukka Korpela. 2001, päivitetty 2002. URL: http://www.cs.tut.fi/~jkorpela/chars.html
RFC 1896: The text/enriched MIME Content-type. P. Resnick ja A. Walker. IETF. 1996.
RFC 2822: Internet Message Format. P. Resnick (toim.). IETF. 2001.
RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed ja N. Borenstein. IETF. 1996.
RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed ja N. Borenstein. IETF. 1996.
RFC 2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. K. Moore. IETF. 1996.
RFC 2049: Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed ja N. Borenstein. IETF. 1996.
RFC 2646: The Text/Plain Format Parameter. R. Gellens (toim.). IETF. 1999.
RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed ja K. Moore. IETF. 1997.
RFC 2557: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann ja A. Hopmann. IETF. 1999.
Myös yllämainittujen edeltäjät (erityisesti RFC 822) saattavat olla olennaisia. Vaikka yllä näkyvät julkaisuvuosiluvut ovat suhteellisen viimeaikaisia, määritysten vanhat versiot ovat olleet olemassa jo niin kauan, että määritykset on toteutettu myös käytännössä laajalti.
RFC:t 1652, 2044, 1642, 1806, 1426, 2392, 2387, 1896 ja 1428. (RFC 1556 olisi olennainen, jos pitäisi käsitellä Lähi-Idän kieliä.)