Eltrovu, kiel DSN celis enkonduki transdaton al SMTP-retpoŝto.
Iam demandis, kio okazis al retpoŝto, kiun vi sendis?
Eĉ nur mallonga rigardo al la protokolo SMTP rimarkos, ke krom la kutima HELO, ankaŭ ekzistas EHLO, kiu faras ke la etendita SMTP-servilo reklamu ĝiajn kapablojn preter la originala normo. Unu el ĉi tiuj estas DSN. DSN? Ĉu ADN kaj DDT ne sufiĉas?
Por argumenti, ke retpoŝto ne estas fidinda, ke iu devus " ... pli bone servi sian servilon, ĝi manĝis mian poŝton ... " ne estas malofta. Mi tion faras. Tamen, ne estas multa kialo por subteni ĉi tiujn suspektojn.
Transdono S otatus N otification estis proksimume ekde RFC 821 (de 1982). Tuj kiam la DATA-parto de la SMTP- protokolo finiĝis kaj la servilo akceptis la retpoŝton por liverado, ĝi respondecas pri ĝi. Se, por iu kialo, ĝi ne povas atingi ĝin al la ricevanto, ĝi devas redoni ĝin per sciigo pri la eraro al la originala sendinto. Ĉi tio rezultigis iun malplenan retpoŝton .
Krom tio, ĉi tiu malnova konvencio signifis, ke ĉu vi ricevis eraron- mesaĝon aŭ vi ricevis nenion, en kies kazo vi nenion sciis: la retpoŝton eble alvenis aŭ eble ne. La eraraj mesaĝoj en multaj kazoj estis tiel helpema kiel ne eraraj mesaĝoj. Kun retpoŝto fariĝanta pli kaj pli grava ĉi tio ne plu kontentigas (kvazaŭ ĝi estis antaŭe).
Extendoj DSN al SMTP
RFC 1891 proponas iujn etendojn al la SMTP- protokolo, kiu devus rezultigi pli fidindan kaj pli uzeblan DSN-sistemon. Ĝi estas aro de etendoj al la MAIL kaj RCPT-komandoj (se tio signifas nenion al vi, legu kiel SMTP funkcias kaj poste revenos ĉi tien.).
Ne EHLO, Ne Amuzo
Unue ni devas certigi, ke la servilo subtenas DSN. Do ni devas diri al li EHLO kaj aŭskultu atente. Se ĝi respondas per DSN en la listo de listo, ni povas supozi, ke ĝi povos servi niajn petojn. Se ne, tiam ne: ni povas provi alian servilon aŭ simple reakiri retpoŝton sen DSN. Ekzemple (mia enigo estas blua, la eligo de la servilo nigra):
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 Saluton localhost [127.0.0.1], plaĉis renkonti vin
250-EXPN
250-VERB
250-8 BITMIĜO
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 Helpo
Por sorto, inter aliaj aĵoj trovas DSN.
Dissendaj sendiloj de DSN
La sekva komando tipe estas MAIL FROM :. Kun DSN, ĉi tio ne estas malsama. Sed ekzistas du pliaj ebloj kiujn vi povas eldoni: RET kaj ENVID.
La opcio RET estis prefere metita en la komandon MAIL, sed ĝi havas ĉi tie tiel same kiel ĝi estus aliloke. La celo estas specifi kiom da via originala mesaĝo devus esti redonita en kazo de transdona fiasko. Validaj argumentoj estas PLENA kaj HDRS. La unua signifas, ke la kompleta mesaĝo devus esti inkluzivita en la erara mesaĝo, HDRS instruas la servilon nur por redoni la kapliniojn de la malsukcesa poŝto. Se RET ne estas specifita, ĝi estas al la servilo, kion fari. Plejofte HDRS estos la defaŭlta valoro.
ENVID vere apartenas al la sendinto kiel ŝi aŭ (pli ĝuste) ŝia retpoŝta kliento estos la sola kiu nin faras de ĉi tiu envolvaĵa identigilo . Lia celo estas raporti al la sendinto, kiu respondas al retpoŝta mesaĝo. La formato de ĉi tiu ID estas esence forlasita al la imago de la sendinto. Ni ne uzos ENVID en nia ekzemplo (imago!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Sendinto bone
Ŝajne ni nur volas rekomenci la titolojn en nia DSN.
DSN Ricevantaj Etendoj
La RCPT TO: ricevas ankaŭ ĝian egalecon de etendoj: NOTIFY kaj ORCPT.
NOTIFI estas la vera koro de DSN. Ĝi diras al la servilo kiam sendi sendan statulan sciigon. La unua ebla valoro estas NUNIĜO, kio signifas ke sub neniu cirkonstanco DSN devas esti redonita al la sendinto. Ĉi tio ne eblis sen DSN. Tiam estas SUCCESS, kiu sciigos al vi, kiam via poŝto estas kroĉita ĉe ĝia celloko. FAILURE estas la kompenso de SUCCESS (!): DSN alvenos se armeo okazis dum la transdono. La lasta opcio estas prokrasti: vi sciigxos, se ekzistas nekutima malfruo en la livero, sed la rezulto de la reala transdono (sukceso aŭ fiasko) ankoraŭ ne decidis. NUNTA devas esti la sola argumento, se ĝi specifis, la aliaj tri povas aperi en listo, limigita per komo. SUCCESSO kaj FAILURE konsistas al sufiĉe forta teamo (!), Informante al vi (preskaŭ) kazon, kio okazis al via poŝto.
La celo de ORCPT estas konservi la originalan ricevanton de retpoŝta mesaĝo, ekzemple se ĝi estas sendita al alia adreso. La argumento al ĉi tiu opcio estas la retpoŝta adreso de la originala ricevilo kune kun la adreso-tipo. La adreso-adreso venas unue, sekvata de punktokomo kaj fine la adreso. Ekzemple:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Ricevanto Ok (Ruliĝos)
Ĉi tio sekvas la DATO, kiel ni konas ĝin kaj poste, espereble, transdono de sciigo informante vin pri sukceso.
Ĉu DSN Laboras?
Kompreneble, ĉio ĉi beleco kaj gajeco nur funkcios, se la retpoŝtaj agentoj de sendinto al ricevanto subtenos DSN. Iuj tagon ili volas.