Tekenset
Vanwege de eenvoud van het Amerikaanse alfabet is een codetabel met 128 tekens voldoende om hun gehele tekenset te kunnen omvatten, inclusief nog ruim dertig stuurcodes als DEL
Extended-ASCII
Het Internet en de privé netwerken zoals de LAN's in de kantooromgevingen waren gedurende lange tijd volkomen gescheiden zaken, met ieder hun eigen standaards. Deze standaards waren vaak niet uitwisselbaar, hetgeen tot veel problemen kon leiden. Zo zijn er ook verschillende, zogenaamde "proprietary" e-mail standaards geweest, bijvoorbeeld voor Lotus cc:mail en PROFS OfficeVision. E-mail uitwisseling werd daarmee vaak beperkt tot de eigen bedrijfsomgeving. Toepassingen in LAN-omgevingen zijn in oorsprong gebaseerd op 8-bits codepagina's, zoals Extended-ASCII. Met één bit meer in de karaktertabel werd de omvang twee maal zo groot, van 128 tot 256 tekens. Ruimte genoeg om ook de tekens in de meeste andere westerse talen te kunnen bevatten. Voor onze eigen taal zijn dat bijvoorbeeld de tekens é, ë, ï, ƒ etc. Je hoeft niet lang na te denken wat dat betekent voor talen als Frans, Zweeds en Duits. Documenten geproduceerd met MS-Office worden dan ook in 8-bits formaat opgemaakt, net als vele andere bestanden in bijvoorbeeld .bmp, .jpg, .mp3 formaat.
SMTP is van oorsprong gebaseerd op 7-bits transport en dat is daarna nooit meer aangepast. Je zou natuurlijk een 8-bits SMTP service kunnen ontwikkelen en die zou het nog doen ook. Het probleem is dat het hele Internet al is vergeven van de 7-bits servers en die begrijpen niets van 8-bits communicatie. Om van 8-bits data gewoon het achtste bit af te knippen en er zo toch de SMTP tunnel mee in te kunnen biedt weinig hoop: je data zou hopeloos verminkt raken, behalve wanneer het achtste bit alleen een pariteitsbit voorstelt. (Pariteit wordt bij asynchrone transmissie nogal eens toegepast). Om toch bestandsonderdelen, geproduceerd in 8-bits of meer (16-bits UNICODE) te kunnen meezenden met het 7-bits transport van SMTP is er een tussenoplossing bedacht: MIME (Multipurpose Internet Mail Extensions).
Is het dan zo belangrijk om 8-bits data anders te behandelen dan 7-bits data? De SMTP service probeert steeds karakters individueel te interpreteren; kijk maar naar de betekenis van de (7-bits) punt aan het einde van een transmissie. Als de karakters steeds een bit langer zijn loop je al snel uit de pas en gaat de betekenis van een karakter verloren. Er moet dus een methode worden bedacht waarmee de betekenis van 8-bits gegevens behouden kan blijven.
MIME bekijkt de eigenschappen van het oorpronkelijke attachment en maakt een keuze voor de manier waarop deze wordt geconverteerd naar 7-, of zelfs 6-bits representatie. MIME doet dit met behoud van alle informatie van het oorspronkelijke bestand in zogenaamde X-MIME-headers in het e-mailbericht. MIME is een uitbreidbare standaard, zodat ook steeds de laatste bestandsformaten kunnen worden ingepast. Een voorbeeld is het gebruik van S/MIME, waarmee digitale handtekeningen, encrypted mail en gebruikerscertificaten kunnen worden geconverteerd en meegezonden.
Conversie
Voor het omzetten van 8-bits naar 7- of 6-bits data gebruikt MIME een drietal verschillende methoden. Afhankelijk van de samenstelling van het brondocument en de instellingen op de zendende server zijn dat:
- 7-bits encoding
- Quoted-Printable encoding
- Base-64 encoding
Bij Quoted-printable encoding bevinden zich in het brondocument naast 7-bit karakters ook 8-bits tekens. Het merendeel van de -meestal tekst- documenten bestaat uit tekens die zowel in de 7- als de 8-bits ASCII tabel voorkomen; de gewone letters en leestekens komen in beide tabellen voor en kunnen zonder moeite worden uitgedrukt in hun 7-bits equivalent. De incidentele 8-bits tekens ondergaan een speciale behandeling:
Het 8-bits teken wordt eerst uitgedrukt in Hex-notatie. Elk teken uit de extended ASCII tabel heeft een positie tussen 00000000 en 11111111 (0 - 255). Voor een teken, bijvoorbeeld de ë (e-trema), dat zich voor de Nederlandse codepagina bevindt op positie 137 is dat 10001001. Hexadecimaal wordt dat 89 (1000 1001). De cijfers 8 en 9 zijn weer gewoon terug te vinden in de 7-bits ASCII tabel, maar om te voorkomen dat er bij de omzetting aan de ontvangende kant het getal '89' in de tekst komt te staan wordt er een quote in de vorm van een '=' voor het getal geplaatst: '=89'. De markering wordt eruit gepikt en 89 wordt weer vervangen door 'ë'. Mocht er in de oorspronkelijke tekst een reeks tekens voorkomen die al vooraf wordt gegaan door een "=", bijvoorbeeld bij een sommetje als "5x8=40", dan wordt er een extra "=" voor de uitkomst geplaatst, zodat deze niet per abuis wordt aangezien als quoted-printable codering. Dat zou er dan uitzien als "5x8==40".
Veel moderne e-mail servers maken tegenwoordig de message-body op in zowel 7-bits plain tekst als in HTML. Ook HTML is deels opgebouwd uit 8-bits codes, waardoor een bericht er als volgt kan uitzien: (Geopend in een POP3 dialoog)
Base-64 encoding tenslotte pakt de zaak heel anders aan: hier wordt het gehele 8-bits attachment herschikt naar 6-bits representatie. (... is kleiner dan 7-bits, dus past in de SMTP pijplijn ...). Deze conversie wordt toegepast op bestanden die geheel uit 8-bits data zijn opgebouwd, zoals afbeeldingen (.bmp, .jpg), binaire bestanden (.zip, .exe etc.) of A/V bestanden. Het is een zaak van efficiency, want de conversie levert uiteindelijk minder extra bits op dan bij Quoted printable, waar voor een 8-bits teken 3x7 = 21 bits in de plaats komen. Base-64 gebruikt een meta-tabel voor het coderen van 6-bits karakters. In het volgende voorbeeld gaan we eerst een plaatje, opgebouwd uit vier pixels, van 8 naar 6 bits omzetten. Daarna laten we een wat groter voorbeeld zien. Hier is eerst het 'bitmapje':
26 Hoofdletters
26 Kleine letters
10 Cijfers
-----------------
62 tekens
We komen er nog twee tekort om aan de 64 te komen; daarvoor worden de "+" en de "/" toegevoegd. Een stukje van deze base-64 tabel ziet er als volgt uit:
Deze string bestaat uit 16 tekens van 6-bits, bij elkaar 96 bits. Evenveel als 12 tekens van 8 bits; we zijn geen informatie kwijtgeraakt! Een willekeurig aantal 8-bits tekens zal lang niet altijd een afgeronde reeks 6-bits groepjes opleveren. Daarvoor worden aan het einde van de brondata extra nullen tussengevoegd om op een afgerond veelvoud van 6 uit te komen. (Bit-stuffing). In werkelijkheid zijn plaatjes natuurlijk veel groter, wat een veel langere brij van schijnbaar betekenisloze code oplevert. Naast afbeeldingen worden ook andere bestandstypen volgens dit schema omgezet voor transport. Bij gebruik van S/MIME gaan zelfs digitale handtekeningen en certificaten op deze manier mee in de verpakking.
Separators
Verzending van e-mail vindt serieel plaats; de bits worden achter elkaar over het medium verzonden. Eerst de RFC 821 envelop, dan de RFC 822 memo-header, body en eventuele attachments. Binnen een paar seconden is een e-mailbericht met tekst en foto's in cyberspace onderweg. Als een bericht uit zoveel onderdelen bestaat (meer dan één attachment) wordt in de header aangegeven dat het MIME type "multipart/mixed" is. De verschillende onderdelen van het e-mailbericht worden van elkaar gescheiden door separators; een opvallende string met een identifier die bovenin het bericht wordt opgegeven. Bij ontvangst geven deze separators het einde van een attachment en het begin van het volgende attachment aan. Dit is nodig omdat verschillende attachments niet alleen afkomstig zijn van afzonderlijke bestanden (met naam en omschrijving) maar ook omdat verschillende coderingen door elkaar gebruikt worden en pér attachment een andere behandeling kunnen vereisen. Zo'n separator ziet er als volgt uit:
De separator bestaat in bovenstaand voorbeeld uit de tekens: "_____ax2s800001rfs@mydomain.com" en wordt steeds als een soort boekenlegger tussen de compartimenten van het e-mailbericht geschoven. Een separator wordt voor ieder bericht random gegenereerd (soms meerdere verschillende per bericht) en heeft per type e-mail server een ander algemeen uiterlijk. De uitbreiding "@mydomain.com" volgt meestal wel aan het einde van de separator, met daarin natuurlijk de naam van het eigen SMTP domein waartoe de server behoort. Een gebruiker ziet deze details bij het lezen van e-mail niet, omdat de server dit als stuurcodes gebruikt. Met wat moeite (Tools/options) in Outlook kun je een deel van deze informatie terugvinden. Een heel bericht op deze manier bekijken kan alleen met gebruik van Telnet, als je een POP3 sessie opent naar de server, inlogt en een bericht met RETR n ophaalt naar het scherm. Meer hierover in een artikel over POP3 ...
De MIME-documentatie bestaat uit de volgende RFC's:
RFC 2045 , RFC 2046, RFC 2047, RFC 4288 , RFC 4289, RFC 2049
(Situatie per 30-11-2009)
Geen opmerkingen:
Een reactie posten