Պարզեք, թե ինչպես է DSN- ը մտադիր է ներկայացնել առաքման կարգավիճակը SMTP էլ.
Երբեւէ մտածել եք, թե ինչ է տեղի ունեցել ձեր ուղարկած էլ.
Նույնիսկ SMTP պրոտոկոլի կարճ դիտարկումը կտեսնեք, որ բացի սովորական HELO- ից, կա նաեւ EHLO, որն ընդլայնված SMTP սերվերին դարձնում է իր հնարավորությունները գովազդային բնույթից դուրս: Դրանցից մեկը DSN է: DSN? ԴՆԹ-ն եւ DDT- ը բավարար չեն:
Ապացուցելու համար, որ էլփոստը անհավատալի է, որ որեւէ մեկը պետք է « ... իրենց սերվերը լավը կերակրեն, ուտում է իմ փոստը ... », հազվադեպ: Ես դա անում եմ: Այնուամենայնիվ, այս կասկածները պաշտպանելու շատ բան չկա:
Առաքման պայմանագրի ժամկետը մոտավորապես եղել է RFC 821-ից (1982 թվականից): Երբ SMTP- ի արձանագրության DATA հատվածն ավարտված է, եւ սերվերը ընդունում է էլփոստի առաքման համար, այն պատասխանատու է դրա համար: Եթե որեւէ պատճառով, այն չի կարող ստանալ այն ստացողի միջոցով, այն պետք է ուղարկի այն, որ սխալը ծանուցվի բնօրինակի ուղարկողին: Դա հանգեցրեց որոշ անհասկանալի էլեկտրոնային փոստին :
Դրանից բացի, այս հին կոնվենցիան նշանակում էր, որ դուք կամ սխալ հաղորդագրություն ստացել եք կամ ոչինչ չեք ստացել, որի դեպքում ոչինչ չգիտեիք. Էլ-փոստը կարող էր ժամանել, թե չէ: Շատ դեպքերում սխալի հաղորդագրությունները նույնքան օգտակար էին, որքան սխալ հաղորդագրություններ: Էլեկտրոնային փոստով ավելի ու ավելի կարեւոր է դառնում, դա այլեւս բավարար չէ (ինչպես նախկինում էր):
DSN ընդլայնումներ SMTP- ին
RFC 1891- ը առաջարկում է որոշակի ընդարձակումներ SMTP արձանագրության մեջ, որը պետք է դառնա ավելի հուսալի եւ առավել մատչելի DSN համակարգ: Դա MAIL- ի եւ RCPT- ի հրամանների ընդլայնման մի շարք է (եթե դա նշանակում է ոչինչ, կարդացեք, թե ինչպես SMTP- ն աշխատում է եւ այնուհետեւ վերադառնալու այստեղ):
Ոչ EHLO, ոչ Ժամանց
Նախ, մենք պետք է համոզվենք, որ սերվերը սատարում է DSN- ին: Այսպիսով, մենք պետք է ասենք EHLO- ին եւ ուշադիր լսենք: Եթե դա պատասխանում է DSN- ի հետ, հնարավորությունների ցանկում, կարելի է ենթադրել, որ այն կկարողանա ծառայել մեր պահանջներին: Եթե ոչ, ապա ոչ `մենք կարող ենք փորձել մեկ այլ սերվեր կամ պարզապես վերադառնալ էլփոստով առանց DSN- ին: Օրինակ (իմ ներածումը կապույտ է, սերվերի արտադրանքի սեւ):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Օգոստոսի 1997 18:23:22 +0200
EHLO տեղական համայնքը
250-larose.magnet.at Hello localhost [127.0.0.1], ուրախ է հանդիպել ձեզ
250-EXPN
250-ՎԵՐԲ
250-8BITMIME
250-ՍԻՄ
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 ՀԱՐՑ
Բարեբախտաբար, ի թիվս այլ բաների, մենք գտնում ենք DSN- ն:
DSN ուղարկողի ընդլայնում
Հաջորդ հրամանը սովորաբար MAIL FROM :. DSN- ի հետ, սա տարբեր չէ: Սակայն կան երկու լրացուցիչ տարբերակներ, որոնք կարող եք թողարկել: RET եւ ENVID:
The RET տարբերակը բավականին կամայական տեղադրվեց MAIL հրամանի մեջ, բայց այն տեղավորվում է նաեւ այնտեղ, որտեղ այլ տեղ է: Նպատակն է պարզել, թե որքանով է ձեր սկզբնական հաղորդագրությունը վերադարձվել, եթե առաքման ձախողման դեպքում: Վավեր փաստարկները FULL եւ HDRS են: Առաջինը նշանակում է, որ ամբողջական հաղորդագրությունը պետք է ընդգրկվի սխալի հաղորդագրության մեջ, HDRS- ը հրահանգ է տալիս սերվերին միայն վերադարձնել ձախողված նամակների վերնագրերը: Եթե RET- ը չի նշվում, ապա այն սերվերին մինչեւ ինչ է անելու: Շատ դեպքերում HDRS- ը կլինի լռելյայն արժեք:
ENVID- ը, ըստ էության, պատկանում է ուղարկողին, քանի որ նա, կամ, իր էլփոստի հաճախորդը, կլինի միայն մեկը, որը ստիպում է մեզ այս ծրարի նույնականացման համար : Դրա նպատակն է ասել, որ ուղարկողը, որը նամակ է հղում, հնարավոր է, ուղարկված սխալ հաղորդագրությանը: Այս ID- ի ձեւաչափը հիմնականում թողարկվում է ուղարկողի երեւակայության վրա: Մենք չենք օգտագործում ENVID մեր օրինակում (երեւակայություն):
Փոստ `sender@example.com RET = HDRS
250 sender@example.com ... Ուղղորդիչը ok
Ակնհայտ է, որ մենք միայն ցանկանում ենք վերցնել վերնագրերը մեր DSN- ում:
DSN ստացողի ընդլայնում
The RCPT TO- ը ստանում է նաեւ ընդլայնումների իր արդար մասնիկը. NOTIFY եւ ORCPT:
NOTIFY- ը DSN- ի իրական սիրտն է: Այն տեղեկացնում է սերվերին, երբ առաքման կարգավիճակի մասին ծանուցում ուղարկելու դեպքում: Առաջին հնարավոր արժեքը երբեք չի նշանակում, որ ոչ մի դեպքում DSN- ն չպետք է վերադարձվի ուղարկողին: Դա հնարավոր չէր առանց DSN- ի: Այնուհետեւ կա հաջողություն, որը կտեղեկացնի ձեզ, երբ ձեր փոստը հայտնվել է իր նշանակման վայրում: FAILURE- ը Հաջողության գործընկերն է (!). DSN- ն կժամանի եթե առաքման ընթացքում տեղի ունեցած արատը: Վերջին տարբերակը DELAY- ը Ձեզ կտեղեկացվի, եթե առաքման ընթացքում անսպասելի ուշացում կա, սակայն փաստացի առաքման արդյունքը (հաջողություն կամ ձախողում) դեռ որոշված չէ: ԵՐԲԵՔ չպետք է լինի միակ փաստարկը, եթե նշվի, մյուս երեքը կարող են հայտնվել ցուցակում, որը բաժանվում է ստորակետով: Հաջողությունը եւ անսպասելիությունը կազմում են բավականին ուժեղ թիմը (!), Պատմելով ձեզ (գրեթե) ցանկացած դեպքի մասին, ինչ տեղի է ունեցել ձեր փոստով:
ORCPT- ի նպատակը էլփոստի հաղորդագրության բնօրինակ ստացողի պահպանումը է, օրինակ, եթե այն փոխանցվում է մեկ այլ հասցեով: Այս տարբերակի փաստարկը բնօրինակի ստացողի էլեկտրոնային հասցեն է, ինչպես նաեւ հասցեի տեսակը: Անվանման տեսակը առաջինն է, որին հաջորդում է կետային վահանակը եւ, վերջապես, հասցեն: Օրինակ:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Recipient ok (հերթը)
Դրան հետեւում է DATA- ն, քանի որ մենք գիտենք դա եւ, ի վերջո, հուսով եմ, որ առաքման կարգավիճակի ծանուցումը ձեզ հաջողություն է հաղորդում:
Արդյոք DSN- ն աշխատում է:
Իհարկե, այս բոլոր գեղեցկությունն ու խելքը կգործեն միայն այն դեպքում, եթե փոստատարի փոխանակողը ուղարկողի կողմից ստացողին աջակցի DSN- ին: Մի օր նրանք կստանան: