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
- De Alias,
- Het @ ("at") teken of apenstaartje,
- 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:
- Een MX record, waarin de naam van de SMTP server voor het ontvangende domein is vermeld (MX=Mail eXchanger).
- 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:
- Batch-SMTP
- 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 ...
