Jakin nola DSN-k SMTP posta elektronikoko entregatze-egoera nola sartu nahi duen.
Inoiz galdetu zenuen bidalitako mezu elektroniko bati gertatua?
SMTP protokoloaren begirada labur bat ere ohartuko zara HELO ohikoaz gain, EHLO ere badago, eta horri esker, Extended SMTP zerbitzariak bere jatorrizko estandarraren gaineko gaitasunak iragartzen ditu. Horietako bat DSN da. DSN? DNA eta DDT nahikoa ez al dira?
Mezu elektronikoak ez fidatzea argudiatzeko, norbaitek " ... zerbitzari hobea lor dezake, nire posta jaten du ... " ez da arraroa. Nik neuk egiten dut. Hala ere, ez dago arrazoirik asko susmo horiei erantzuteko.
Entrega S tatus N otification izan da inguruan RFC 821 geroztik (1982tik). SMTP protokoloaren DATA zatiak amaitutakoan eta zerbitzariak posta elektronikoa onartu duelako entregatzeko ardura du. Edozein arrazoirengatik, hartzaileari ezin zaio horren berri eman, bidaltzailearen bidaltzeari akatsen berri emanez. Honek email ilun batzuk eragin zituen.
Horretaz gain, konbentzio zahar honek akats mezu bat jasotzen zuen edo ezer ez zenuen ezer lortu; kasu horretan ezer ez zenekien: posta elektronikoa iritsi edo agian ez. Errore mezuak kasu askotan errore-mezuak ez diren bezain lagungarria izan ziren. Mezu elektronikoa gero eta garrantzitsuagoa denez, hau ez da egokia (lehen bezala balitz bezala).
DSN Extensions to SMTP
RFC 1891-ek SMTP protokoloak luzapen batzuk proposatzen ditu DSN sistema fidagarriago eta erabilgarriagoa lortzeko. MAIL eta RCPT komandoen luzapenen multzoa da (hau da, ez duzu ezer esan beharrik izango, irakurri nola funtzionatzen duen SMTP eta hemen itzuli).
No EHLO, No Fun
Lehenik eta behin, ziurtatu zerbitzariak DSN onartzen duela. Horrela, EHLO esan behar dugu eta arretaz entzun. Ezaugarri zerrendan DSN bat baino gehiago erantzuten badiogu, gure eskaerak zerbitzatu ahal izango ditugu. Hala ez bada, ez: zerbitzaria beste probatu dezakegu edo, besterik gabe, atzera mezu elektronikoa DSN gabe. Adibidez (nire sarrera urdina izanda, zerbitzariaren irteera beltza):
220 larose.magnet.at Sendmail 8.8.6 / 8.8.6 ESMTP; Eguna, 24 abe 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hello localhost [127.0.0.1], pozik ezagutu zaitu
250-EXPN
250-aditza
250-8BITMIME
250-SIZE
250-DSN
250-Onex
250-ETRN
250-XUSR
250 HELP
Zorionez, besteak beste, DSN aurkituko dugu.
DSN igorlearen luzapenak
Hurrengo komandoa MAIL FROM da. DSN honekin, hau ez da desberdina. Baina badira bi aukera gehiago: RET eta ENVID.
RET aukera MAIL komandoan arbitrarioki jartzen zen, baina hemen egokitzen baita beste inon ere. Helburua da zure jatorrizko mezuaren zenbatekoa itzuli behar den entregatze porrota baten kasuan zehaztea. Baliozko argumentuak FULL eta HDRS dira. Lehenak esan nahi du mezu osatua errore-mezuetan sartu behar dela, HDRS-k zerbitzariari emandako mezuaren goiburuak bakarrik itzultzen ditu. RET zehazten ez bada, zerbitzariari zer egin behar diozu? Kasu gehienetan HDRS balio lehenetsia izango da.
ENVID benetan bidaltzaileari dagokio edo (baizik), bere posta elektronikoaren bezeroak gutun hau identifikatzen duen bakarra izango da. Bere helburua bidaltzailea esatea da, ziurtagiriaren errore-mezu bat bidaltzen duena. ID honen formatua bidaltzailearen irudimenari utzi ohi zaio. Ez dugu ENVID erabiliko gure adibidean (irudimena!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Bidal ezazu ongi
Dirudienez, goiburuak gure DSNn soilik lortu nahi ditugu.
DSN hartzailearen luzapenak
RCPT TO: luzapenen partekatze egokia lortzen du baita ere: NOTIFY eta ORCPT.
NOTIFY DSNren benetako bihotza da. Zerbitzariari jakinarazpen jakinarazpena bidaltzen duenean jakinarazten dio zerbitzariari. Lehenengo balioa inoiz ez da esan nahi, inolaz ere, DSNa bidaltzaileari itzuli behar zaio. Hau ez zen posible DSN gabe. Ondoren, SUCCESS dago, zure helmugara hurbildutako posta elektronikoa jakinaraziko dizu. FAILURE SUCCESS-en kontrakoa (!) Da: DSN bat bidaliko da gertakizun bat gertatu bada. Azken aukera DELAY da: jakinarazpena jasoko duzu atzerapen ezohikoa izanez gero, baina benetako emaitzaren emaitza (arrakasta edo hutsegitea) oraindik ez da erabaki. NIRE ez du zehaztutako baldintza bakarra izan behar , beste hiru zerrenda batean agertuko dira, komaz mugatutakoak. SUCCESS eta FAILURE osatzen dute talde sendo indartsu bat (!), Zure posta elektronikoa gertatu den kasu batean (ia).
ORCPTren helburua mezu elektroniko baten jatorrizko hartzailea aurreztea da, adibidez, beste helbide batera birbidaltzen bada. Aukera honen argumentua jatorrizko hartzailearen helbide elektronikoa da, helbide mota batera. Helbide mota lehenengoa dator, puntu eta koma bat eta, azkenik, helbidea. Adibidez:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Hartzailea ongi (ilaran)
Jarraian DATUAK ezagutzen ditugunean eta azkenean, zorionez, arrakastaz jakinaraztea.
DSN lan egiten du?
Noski, edertasun hau eta engainatzaileak bidalitako mezularitzako garraiolariak hartzekodunentzako DSN laguntza jasotzen dutenean soilik funtzionatuko du. Egun bat egingo dute.