Zelfs als je even naar het SMTP-protocol kijkt, merk je dat naast de gebruikelijke HELO, er ook EHLO is, waardoor de Uitgebreide SMTP-server adverteert zijn mogelijkheden verder dan de oorspronkelijke standaard. Een daarvan is DSN. DSN? Zijn DNA en DDT niet genoeg?
Om te beweren dat e-mail onbetrouwbaar is, dat iemand " … hun server beter voeden; het at mijn mail … "is niet ongewoon, maar er is niet veel reden om deze vermoedens te ondersteunen.
Levering S tatus N Kennisgeving bestaat al sinds RFC 821 (vanaf 1982). Zodra het DATA-gedeelte van het SMTP-protocol is voltooid en de server de e-mail heeft aanvaard voor aflevering, is deze daarvoor verantwoordelijk. Als het om welke reden dan ook niet tot de ontvanger kan doordringen, moet het dit terugsturen met kennisgeving van de fout aan de oorspronkelijke afzender. Dit resulteerde in een aantal obscure e-mail.
Afgezien daarvan betekende deze oude conventie dat je een foutmelding kreeg of je kreeg niets in welk geval je het wist niets : de e-mail is mogelijk gearriveerd of niet. De foutmeldingen waren in veel gevallen even nuttig als geen foutmeldingen. Met het steeds belangrijker worden van e-mail is dit niet langer bevredigend (alsof het eerder was).
DSN-extensies naar SMTP
RFC 1891 stelt enkele uitbreidingen voor van het SMTP-protocol die zouden moeten leiden tot een betrouwbaarder en meer bruikbaar DSN-systeem. Het is een set extensies voor de MAIL- en RCPT-opdrachten.
Geen EHLO, geen plezier
Eerst moeten we ervoor zorgen dat de server DSN ondersteunt. Daarom moeten we EHLO tegen hem zeggen en goed luisteren. Als het ergens in de functielijst met DSN antwoordt, kunnen we aannemen dat het in staat zal zijn om onze verzoeken te vervullen. Zo niet, dan niet: we kunnen een andere server proberen of gewoon terugvallen op e-mail zonder DSN. Bijvoorbeeld:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Zo, 24 aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hallo localhost 127.0.0.1, verheugd u te ontmoeten250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 HELP Gelukkig vinden we onder andere DSN. De volgende opdracht is meestal MAIL VANAF. Met DSN is dit niet anders. Maar er zijn twee extra opties die u kunt uitgeven: RET en ENVID. De RET-optie was nogal arbitrair geplaatst in het MAIL-commando, maar hij past hier net zo goed als elders. Het doel is om aan te geven hoeveel van uw oorspronkelijke bericht moet worden geretourneerd in het geval van een leveringsfout. Geldige argumenten zijn FULL en HDRS. Het eerste betekent dat het volledige bericht in het foutbericht moet worden opgenomen. HDRS geeft de server opdracht alleen de kopteksten van de mislukte e-mail te retourneren. Als RET niet is opgegeven, is het aan de server wat te doen. In de meeste gevallen is HDRS de standaardwaarde. ENVID hoort echt bij de afzender omdat zij (of liever gezegd) haar e-mailclient de enige is die hiervan gebruik maakt envelop-ID . Het doel is om de verzender te vertellen op welke e-mail een mogelijk uitgegeven foutbericht betrekking heeft. Het formaat van deze ID is in wezen aan de verbeelding van de afzender overgelaten. We gebruiken ENVID niet in ons voorbeeld: MAIL VAN: [email protected] RET = HDRS250 [email protected] … Afzender ok Blijkbaar willen we alleen de headers terug krijgen in onze DSN. De RCPT TO: krijgt ook een behoorlijk aantal uitbreidingen: NOTIFY en ORCPT. NOTIFY is het echte hart van DSN. Het vertelt de server wanneer om een melding over de bezorgingsstatus te verzenden. De eerste mogelijke waarde is NOOIT, wat betekent dat een DSN in geen geval teruggestuurd hoeft te worden naar de afzender. Dit was niet mogelijk zonder DSN. Dan is er SUCCESS, dat u op de hoogte brengt wanneer uw e-mail op zijn bestemming is aangekomen. FAILURE is de tegenhanger van SUCCESS: een DSN komt aan als er tijdens de levering een fout is opgetreden. De laatste optie is DELAY: u krijgt een melding als er een ongebruikelijke vertraging in de aflevering is, maar de uitkomst van de daadwerkelijke aflevering (succes of mislukking) is nog niet vastgesteld. NOOIT moet het enige argument zijn als dit is opgegeven, de andere drie kunnen in een lijst voorkomen, begrensd door een komma. SUCCES en FAILURE vormen samen een behoorlijk sterk team en vertellen je (bijna) in elk geval wat er met je mail is gebeurd. Het doel van ORCPT is het bewaren van de origineel ontvanger van een e-mailbericht, bijvoorbeeld als het wordt doorgestuurd naar een ander adres. Het argument voor deze optie is het e-mailadres van de oorspronkelijke ontvanger, samen met het adrestype. Het adrestype komt eerst, gevolgd door een puntkomma en tot slot het adres. Bijvoorbeeld: RCPT AAN: [email protected] NOTIFY = FAILURE, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Ontvanger ok (wordt in de wachtrij geplaatst) Dit wordt gevolgd door de DATA zoals wij die kennen en uiteindelijk, hopelijk, een melding over de bezorgingsstatus die u op de hoogte brengt van een succes. Natuurlijk, al dit moois en het zal alleen werken als de postvervoerders van zender naar ontvanger DSN ondersteunen. Op een dag zullen ze dat doen. DSN Sender Extensions
DSN geadresseerde extensies
Werkt DSN?
