Selvitä, miten DSN pyrkii tuomaan toimitustilanteen SMTP-sähköpostiviestiin.
Oletko koskaan miettinyt, mitä tapahtui sähköpostin lähettämiseen?
Jopa vain lyhyt katsaus SMTP-protokollaan huomaa, että tavallisen HELOn lisäksi on olemassa myös EHLO, joka tekee laajennetusta SMTP-palvelimesta mainontaa ominaisuuksiaan alkuperäisen standardin ulkopuolella. Yksi näistä on DSN. DSN? Ovatko DNA ja DDT tarpeeksi tarpeeksi?
Voit väittää, että sähköposti ei ole luotettava, että joku " ... ruokkii palvelintaan paremmin, se söi postini ... " ei ole harvinaista. Minä teen sen itse. Silti ei ole paljon syytä tukea näitä epäilyksiä.
Toimitusvalmius on ollut käytössä RFC: n 821 jälkeen (vuodesta 1982 lähtien). Heti kun SMTP- protokollan DATA-osa on päättynyt ja palvelin on hyväksynyt sähköpostin toimitettavaksi, se vastaa siitä. Jos se ei mistä tahansa syystä voi päästä vastaanottajalle, sen on lähetettävä virheilmoitus alkuperäiselle lähettäjälle. Tämä johti epäselviin sähköpostiviesteihin .
Sen lisäksi, että tämä vanha yleissopimus merkitsi, että joko sinulla on virheilmoitus tai sinulla ei ole mitään , jolloin et tiennyt mitään : sähköposti saattaa olla saapunut tai se ei ehkä ole. Usein virheilmoitukset olivat yhtä hyödyllisiä kuin virheilmoituksia. Sähköpostilla yhä tärkeämmäksi tämä ei ole enää tyydyttävä (ikään kuin se olisi aiemmin).
DSN-laajennukset SMTP: hen
RFC 1891 ehdottaa joitain laajennuksia SMTP- protokollaan, jonka pitäisi johtaa luotettavampaan ja käyttökelpoisempaan DSN-järjestelmään. Se on sarja laajennuksia MAIL- ja RCPT-komentoihin (jos tämä ei merkitse mitään sinulle, lue kuinka SMTP toimii ja palaa tänne.).
Ei EHLO, ei hauskaa
Ensinnäkin meidän on varmistettava, että palvelin tukee DSN: ää. Siksi meidän täytyy sanoa hänelle EHLO ja kuunnella tarkasti. Jos se reagoi DSN: n kanssa jonkin verran ominaisuusluetteloon, voimme olettaa, että se pystyy palvelemaan pyyntöjemme. Jos ei, niin ei: voimme kokeilla toista palvelinta tai vain palata takaisin sähköpostitse ilman DSN: ää. Esimerkiksi (tuloni on sininen, palvelimen lähtö musta):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Aurinko, 24. Elokuu 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hei localhost [127.0.0.1], tyytyväinen tavata
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Onneksi mm. Löydämme DSN: n.
DSN-lähettäjän laajennukset
Seuraava komento on tyypillisesti MAIL FROM :. DSN: n avulla tämä ei ole erilainen. Mutta sinulla on kaksi vaihtoehtoa, joita voit antaa: RET ja ENVID.
RET-vaihtoehto oli melko mielivaltaisesti MAIL-komennossa, mutta se sopii tänne samoin kuin muualla. Tarkoituksena on määrittää, kuinka paljon alkuperäistä viestiäsi pitäisi palauttaa, mikäli lähetys epäonnistuu. Hyvät argumentit ovat FULL ja HDRS. Ensimmäinen tarkoittaa, että täydellinen viesti olisi sisällytettävä virheilmoitukseen, HDRS kehottaa palvelinta palauttamaan vain epäonnistuneen sähköpostin otsikot. Jos RET ei ole määritetty, palvelimen tehtävä on tehdä. Useimmissa tapauksissa HDRS on oletusarvo.
ENVID todella kuuluu lähettäjälle, koska hän tai (melko) hänen sähköpostiasiakkaansa on ainoa, joka tekee meidät tästä kirjekuorien tunnistimesta . Sen tarkoitus on kertoa lähettäjälle, joka lähettää mahdollisen virheilmoituksen sähköpostiviesti. Tämän tunnuksen muoto on periaatteessa jätetty lähettäjän mielikuvitukselle. Emme käytä ENVIDä esimerkissämme (mielikuvitus!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Lähettäjä ok
Ilmeisesti haluamme vain saada otsikot takaisin DSN: ään.
DSN-vastaanottajan laajennukset
RCPT TO: saa myös kohtuullisen osuutensa laajennuksista: NOTIFY ja ORCPT.
NOTIFY on DSN: n todellinen sydän. Se kertoo palvelimelle, milloin lähettää toimitustilan ilmoituksen. Ensimmäinen mahdollinen arvo ei ole missään tapauksessa mikä tarkoittaa, että DSN: tä ei missään tapauksessa tarvitse palauttaa lähettäjälle. Tämä ei ollut mahdollista ilman DSN: ää. Sitten on SUCCESS, joka ilmoittaa sinulle, kun postisi karkeasti määränpäässä. FAILURE on SUCCESSin vastapuoli (!): DSN saapuu, jos saapuminen tapahtui toimituksen aikana. Viimeinen vaihtoehto on VIIVÄSTYS: saat ilmoituksen, jos toimituksessa on epätavallinen viivästys, mutta todellisen toimituksen tulosta (menestystä tai epäonnistumista) ei ole vielä päätetty. ÄLÄ KOSKAAN saa olla ainoa argumentti, jos se on määritelty, muut kolme voivat näkyä luettelossa, jonka rajaavat pilkku. SUCCESS ja FAILURE muodostavat melko vahvan ryhmän yhdessä (!), Kertoivat sinulle (melkein) joka tapauksessa, mitä tapahtui postisi.
ORCPT: n tarkoitus on säilyttää sähköpostiviestin alkuperäinen vastaanottaja, esimerkiksi jos se välitetään toiseen osoitteeseen. Tämän vaihtoehdon argumentti on alkuperäisen vastaanottajan sähköpostiosoite yhdessä osoitetyypin kanssa. Osoitetyyppi tulee ensin, jonka jälkeen on annettu puolipiste ja lopuksi osoite. Esimerkiksi:
RCPT TO: support@example.com NOTIFY = virhe, viivästys ORCPT = rfc822; support@example.com
250 support@example.com ... Vastaanottaja ok (tulee jonoon)
Tätä seuraa DATA, kuten tiedämme ja lopulta toivottavasti toimitustilailmoitus, joka ilmoittaa sinulle menestyksestä.
Onko DSN toimii?
Tietenkin kaikki tämä kauneus ja wit toimivat vain, jos lähettäjän ja vastaanottajan väliset postinkuljettajat tukevat DSN: ää. Jotkut he tulevat.