Over MIME

Het Internet is een Amerikaanse uitvinding en zij gebruiken het Internet dan ook al bijna twintig jaar langer dan wij Europeanen en de rest van de wereld. Aanvankelijk was het bedoeld als een netwerk voor overheidsdiensten, zoals defensie en universiteiten. Medio jaren '80 werd het Internet overgedragen in handen van semi-onafhankelijke netwerk-operators zoals NSF en werd het netwerk verder ontsloten voor commercieel en particulier gebruik. Het duurde echter nog tot midden jaren '90 voordat we er in Nederland gebruik van konden maken.

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, BACKSPACE, ENTER, SPACE en ETX. Voor alleen letters en cijfers zijn 62 tekens voldoende en met een omvang van 128 posities kun je ook alle leestekens (!, ?, ", +, -, #, $, % etc.) gemakkelijk kwijt in de tabel. Deze Standard-ASCII tabel is opgebouwd uit 7-bits karakters en is jarenlang de basis geweest voor het onwikkelen van vele toepassingen en protocollen. Zo ook SMTP. Hieronder zie je een stukje van deze Standard-ASCII tabel:

Geheugenruimte was aanvankelijk kostbaar, dus elke besparing, al is het maar 1 bit per karakter, is meegenomen. Niet verwonderlijk dus, dat veel (programmeer)werk op deze 7-bits codes is gebaseerd.

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 7-bits encoding bestaat het brondocument al geheel uit 7-bits data, bijvoorbeeld omdat het is aangemaakt met een in 7-bits coderende plaintext-editor. Er hoeft aan het attachment niets te worden bijgeschaafd, behalve dat het als een apart compartiment van de message-body moet worden onderscheiden. Het attachment wordt tussen separators geplaatst en bovenin komen kenmerken als de oorspronkelijke bestandsnaam, het MIME hoofdtype en subtype, bijvoorbeeld "text/plain" en het encodingmechanisme: 7-bit. Bij de ontvangende server hoeft er niets te worden aangepast en alleen de client kan nu het attachment als een losstaand bestand van de message scheiden en apart opslaan, indien gewenst.

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':

Geen spannend plaatje, maar wat kun je anders met slechts vier pixels. Ieder beeldpunt of pixel (PIcture ELement) is uitgedrukt in 24-bits kleur, 8 bits voor respectievelijk de Rode, Groene en Blauwe kleurcomponent. Drie groepjes van 8 bits = 24 bits. Je kunt 24 ook door 4 delen en dan krijg je vier groepjes van 6 bits, als volgt:

Alleen de rangschikking is nu veranderd, maar er is geen informatie verloren gegaan. De groepjes van 6-bits worden nu vertaald langs een gedeelte van de Standard-ASCII tabel. Met 6 bits kun je maar 64 verschillende karakters uitbeelden dus we hebben maar een gedeelte van de tabel nodig:

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:

Zet de tekens op de juiste plaats en nu kunnen we begrijpen waarom zo'n klein plaatje er gecodeerd als volgt zal uitzien:

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)

Over SMTP (Simple Mail Transfer Protocol)

SMTP is het protocol waarmee e-mail wordt verzonden over het Internet. Het is de taal die wordt gesproken tussen de e-mail afzender (de client) en de Mail-server, die, zoals we zullen zien, op zijn beurt ook de rol van client vervult. De eerste server waar de client al de te verzenden mail aflevert om deze vervolgens te laten routeren naar de uiteindelijke bestemming is meestal die van de eigen Internet-provider of is een server die op de eigen zaak of soms ook thuis staat. Deze server is gewoonlijk in het e-mail programma vermeld als een vast gegeven in het veld "Outgoing mail (SMTP) server:" (Outlook Express).

Send-only

SMTP is een send-only protocol, dat wil zeggen dat het niet kan worden gebruikt om je e-mail van de server op te halen om het te lezen. De zendende server hoeft niet dezelfde te zijn als die waarop je mailbox zich bevindt. Voor het openen van je mailbox en het lezen van mail gebruik je een ander protocol, bijvoorbeeld POP3, of soms IMAP4.

Wanneer je Outlook (onderdeel van Microsoft Office®) gebruikt in een kantooromgeving dan zul je hiervoor vaak helemaal geen Internet protocol gebruiken maar het eigen MAPI interface van Microsoft. Outlook gebruikt deze methode voor communicatie met een Exchange Server in een LAN omgeving. De Exchange Server zal in dit geval zelf het SMTP verkeer met het Internet onderhouden.

Client/Server


In het bovenstaande stukje tekst worden de deelnemers in een SMTP-conversatie beschreven als client en server. Hiermee wordt niet alleen de dialoog tussen een Outlook Express gebruiker en een SMTP server bedoeld, maar ook de dialoog tussen twee SMTP-servers, in het geval van mail-forwarding. De SMTP-server die een sessie begint speelt ook de rol van client en de accepterende server die van "server". Het hangt dus af van de richting waarin de sessie verloopt, of beter; door wie de sessie wordt gestart. De client begint een conversatie altijd netjes met een groet; "Hallo, ik ben mail.acme.com". Het "helo" in de figuur links is geen schrijffout; commando's in SMTP worden zo kort mogelijk uitgedrukt, meestal in vier tekens, dus helo in plaats van hello.

(Korte) Historie


SMTP is niet de eerste versie van dit mail-protocol. Het wordt beschreven in RFC 821 (J.Postel, aug 1982) en is ontwikkeld uit eerdere varianten zoals MTP, Mail Transfer Protocol, RFC 772 (S. Sluizer & J. Postel, Sept. 1980). Na een aantal revisies is echter de essentie van het protocol sinds 1982 niet meer veranderd. De eenvoud van het protocol heeft hieraan zeker bijgedragen. Gedurende de jaren '80 en zelfs tot halverwege de jaren '90 is de tegenhanger van SMTP, de ISO X.400 aanbeveling, de enige serieuze concurrent geweest. Beiden zijn zogenaamde open standaards; niet gerelateerd aan een commerciële organisatie.

De achtergrond van beide protocollen is echter geheel verschillend: SMTP is afkomstig van de IETF (Internet Engineering Task Force), onderdeel van de ISOC (Internet Society). Hun werkwijze bij de totstandkoming van protocollen is het best te omschrijven als een bottom-up benadering. Iedereen die meedenkt en een oplossing weet aan te dragen voor een specifiek probleem is welkom! Op deze manier kan snel in de praktijk worden bijgestuurd en naar een gestroomlijnd product worden toegewerkt.

X.400 daarentegen is ontwikkeld vanuit de ITU-C, vroeger CCITT en onderdeel van de ISO. Protocollen van de ISO worden meestal top-down ontwikkeld: deskundigen buigen zich over een te ontwerpen standaard en na meerdere vergader- en discussie-ronden rolt daar een aanbeveling uit.

De belangrijkste oorzaak voor de populariteit van SMTP is de eenvoud van het protocol. Met aanvankelijk een tiental commando's werd een wereldwijde e-mail infrastructuur gebouwd. Dezelfde eenvoud blijkt wanneer we e-mail-adressen van beide protocollen naast elkaar leggen:

• SMTP: johnsmith@somedomain.com
  
  
• X.400: /C=US/A=MCI/P=SomeDomain/O=North America/OU=Sales/G=John/S=Smith

Kortom, je hoeft maar naar een voorbeeld van een e-mail adres te kijken om te zien waarom SMTP het uiteindelijk heeft gewonnen van X.400. Op een visitekaartje kun je de laatste in veel gevallen niet eens kwijt ..

Wat zit er in het SMTP protocol


In de kern van SMTP draait het allemaal om twee RFC-documenten: RFC 821 en RFC 822. Later zijn er nogal wat uitbreidingen aan het protocol toegevoegd, waardoor we nu ook spreken van ESMTP, Extensions for SMTP; het betreft hier veelal losse aanpassingen en uitbreidingen om meer tekstformaten, typen attachments, een efficiënter afhandeling en een betere beveiliging te ondersteunen.

RFC 821 beschrijft de "electronische envelop" van SMTP. Net als bij de papieren posterijen is ook voor SMTP beschreven hoe je iemand adresseert, waar je de afzendergegevens plaatst en of je -aangetekend- met bericht van ontvangst wilt verzenden. De envelop bevat slechts header-informatie: "van wie ... aan wie". Met deze gegevens kunnen de SMTP-servers aan het werk. Alle SMTP-servers die het bericht vervolgens afhandelen plaatsen hun eigen gegevens in deze message-header. Dit lijkt wel wat op het stempelen van allerlei nummers en barcodes op een gewone envelop.In geval van uitval of een andere storing onderweg kan de afzender aan de hand van deze Return-path informatie worden ingelicht. Wanneer het bericht veel servers passeert kan de header hierdoor aanzienlijk groeien.
Een SMTP-conversatie volgens RFC 821 tussen client (C) en server (S) kan er als volgt uitzien:

De getallen aan het begin van van iedere server-response zijn statuscodes. Deze vertellen de client of de communicatie volgens plan verloopt. Statuscodes die beginnen met een 2 geven een bevestiging weer, met een 3 zijn opdrachten van de server, wachtend op response en 4 en 5 geven fouten in de communicatie aan. De gegevens in de RFC 821 header (envelop) zie je niet terug in het geopende bericht, maar kunnen wel worden gevolgd in een Telnet dialoog of worden opgepikt met een netwerk-monitor.

RFC 822 beschrijft de samenstelling van het bericht. Een e-mailbericht bevat vaak meerdere onderdelen of body-parts. Zo is er bovenin de zogenaamde informele- of memo header. Hier staan gegevens als:

Deze gegevens zie je ook terug in het geopende bericht. Direct na deze header volgt een lege regel om het onderscheid tussen header en message-body aan te geven. De message-body bevat de eigenlijke boodschap, de inhoud van het bericht. Wanneer geen attachments zijn meegezonden en het bericht zelf is uitsluitend opgebouwd uit ongeformatteerde tekst (plaintext) dan volgt na de body een afsluitende punt op een enkele regel om het einde van het bericht te markeren. Dit is voor de SMTP server het signaal om het bericht te accepteren, in de wachtrij te plaatsen en met de eigenlijke verzending te beginnen.

Extra header-informatie

Door de vele aanpassingen en uitbreidingen op het SMTP protocol zijn er ook tal van aanvullende regels mogelijk in de RFC 822-header. Deze zijn niet direct terug te zien in het clientprogramma; sommige zijn bedoeld om opgemaakte tekst en/of attachments te beschrijven (MIME-headers), andere zijn bedoeld voor specifieke controles tijdens het transport. Zo bestaan er bijvoorbeeld verschillende controles op spam-waarschijnlijkheid van een bericht (zie hieronder bij de pijl):

X-Spam Score is een waarde waarmee de waarschijnlijkheid wordt uitgedrukt dat we hier te maken hebben met een spam-bericht. Dichter bij de 100 is de Spam-waarschijnlijkheid groter. Spamfilters op een SMTP-server of gateway/firewall kennen deze waarde toe aan een bericht na analyse van een aantal kenmerken van het bericht; afzender, samenstelling, trefwoorden etc. Outlook kan alleen een "Spam Confidence Level" (SCL) interpreteren dat in een getal tussen 1 en 10 wordt uitgedrukt.  Afhankelijk van de instellingen aan de client-zijde kan het bericht vervolgens worden gerouteerd naar de Inbox, een speciale Spam-map of naar de prullenbak.

ESMTP

SMTP wordt voortdurend uitgebreid met nieuwe voorzieningen. Nieuwere versies van een SMTP-server zullen meer van deze voorzieningen aan boord hebben dan oudere. De vele uitbreidingen hebben latere versies van SMTP de naam ESMTP bezorgd (Extensions for SMTP). Uiteenlopende ondersteuning voor deze ESMTP uitbreidingen bij verschillende servers heeft geleid tot "dialecten" van SMTP. Een server die alleen standaard SMTP verstaat begrijpt geen ESMTP opdrachten. Een ESMTP server kan wel SMTP verstaan. Als een client een ESMTP sessie met een server wil starten dan wordt het startcommando "ehlo" gegeven in plaats van "helo". Om aan een client duidelijk te maken of, en zoja welke ESMTP opdrachten de server allemaal begrijpt wordt in antwoord op het "ehlo" van de client een lijst met op de server beschikbare ESMTP-extensies teruggestuurd.

Als op de server alleen de beperkte, oudere versie van SMTP draait zal op een "ehlo" aanmelding van de client een foutmelding volgen:

De client zal in dergelijke gevallen terugvallen op gewone SMTP-communicatie en de sessie herstarten met een "helo".

Smart-host, naamresolutie en routing

De SMTP server kan zijn ingericht als "smart-host" of als "relay-host". Een smart-host moet zelf naamresolutie verrichten en dan de server van de geadresseerde aanspreken voor aflevering van het bericht. Naamresolutie is het proces waarmee een machine zal trachten het IP-adres voor de bestemming van een e-mailbericht te achterhalen. Dit moet de smart-host voor ieder afzonderlijk bestemmingsdomein  opnieuw doen. Een SMTP-adres bestaat uit drie onderdelen

1. De Alias,
2. Het @ ("at") teken of apenstaartje,
3. De DNS-domeinnaam van de geadresseerde

Zodra een smart-host een bericht ter verzending aangeboden krijgt wordt alleen onderdeel 3 van het adresveld gebruikt (de domeinnaam van de geadresseerde). Alles vóór het "@"-teken, de Alias,  is voor rekening van de ontvangende SMTP-server. De zendende SMTP server raadpleegt een DNS server om uit te vinden welke mailserver berichten kan ontvangen voor het gegeven domein. Hiervoor heeft de SMTP server twee DNS-records nodig:

1. Een MX record, waarin de naam van de SMTP server voor het ontvangende domein is vermeld (MX=Mail eXchanger).
2. Een A record, waarin het IP-adres van deze -ontvangende- SMTP server is vermeld.

Met nslookup.exe is bij elke DNS server waarop zones worden gehost een MX record op te vragen (indien aanwezig). Dit gaat niet op voor non-recursieve DNS servers zoals de root-DNS servers. Hier een voorbeeld:

Zodra het IP-adres van de SMTP server op de eindbestemming bekend is zal onze SMTP server een connectie starten naar dat adres, gericht aan TCP-poort 25, waarachter zich de SMTP service bevindt. De rest van de communicatie ziet eruit als hierboven. (zie het stukje over RFC821)

Redundantie en Batch-SMTP

In veel gevallen worden voor een domein meerdere MX records aangemaakt in DNS. Mocht één van de mailservers voor het domein niet beschikbaar zijn dan kan worden uitgeweken naar een van de alternatieve servers. Zo kan altijd e-mail worden ontvangen. Voorkeur voor bepaalde servers wordt uitgedrukt in een zogenaamde Preference Value. Dit is een getal tussen 1 en 100, die in het MX record wordt vermeld. De standaardwaarde bij het opgeven van MX records in Microsoft DNS servers bedraagt 10. Hoe lager de waarde, hoe groter de voorkeur voor de server in dit record. De DNS beheerder geeft zelf de MX-Preference value pér server aan. Als de server met de laagste preference waarde een keer niet beschikbaar is omdat hij is omgevallen of in onderhoud is, dan zou het alternatieve MX record bijvoorbeeld naar de mailserver  van de provider kunnen verwijzen. Dit moet dan wel met de Internet Service Provider (ISP) zijn afgestemd. Alle mail voor je domein komt dan in een opvangbak bij de ISP terecht zodat later, als je eigen SMTP server weer beschikbaar is, de mail alsnog op de juiste plek kan worden afgeleverd. Dit laatste kan op één van de twee volgende manieren worden gerealiseerd:

1. Batch-SMTP
2. SMTP-Fallback

Bij batch-SMTP is het de bedoeling dat je eigen server een SMTP-sessie start naar die van je ISP en vervolgens de mail in de wachtrij ophaalt. Maar wacht eens; we hadden eerder geleerd dat SMTP eenrichtingsverkeer afdwingt door de specifieke client/server relatie. De beginnende partij is altijd de client en de antwoordende partij de server. Hoe kan dan de mail van de server aan de client worden overgedragen, terwijl de "client" -in dit geval onze eigen SMTP server- de sessie is begonnen? In de SMTP RFC's is daarvoor het commando TURN bedacht. TURN keert de richting van de verzending of, zo je wilt, de rollen van client en server om: Heel even wordt de ISP-server nu client en je eigen machine wordt nu de server. Alle e-mail voor je domein wordt nu in een keer naar je server doorgezonden. De opdracht ziet er zo uit:

TURN mydomain.com

Daarna kan worden vervolgd met een gewone sessie of kun je de sessie beëindigen. In de eerste jaren was het Internet nog een besloten omgeving voor een beperkt type gebruikers: Universiteiten en Overheid (Defensie). Later, toen iedereen een lijntje naar het web kreeg, begonnen ook gebruikers met minder serieuze bedoelingen het Internet op te gaan en bleek spoedig dat iedereen een TURN opdracht kon uitvoeren voor welk SMTP-domein dan ook. Met een beetje inspanning kon je zo e-mail van meerdere servers plukken. Om daar een stokje voor te steken is SMTP uitgebreid met twee extra opdrachten: ETRN en ATRN. Met ETRN (Extended TuRN) wordt eerst je eigen IP-adres bekeken en beoordeeld of je wel de juiste gemachtigde bent. Met ATRN (Authenticated TuRN) moet de aanvrager zich eerst authenticeren; inloggen dus.

SMTP-Fallback is een eenvoudiger mechanisme; hier probeert de SMTP server van de ISP gewoon op gezette tijden (eens per kwartier/uur etc.) of je eigen server alweer mee doet en zodra dat het geval is wordt het zaakje gewoon doorgegeven. Veel minder rompslomp, al zullen de meeste ISP's deze service alleen voor bedrijven aanbieden.

Als de SMTP server geen smart-host, maar een relay-host of forwarder is wordt alle te verzenden e-mail altijd naar een specifieke SMTP-server (smart-host) doorgestuurd. Een relay-host of forwarder doet dus niets met naamresolutie. Anders gezegd; een relay-host heeft altijd een smart-host nodig voor aflevering op de eindbestemming, maar hoeft zelf alleen maar e-mail naar de smart-host te forwarden. We kunnen een deel van deze dialoog met gebruik van Telnet naspelen om te controleren of onze mailserver naar behoren reageert. Hieronder is zo'n dialoog met Telnet in scene gezet: we spelen de rol van een SMTP-client ...

Meer in een volgend artikel ...

Tijd voor een nieuw blog ...

Een blog is dynamischer dan een website, voor mij een reden waarom ik content van mijn website http://www.blip.nl/ stukje bij beetje ga verhuizen naar dit blog. Nog een reden om op een blog-vorm over te gaan is dat ik er overal aan kan werken en er niet noodzakelijk thuis voor achter de PC hoef te zitten. Zo ontstaat er ook meer ad-hoc content, die ik desgewenst later weer kan uitbreiden. En zo kan ik nog wel even doorgaan.

Waar komt de naam vandaan?
Omdat ik in mijn dagelijkse leven trainingen/cursussen geef aan IT-ers zocht ik een naam die met mijn onderwerpen te linken was. Zo is "Exchange - Office Communications Server" verdicht tot ExchOcs; het moest wel kort blijven natuurlijk.

Wat ga ik doen?
Artikelen plaatsen die betrekking hebben op onderwerpen uit mijn trainingen, demo's en downloads van bijvoorbeeld presentaties en/of animaties. Topics plaatsen die in het reguliere lesmateriaal in veel gevallen niet goed uit de verf komen of soms helemaal niet behandeld worden, terwijl ik van mening ben dat die een onderwerp van een training beter onderbouwen. Tips en Trucs. Wellicht kan het blog uitgroeien tot een forum waarin onderwerpen -over trainingen dan- kunnen worden bediscussieerd of aangevuld. Ik begin gewoon en we zien wel wat er uit komt. Suggesties zijn welkom!

De aftrap: SMTP
Een van de onderwerpen die ik eerder heb geplaatst op mijn website biedt een kijkje op de werking van dit eenvoudige, doch antieke protocol. Om meteen maar wat content te hebben volgt in het volgende artikel de tekst met bijbehorende afbeeldingen ...