Selv et kort kig på SMTP-protokollen vil du bemærke, at ud over den sædvanlige HELO er der også EHLO, hvilket gør Udvidet SMTP-serveren annoncerer sine muligheder ud over den oprindelige standard. En af disse er DSN. DSN? Er DNA og DDT ikke nok?
At argumentere for, at e-mail er upålidelig, at nogen skal " … feed deres server bedre det spiste min mail … "er ikke ualmindeligt. Men der er ikke meget grund til at støtte disse mistanker.
Levering S TATUS N otification har eksisteret siden RFC 821 (fra 1982). Så snart DATA-delen af SMTP-protokollen er færdig, og serveren har accepteret e-mailen til levering, er den ansvarlig for den. Hvis den af en eller anden grund ikke kan få det igennem til modtageren, skal den sende den tilbage med meddelelse om fejlen til den oprindelige afsender. Dette resulterede i noget uklart email.
Bortset fra det betød denne gamle konvention, at du enten fik en fejlmeddelelse eller du fik ikke noget i hvilket tilfælde du vidste ikke noget : Emailen kan være ankommet, eller det kan ikke. Fejlmeddelelserne var i mange tilfælde lige så nyttige som ingen fejlmeddelelser. Med e-mail bliver mere og mere vigtigt er dette ikke længere tilfredsstillende (som om det var før).
DSN-udvidelser til SMTP
RFC 1891 foreslår nogle udvidelser til SMTP-protokollen, der skal resultere i et mere pålideligt og mere brugbart DSN-system. Det er et sæt udvidelser til MAIL og RCPT kommandoer.
Ingen EHLO, ingen sjov
For det første skal vi sikre os, at serveren understøtter DSN. Således må vi sige EHLO til ham og lytte omhyggeligt. Hvis det svarer med DSN et eller andet sted i funktionslisten, kan vi antage, at det vil kunne betjene vores anmodninger. Hvis ikke, så ikke: vi kan prøve en anden server eller bare vende tilbage til email uden DSN. For eksempel:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hej localhost 127.0.0.1, glad for at møde dig250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 HJÆLP Heldigvis finder vi blandt andet DSN. Den næste kommando er typisk MAIL FROM. Med DSN er det ikke anderledes. Men der er to ekstra muligheder, du kan udstede: RET og ENVID. RET-indstillingen blev ret vilkårligt placeret i MAIL-kommandoen, men det passer her såvel som det ville andre steder. Formålet er at angive, hvor meget af din oprindelige besked skal returneres i tilfælde af manglende levering. Gyldige argumenter er FULL og HDRS. Den tidligere betyder, at den komplette besked skal medtages i fejlmeddelelsen, HDRS pålægger serveren kun at returnere overskrifterne for den mislykkede mail. Hvis RET ikke er angivet, er det op til serveren, hvad der skal gøres. I de fleste tilfælde vil HDRS være standardværdien. ENVID tilhører virkelig afsenderen, da hun eller (snarere) hendes e-mail-klient vil være den eneste der gør brug af dette kuvertidentifikator . Dens formål er at fortælle afsenderen hvilken e-mail en eventuelt udgivet fejlmeddelelse svarer til. Formatet af dette ID er stort set overladt til afsenderens fantasi. Vi vil ikke bruge ENVID i vores eksempel: MAIL FROM: [email protected] RET = HDRS250 [email protected] … Afsender ok Tilsyneladende ønsker vi kun at få overskrifterne tilbage i vores DSN. RCPT TO: får også sin retlige andel af udvidelser: NOTIFY og ORCPT. NOTIFY er DSN's ægte hjerte. Det fortæller serveren hvornår at sende en meddelelse om leveringsstatus. Den første mulige værdi er ALDRIG, hvilket betyder, at en DSN under ingen omstændigheder skal returneres til afsenderen. Dette var ikke muligt uden DSN. Så er der succé, som vil give dig besked, når din mail er ankommet til bestemmelsesstedet. FAILURE er SUCCESS modpart: en DSN vil ankomme, hvis der opstod en fejl under levering. Den sidste mulighed er DELAY: Du vil blive underrettet, hvis der foreligger en usædvanlig forsinket levering, men den faktiske leveringens resultat (succes eller fiasko) er endnu ikke besluttet. ALDRIG skal være det eneste argument, hvis det angives, de andre tre kan vises i en liste afgrænset af et komma. SUCCESS and FAILURE udgør et godt stærkt team sammen og fortæller dig (næsten) i hvert fald hvad der skete med din mail. Formålet med ORCPT er at bevare original modtager af en e-mail besked, for eksempel, hvis den videresendes til en anden adresse. Argumentet for denne indstilling er den oprindelige modtagers emailadresse sammen med adressetypen. Adressetypen kommer først, efterfulgt af et semikolon og endelig adressen. For eksempel: RCPT TIL: [email protected] NOTIFY = FEJL, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Modtager ok (vil kø) Dette efterfølges af DATA som vi kender det og til sidst, forhåbentlig en leveringsstatus anmeldelse, der meddeler dig en succes. Selvfølgelig vil al denne skønhed og det kun fungere, hvis posttransportagenterne fra afsender til modtager støtter DSN. I dag vil de. DSN Sender Extensions
DSN Modtagerudvidelser
Fungerer DSN?
