Även en kort titt på SMTP-protokollet kommer att märka att förutom den vanliga HELO finns det också EHLO, vilket gör att Utökad SMTP-servern annonserar sina möjligheter utöver originalstandarden. En av dessa är DSN. DSN? Är DNA och DDT inte tillräckligt?
Att argumentera för att e-post är opålitligt, att någon borde " … mata deras server bättre det åt min mail … "Det är inte ovanligt. Men det finns inte mycket anledning att stödja dessa misstankar.
Leverans S Tatus N otification har funnits sedan RFC 821 (från 1982). Så snart DATA-delen av SMTP-protokollet är klar och servern har accepterat e-posten för leverans ansvarar den för det. Om det av någon anledning inte går igenom det till mottagaren måste det skicka det tillbaka med anmälan av felet till den ursprungliga avsändaren. Detta resulterade i något obskilt email.
Bortsett från detta, menade den här gamla konventionen att du antingen fick ett felmeddelande eller du fick ingenting i vilket fall du visste ingenting : E-postmeddelandet kan ha kommit eller det kanske inte. Felmeddelandena var i många fall lika användbara som inga felmeddelanden. Med e-post blir allt viktigare är detta inte längre tillfredsställande (som om det var tidigare).
DSN-förlängningar till SMTP
RFC 1891 föreslår några tillägg till SMTP-protokollet som borde leda till ett mer tillförlitligt och mer användbart DSN-system. Det är en uppsättning tillägg till kommandona MAIL och RCPT.
Ingen EHLO, ingen kul
Först måste vi se till att servern stöder DSN. Således måste vi säga EHLO till honom och lyssna noggrant. Om det svarar med DSN någonstans i funktionslistan kan vi anta att det kommer att kunna betjäna våra önskemål. Om inte, då inte: vi kan prova en annan server eller helt enkelt återgå till e-post utan DSN. Till exempel:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sön, 24 aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hej localhost 127.0.0.1, glad att träffa dig250-EXPN250-VERB250-8BITMIME250-STORLEK250-DSN250-ONEX250-ETRN250-XUSR250 HJÄLP Lyckligtvis hittar vi bland annat DSN. Nästa kommando är typiskt MAIL FROM. Med DSN är det inte annorlunda. Men det finns ytterligare två alternativ du kan utfärda: RET och ENVID. Alternativet RET var ganska godtyckligt placerat i MAIL-kommandot, men det passar här såväl som det skulle någon annanstans. Syftet är att ange hur mycket av ditt ursprungliga meddelande som ska returneras vid leveransfel. Giltiga argument är FULL och HDRS. Den tidigare innebär att det fullständiga meddelandet bör ingå i felmeddelandet, HDRS instruerar servern att bara returnera rubrikerna för det misslyckade mailet. Om RET inte är angivet är det upp till servern vad man ska göra. I de flesta fall är HDRS standardvärdet. ENVID hör verkligen till avsändaren eftersom hon eller (snarare) hennes e-postklient kommer att vara den enda som använder sig av detta kuvertidentifierare . Dess syfte är att berätta för avsändaren vilken e-post ett eventuellt utfärdat felmeddelande motsvarar. Formatet för detta ID är i grunden kvar till avsändarens fantasi. Vi kommer inte använda ENVID i vårt exempel: MAIL FRÅN: avsä[email protected] RET = HDRS250 avsä[email protected] … Avsändare ok Tydligen vill vi bara få rubrikerna tillbaka i vår DSN. RCPT TO: får också sin rättvisa andel av tillägg: ANMÄRK OCH ORCPT. NOTIFY är DSN: s verkliga hjärta. Det berättar servern när att skicka en meddelande om leveransstatus. Det första möjliga värdet är ALDRIG vilket innebär att en DSN under inga omständigheter måste returneras till avsändaren. Detta var inte möjligt utan DSN. Då finns det SUCCESS, som kommer att meddela dig när ditt mail har kommit till dess destination. FEL är SUCCESS motpart: en DSN kommer att komma om ett fel inträffade under leveransen. Det sista alternativet är DELAY: Du kommer att bli underrättad om det förekommer en ovanlig leveransfördröjning, men det faktiska leveransresultatet (framgång eller misslyckande) är ännu inte bestämt. ALDRIG måste vara det enda argumentet om det anges, de andra tre kan visas i en lista, avgränsad av ett komma. SUCCESS and FAILURE utgör ett ganska starkt lag tillsammans och berättar (nästan) vad som hände med ditt mail. Syftet med ORCPT är att bevara original- mottagare av ett e-postmeddelande, till exempel om det vidarebefordras till en annan adress. Argumentet för det här alternativet är den ursprungliga mottagarens e-postadress tillsammans med adresstypen. Adress typ kommer först, följt av en semikolon och slutligen adressen. Till exempel: RCPT TO: [email protected] NOTIFY = FEL, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Mottagare ok (kommer kö) Detta följs av DATA som vi känner till det och så småningom, förhoppningsvis, en leveransstatusanmälan som meddelar dig en framgång. Självklart kommer allt detta skönhet och det fungerar bara om postleverantörerna från avsändare till mottagare stöder DSN. Somedag kommer de. DSN Sender Extensions
DSN mottagare förlängningar
Fungerar DSN?
