Toimituksen tilailmoitus (DSN) on ollut käytössä RFC 821:stä (1982) lähtien. Kun SMTP-protokollan DATA-osa on valmis ja palvelin hyväksyy sähköpostin toimitettavaksi, DSN on vastuussa siitä. Jos sähköposti jostain syystä ei tavoita vastaanottajaa, DSN:n on palautettava se alkuperäiselle lähettäjälle ja ilmoitettava virheestä. Tämä vanha käytäntö tarkoitti, että sait virheilmoituksen tai et saanut mitään. Sähköposti on ehkä saapunut tai ei ole saapunut. Virheilmoitukset olivat monissa tapauksissa yhtä hyödyllisiä kuin ei virheilmoituksia.
DSN-laajennukset SMTP:hen
RFC 1891 ehdottaa joitain laajennuksia SMTP-protokollaan, joiden pitäisi johtaa luotettavampaan ja käyttökelpoisempaan DSN-järjestelmään. Se on joukko MAIL- ja RCPT-komentojen laajennuksia.
Ei EHLOa, ei hauskaa
Varmista ensin, että palvelin tukee DSN:ää, eli sano sille EHLO ja kuuntele tarkkaan. Jos se vastaa DSN:llä missä tahansa funktioluettelossa, se voi käsitellä pyyntöjä. Jos ei, kokeile toista palvelinta tai palaa sähköpostiin ilman DSN:ää. Esimerkki: 220 larose.magnet.at ESMTP Sendmail 8.8.6/8.8.6; su 24. elokuuta 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hello localhost [127.0.0.1]oli ilo tavata sinut
250-EXPN
250 VERB
250-8 BITMIME
250 KOKO
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 APUA
DSN Sender Extensions
Seuraava komento on yleensä MAIL FROM. Tämä ei ole erilaista DSN: n kanssa. Mutta voit käyttää kaksi lisävaihtoehtoa: RET ja ENVID. RET-vaihtoehto sijoitettiin satunnaisesti MAIL-komentoon, mutta se sopii tähän yhtä hyvin kuin mihin tahansa muuallekin. Sen tarkoitus on määrittää, kuinka suuri osa alkuperäisestä viestistä tulee palauttaa, jos toimitus epäonnistuu. Kelvolliset argumentit ovat FULL ja HDRS. FULL tarkoittaa, että koko viesti on sisällytettävä virheilmoitukseen. HDRS kehottaa palvelinta palauttamaan vain epäonnistuneen sähköpostin otsikot. Jos RET:tä ei ole määritetty, on palvelimen asia, mitä tehdä. HDRS on oletusasetus useimmissa tapauksissa. ENVID kuuluu lähettäjälle, koska lähettäjä tai (mieluiten) lähettäjän sähköpostiohjelma on ainoa, joka käyttää tätä kirjekuoritunnusta. Sen tarkoitus on kertoa lähettäjälle, mitä sähköpostiviestiä mahdollisesti lähetetty virheilmoitus vastaa. Tämän tunnuksen muoto jätetään lähettäjän mielikuvituksen varaan. ENVIDiä ei käytetä tässä esimerkissä: MAIL FROM: [email protected] RET=HDRS
250 [email protected]… Lähettäjä ok
Laajennukset DSN-vastaanottimille
RCPT TO saa myös suuren määrän laajennuksia: NOTIFY ja ORCPT. NOTIFY on DSN:n ydin. Se kertoo palvelimelle, milloin toimitustilailmoitus lähetetään. Vaihtoehtoja ovat:
- EI KOSKAAN tarkoittaa, että DSN-numeroa ei saa missään olosuhteissa palauttaa lähettäjälle. Tämä ei ollut mahdollista ilman DSN:ää.
- SUCCESS ilmoittaa, kun posti on saapunut määränpäähänsä.
- FAILURE toimittaa DSN:n, jos toimituksen aikana tapahtui virhe.
- DELAY lähettää ilmoituksen, jos toimituksessa on epätavallinen viivästys, mutta toimituksen lopputulosta (onnistuminen tai epäonnistuminen) ei ole vielä päätetty.
EI KOSKAAN pitäisi olla ainoa argumentti, jos se on määritetty. Muut kolme voivat olla luettelossa pilkulla erotettuina. ORCPT:n tarkoitus on säilyttää sähköpostiviestin alkuperäinen vastaanottaja, jos se esimerkiksi välitetään toiseen osoitteeseen. Tämän vaihtoehdon argumentti on alkuperäisen vastaanottajan sähköpostiosoite ja osoitetyyppi. Osoitetyyppi tulee ensin, sen jälkeen puolipiste ja lopuksi osoite. Esimerkki: RCPT TO: [email protected] NOTIFY=FAILURE,DELAY ORCPT=rfc822;[email protected]
250 [email protected]… Vastaanottaja ok (jonossa) Tämän jälkeen tulee DATA ja ilmoitus toimituksen onnistumisesta.
Toimiiko DNS?
DSN toimii vain, jos lähettäjältä vastaanottajalle -postinsiirtoagentit tukevat DSN:ää.