Tudja meg, hogy a DSN hogyan akarta bevezetni a szállítási állapotot az SMTP e-mail címre.
Elgondolkozott, mi történt egy e-mailben, amelyet elküld?
Még csak egy rövid pillantást vetni az SMTP protokollra , észre fogod venni, hogy a szokásos HELO mellett létezik az EHLO is, amely a kibővített SMTP szervert az eredeti szabványon túlmutatja. Az egyik ilyen a DSN. DSN? A DNS és a DDT nem elég?
Annak érvelése, hogy az e-mail megbízhatatlan, hogy valaki " ... táplálja a szervereit, jobban táplálja a levelemet ... " nem ritka. Magam csinálom. Ennek ellenére nincs sok oka annak, hogy támogassák ezeket a gyanút.
A szállítási kódex az RFC 821 óta (1982-től) már megtörtént. Amint az SMTP protokoll DATA része befejeződik, és a kiszolgáló elfogadta az e-mailt a szállításhoz, ez a felelős. Ha valamilyen oknál fogva nem tudja átvenni a címzett felé, vissza kell küldenie a hiba értesítésével az eredeti feladónak. Ez némi homályos e-mailt eredményezett .
Ettől eltekintve, ez a régi egyezmény azt jelentette, hogy vagy hibaüzenetet kaptál, vagy semmit sem kaptál, abban az esetben semmit sem tudott: az e-mail érkezett, vagy nem. A hibaüzenetek sok esetben ugyanolyan hasznosak voltak, mint hibaüzenetek. Az e-mailek egyre fontosabbá válásával ez már nem kielégítő (mintha korábban volt).
DSN kiterjesztések SMTP-re
Az RFC 1891 az SMTP protokoll néhány kiterjesztését javasolja, amelyek megbízhatóbb és használhatóbb DSN-rendszert eredményeznek. Ez a MAIL és RCPT parancsok kiterjesztése (ha ez nem jelent semmit, olvassa el, hogyan működik az SMTP , majd visszatér ide.).
Nem EHLO, No Fun
Először meg kell győződnünk arról, hogy a kiszolgáló támogatja a DSN-t. Ezért el kell mondanunk neki EHLO-t, és óvatosan figyelni kell. Ha a DSN néven reagál a szolgáltatáslistán, feltételezhetjük, hogy képes lesz a kéréseink kiszolgálására. Ha nem, akkor nem: megpróbálhatunk egy másik kiszolgálót, vagy egyszerűen vissza tudunk térni a DSN nélküli e-mailre . Például (a bemenetem kék, a kiszolgáló kimenete fekete):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hello localhost [127.0.0.1], örülök, hogy találkoztunk
250-EXPN
250-IGE
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Szerencsére, többek között megtaláljuk a DSN-t.
DSN Sender Extensions
A következő parancs általában MAIL FROM :. A DSN-vel ez nem más. De két további lehetőséget is adhat: RET és ENVID.
A RET opció önkényesen elhelyezett a MAIL parancsba, de itt is illik, bárhol máshol is. A cél az, hogy meg kell adni, hogy az eredeti üzenet mennyi lesz a küldési hiba esetén. Érvényes argumentumok: FULL és HDRS. Az előbbi azt jelenti, hogy a teljes üzenetet fel kell tüntetni a hibaüzenetben, a HDRS arra utasítja a kiszolgálót, hogy csak a sikertelen levél fejlécét küldje vissza. Ha a RET nincs megadva, akkor a kiszolgálóra van szükség. A legtöbb esetben az HDRS lesz az alapértelmezett érték.
Az ENVID valóban a feladóhoz tartozik, hiszen ő vagy (inkább) az e-mail kliens lesz az egyetlen, aki ezt a borítékazonosítót teszi. Célja, hogy megmondja a feladónak, amely egy esetlegesen kiadott hibaüzenetet küld e-mailnek. Az azonosító formátuma alapvetően a feladó képzeletéhez tartozik. Nem használjuk az ENVID példát (képzelet!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Feladó oké
Nyilvánvalóan csak a fejléceket szeretnénk visszaszerezni a DSN-be.
DSN-címzettbővítmények
Az RCPT TO: a kiterjesztések méltányos arányát is megkapja: NOTIFY és ORCPT.
A NOTIFY a DSN igazi szíve. Megmondja a kiszolgálónak , hogy mikor küldi el a szállítási állapot értesítést. Az első lehetséges érték SOHA nem jelenti azt, hogy semmilyen körülmények között nem kell DSN-t visszaadni a küldőnek. Ez nem lehetséges DSN nélkül. Aztán ott van a SIKERTESSÉG, amely értesíti Önt, ha az e-mailje a rendeltetési helyén fárasztó. A FAILURE a SUCCESS megfelelője (!): A DSN akkor érkezik meg, ha a szállítmány megérkezett a szállítás során. Az utolsó lehetőség a KÉSLELTETÉS: értesítést fog kapni, ha szokatlan késedelem van a szállításban, de a tényleges kézbesítés kimenetele (siker vagy kudarc) még nem született döntés. SOHA nem lehet az egyetlen érv, ha megadta, a másik három egy vesszővel határolt listán jelenhet meg. A SIKERTESSÉG és a MEGHIBÁSODÁS egy nagyon erős csapathoz (!) Teszik fel a kapcsolatot, és (esetenként) elmondja neked, hogy mi történt az Ön levelével.
Az ORCPT célja, hogy megőrizze az e-mail üzenet eredeti címzettjét, például ha másik címre továbbítja. Ennek az opciónak az érvelése az eredeti címzett e-mail címe és a cím típusa. Először a cím típusa, majd pontosvessző, végül pedig a cím. Például:
RCPT TO: support@example.com NOTIFY = HIBA, KÉSLELTETÉS ORCPT = rfc822; support@example.com
250 support@example.com ... A címzett rendben van (sor kerül)
Ezt követi a DATA, amint tudjuk, és végül, remélhetőleg, egy kézbesítési státusz értesítést értesítünk a sikerről.
A DSN működik?
Természetesen ez a szépség és szellem csak akkor működik, ha a küldõ és a címzett postai szállítmányozói támogatják a DSN-t. Várják.