Til og med bare en kort titt på SMTP-protokollen vil du legge merke til at i tillegg til den vanlige HELO, er det også EHLO, noe som gjør at Forlenget SMTP-serveren annonserer sine evner utover den opprinnelige standarden. En av disse er DSN. DSN? Er DNA og DDT ikke nok?
Å argumentere for at e-posten er upålitelig, at noen burde " … mate serveren bedre det spiste min mail … "er ikke uvanlig. Men det er ikke mye grunn til å støtte disse mistenksomhetene.
Leveranse S Tatus N otification har eksistert siden RFC 821 (fra 1982). Så snart DATA-delen av SMTP-protokollen er ferdig og serveren har akseptert e-posten for levering, er den ansvarlig for den. Hvis det av en eller annen grunn ikke kan komme igjennom mottakeren, må den sende den tilbake med varsel om feilen til den opprinnelige avsenderen. Dette resulterte i noe uklar e-post.
Bortsett fra det, betydde denne gamle konvensjonen at du enten har en feilmelding eller du har ingenting i hvilket tilfelle du visste ingenting : e-posten kan ha kommet eller det kan ikke. Feilmeldingene var i mange tilfeller like nyttig som ingen feilmeldinger. Med e-post blir stadig viktigere er dette ikke lenger tilfredsstillende (som om det var før).
DSN-utvidelser til SMTP
RFC 1891 foreslår noen utvidelser til SMTP-protokollen som skal resultere i et mer pålitelig og mer brukbart DSN-system. Det er et sett med utvidelser til MAIL og RCPT-kommandoene.
Ingen EHLO, ingen moro
Først må vi sørge for at serveren støtter DSN. Dermed må vi si EHLO til ham og lytte nøye. Hvis det reagerer med DSN et sted i funksjonslisten, kan vi anta at den vil kunne betjene våre forespørsler. Hvis ikke, da ikke: vi kan prøve en annen server eller bare komme tilbake til e-post uten DSN. For eksempel:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Søndag 24 aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hei localhost 127.0.0.1, glad for å møte deg250-EXPN250 og verb250-8BITMIME250-SIZE250 DSN250-Onex250-ETRN250-XUSR250 HJELP Heldigvis finner vi blant annet DSN. Den neste kommandoen er vanligvis MAIL FROM. Med DSN er dette ikke annerledes. Men det er to alternativer du kan utstede: RET og ENVID. RET-alternativet ble ganske tilfeldig plassert i MAIL-kommandoen, men det passer her så vel som det ville noe annet sted. Hensikten er å angi hvor mye av den opprinnelige meldingen som skal returneres i tilfelle en feil i leveransen. Gyldige argumenter er FULL og HDRS. Den tidligere betyr at den komplette meldingen skal inkluderes i feilmeldingen, HDRS instruerer serveren om å bare returnere overskriftene til den mislykkede posten. Hvis RET ikke er angitt, er det opp til serveren hva som skal gjøres. I de fleste tilfeller vil HDRS være standardverdien. ENVID tilhører virkelig avsenderen som hun eller (heller) hennes e-postklient vil være den eneste som gjør bruk av dette konvoluttidentifikator . Formålet er å fortelle avsenderen hvilken e-post en mulig utstedt feilmelding stemmer overens med. Formatet på denne IDen er i utgangspunktet igjen til avsenderens fantasi. Vi vil ikke bruke ENVID i vårt eksempel: MAIL FROM: [email protected] RET = HDRS250 [email protected] … Sender ok Tilsynelatende vil vi bare få overskriftene tilbake i vår DSN. RCPT TO: får sin rettferdige andel av utvidelser også: NOTIFY og ORCPT. NOTIFY er DSNs virkelige hjerte. Det forteller serveren når å sende et varselstatusvarsel. Den første mulige verdien er ALDRI noe som betyr at en DSN under ingen omstendigheter må returneres til avsenderen. Dette var ikke mulig uten DSN. Deretter er det SUCCESS, som vil varsle deg når posten din er kommet til bestemmelsesstedet. FELLING er SUCCESS motpart: en DSN vil komme hvis det oppsto en feil under levering. Det siste alternativet er DELAY: Du vil bli varslet om det foreligger en uvanlig forsinkelse i leveransen, men den faktiske leveringens utfall (suksess eller fiasko) er ennå ikke bestemt. ALDRI må vær det eneste argumentet hvis det angis, de andre tre kan vises i en liste, avgrenset av et komma. SUCCESS and FAILURE utgjør et ganske sterkt lag sammen og forteller deg (nesten) uansett hva som skjedde med e-posten din. Formålet med ORCPT er å bevare opprinnelig mottaker av en e-postmelding, for eksempel hvis den videresendes til en annen adresse. Argumentet for dette alternativet er e-postadressen til den opprinnelige mottakeren sammen med adressetypen. Adressetypen kommer først, etterfulgt av et semikolon og til slutt adressen. For eksempel: RCPT TIL: [email protected] NOTIFY = FEIL, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Mottaker ok (vil kø) Dette blir etterfulgt av DATA som vi kjenner det, og til slutt, forhåpentligvis, en leveringsstatus varsel informerer deg om en suksess. Selvfølgelig, alt dette skjønnhet og det vil bare fungere hvis e-posttransportagenter fra avsender til mottaker støtter DSN. En dag vil de. DSN Sender Extensions
DSN mottakerutvidelser
Fungerer DSN?
