Jopa vain lyhyt katsaus SMTP-protokollaan huomaat, että tavallisen HELOn lisäksi on myös EHLO, joka tekee laajennettu SMTP-palvelin mainostaa 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 " … syöttää palvelimelleen paremmin; se söi postini … "ei ole harvinaista, mutta ei ole paljon syytä tukea näitä epäilyksiä.
Toimitus S tatus N RFC 821 (vuodesta 1982 lähtien) on ollut käytössä. Heti kun SMTP-protokollan DATA-osa on päättynyt ja palvelin on hyväksynyt sähköpostin toimitettavaksi, se vastaa siitä. Jos jostain syystä se ei pääse vastaanottajalle, sen on lähetettävä se takaisin virheilmoituksella 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 on ei mitään jolloin tiedät ei 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.
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 vastaa DSN: n jossakin ominaisuusluettelossa, 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:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Aurinko, 24. Elokuu 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hei localhost 127.0.0.1, tyytyväinen tavata250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 HELP Onneksi mm. Löydämme DSN: n. 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 käyttää tätä kirjekuorien tunniste . 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: MAIL FROM: [email protected] RET = HDRS250 [email protected] … Lähettäjä ok Ilmeisesti haluamme vain saada otsikot takaisin DSN: ään. RCPT TO: saa myös kohtuullisen osuutensa laajennuksista: NOTIFY ja ORCPT. NOTIFY on DSN: n todellinen sydän. Se kertoo palvelimelle kun 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 posti saapuu kohteeseen. FAILURE on SUCCESSin vastapuoli: DSN saapuu, jos tapahtui virhe 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. EI KOSKAAN on pakko 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ää alkuperäinen esimerkiksi sähköpostiviestin vastaanottaja, 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: [email protected] NOTIFY = virhe, viivästys ORCPT = rfc822; [email protected]250 [email protected] … Vastaanottaja ok (tulee jonoon) Tätä seuraa DATA, kuten tiedämme ja lopulta toivottavasti toimitustilailmoitus, joka ilmoittaa sinulle menestyksestä. Tietenkin kaikki tämä kauneus ja se toimii vain, jos lähettäjän ja vastaanottajan väliset postimyyntitoimijat tukevat DSN: ää. Jonain päivänä he tulevat. DSN-lähettäjän laajennukset
DSN-vastaanottajan laajennukset
Onko DSN toimii?
