IMAP (անգլ.՝ Internet Message Access Protocol), կիրառական մակարդակի ցանցային պրոտոկոլ է՝ էլեկտրոնային փոստ մուտք գործելու և դրա հետ աշխատելու համար։ Հիմնվում է TCP տրանսպորտային պրոտոկոլի վրա և օգտագործում է 143 պորտը։
Ստեղծվել է 1986 թվականին Վաշինգտոնի համալսարանում՝ որպես այլընտրանք POP3-ին։ IMAP-ը օգտվողին ընձեռում է կենտրոնական սերվերի վրա գտնվող փոստարկղերի հետ աշխատելու լայն հնարավորություններ։
IMAP պրոտոկոլը օգտագործող փոստարկղային ծրագիրը կարող է մուտք գործել սերվեր և աշխատել տվյալ սերվերի փոստարկղերում գտնվող ինֆորմացիայի հետ այնպես, կարծես թե այդ ինֆորմացիան տեղակայված լինի տվյալ համակարգչի մեջ։
էլեկտրոնային հաղորդագրությունների հետ կարելի է աշխատել հենց օգտվողի (client) համակարգչից՝ առանց բոլոր հաղորդագրությունները ամբողջական տեսքով՝ սերվեր-օգտվող և օգտվող-սերվեր անընդհատ ուղարկելու անհրաժեշտության։
Հաղորդագրություններ ուղարկելու համար օգտագործվում է SMTP (Simple Mail Transfer Protocol) պրոտոկոլը։
IMAP-ը իրենից ներկայացնում է այլընտրանք POP3-ին։
POP3-ը ունի մի շարք թերություններ, և դրանցից ամենալուրջը այն է, որ օգտվողը չի կարող կառավարել սերվերի վրա գտնվող հաղորդագրությունների պահպանումը և տեղաշարժումը։
Այսինքն, որպես օրենք, բոլոր հաղորդագրությունները միանգամից բեռնվում են սերվերից օգտվողի համակարգիչ, որից հետո նրանք սերվերից հեռացվում են։ Այսինքն օգտվողը չի կարող ընտրել, թե որ նամակը ստանա, իսկ որը՝ ոչ։
POP3-ի տվյալ թերությունները շտկելու նպատակով Վաշինգտոնի համալսարանում մշակվեց նոր պրոտոկոլ, որով օգտվողներին հնարավորություն ընձեռնվեց ստանալ էլ. հաղորդագրություններ տարբեր վայրերից մեկ էլ. փոստի միջոցով, ընդ որում հաղորդագրությունները չեն բաշխվում ըստ ստացման վայրի։
Այսինքն օգտվողը կարող է նույն փոստից օգտվել աշխարհի ցանկացած ծայրում գտնվելով, և փոստի հաղորդագրությունների պարունակությունը չի փոխվում վայրից կախված՝ բոլոր հաղորդագրությունները անխտիր միշտ պահպանվում են սերվերի վրա։
Օգտվողին հնարավորություն է տրվում իր էլ. փոստում գտնվող հաղորդագրությունները և սերվերի էլեկտրոնային փոստարկղերի սպասարկման հետ կապված ֆունկցիաները կառավարել։
POP3-ի օգտագործման ժամանակ օգտվողը միանում է սերվերին միայն այն ժամանակահատվածով, որը անհրաժեշտ է նոր հաղորդագրությունները բեռնելու համար։
IMAP-ի օգտագործման ժամանակ կապը սերվերի հետ ակտիվ է լինում այնքան ժամանակ, ինչքան ժամանակ ակտիվ է լինում օգտվողի ինտերֆեյսը, իսկ հաղորդագրությունները բեռնվում են միայն օգտվողի պահանջով։ Դա թույլ է տալիս կրճատել սերվերի արձագանքման ժամանակը այն օգտվողներին, որոնց փոստարկղերում առկա են շատ հաղորդագրություններ մեծ ծավալով։
POP պրոտոկոլի օգտագործման ժամանակ միայն մեկ օգտվող կարող է միացած լինել մի փոստարկղի, մինչ դեռ IMAP պրոտոկոլը թույլ է տալիս միևնույն փոստարկղին միևնույն ժամանակ մի քանի օգտվողների միացում։
IMAP-ը նաև հնարավորություն է տալիս օգտվողին հետևել փոփոխություններին, որոնք կատարում են իր հետ միաժամանակ միացած մյուս օգտվողները։ Դրոշակային համակարգի շնորհիվ, որը իրականացված է IMAP4-ում, օգտվողը ինֆորմացիա է ստանում հաղորդագրության վիճակի մասին(նոր, կարդացված, հեռացված, սպամ, պոտենցիալ վտանգավոր և այլն)։ Դրոշակների մասին ինֆորմացիան պահպանվում է սերվերի վրա։
IMAP4-ից օգտվողները կարող են փոստարկղերը ստեղծել, վերանվանել, հեռացնել և հաղորդագրություններ տեղափոխել մի էլ. փոստարկղից մյուսը։ Բացի դրանից, կարելի է օգտագործել IMAP4 Access Control List (ACL) Extension ընդլայնումը՝ տարբեր օգտվողների՝ տարբեր փոստարկղեր մուտք գործելու իրավունքների ղեկավարման համար։
Հաղորդագրությունների որոնումը տեղի է ունենում սերվերում։
IMAP4-ը ունի բացահայտ ընդլայնման մեխանիզմ։
IMAP-ը աշխատում է միայն հաղորդագրությունների հետ և չի պահանջում որևէ փաթեթներ հատուկ վերնագրերով։ Ամեն հաղորդագրություն ունի իր հետ կապված մի քանի ատրիբուտ։ Այս ատրիբուտները կարող են նույնականացվել ինչպես առանձին առանձին, այնպես էլ մյուս ատրիբուտների հետ միասին։
Ամեն հաղորդագրության՝ պայմանականորեն համապատասխանեցվում է 32-բիտանի կոդ, որը ունիկալ նույնացուցչի(իդենտիֆիկատորի) հետ համատեղ օգտագործելով կազմում են 64-բիտանի հաջորդականություն, որը կարող է երաշխավորել փոստարկղի մեջ գտնվող հաղորդագրության միանշանակ նույնականացումը(իդենտիֆիկացիան)։ UID-ը ասոցացվում է էլ. փոստարկղի հետ և ուղարկվում է uidvalidity արձագանքի (ok) տեսքով՝ էլ. փոստարկղի ընտրման փուլում։ Եթե անցյալ սեսսիայի UID-ը չի կարող օգտագործվել ինչ որ պատճառով, ապա UID-ը պետք է ինկրեմենտացվի(մեծացվի մեկով)։ Հաղորդագրության UID-ը չպետք է փոխվի սեսսիայի սահմաններում, խորհուրդ չի տրվում փոխել այն նաև սեսսիայից սեսսիա։ Բայց եթե հնարավոր չէ պահպանել հաղորդագրության UID-ը մյուս սեսսիայում, ապա հաջորդ սեսսիան պետք է ունենա նոր ունիկալ կոդ, որը պետք է մեծ լինի ցանկացած օգտագործված հաղորդագրության UID-ից։
Հաղորդագրության համարը էլ. փոստարկղում սկսվում է 1-ից։ Ամեն հաջորդ հաղորդագրություն, սկսած 2-ից, ունի ուղիղ 1-ով ավել հերթական համար, նախորդի համեմատ։ Սեսիայի ընթացքում թույլատրված է հաղորդագրության հերթական համարի փոփոխություն։ Օրինակ, երբ ինչ որ հաղորդագրություն հեռացվում է էլ. փոստարկղից, մնացած հաջորդ հաղորդագրությունների հերթական համարները փոփոխվում են։
Այս ատրիբուտը իրենից ներկայացնում է 0 կամ ավելի անվանավորված լեքսեմներ, փոխկապակցված տվյալ հաղորդագրության հետ։ Դրոշակը տեղադրվում է իրեն այդ ցուցակին ավելացնելով և զրոյացվում է իրեն այդ ցուցակից հեռացնելու ճանապարհով։ IMAP4.1-ում գոյություն ունեն 2 տիպի դրոշակներ՝
Ներկա պահին գոյություն ունեն հետևյալ համակարգային դրոշակները՝
\seen
– հաղորդագրությունը կարդացված է\answered
– հաղորդագրությանը ուղարկված է պատասխան\flagged
– հաղորդագրությունը նշված է որպես «կարևոր»\deleted
– հաղորդագրությունը նշված է որպես հեռացված(ջնջված)\draft
– հաղորդագրությունը նշված է որպես «սևագիր»\recent
– նոր հաղորդագրություն(հայտնվել է տվյալ սեսսիայի ժամանակահատվածում)Հաղորդագրության ստացման ամսաթիվն ու ժամը։
IMAP4.1 միացությունը ակնկալում է օգտվողի և սերվերի միջև կապի հաստատում։ Օգտվողը ուղարկում է սերվերին հրամաններ, սերվերը օգտվողին՝ հարցման կատարման մասին տվյալներ և ծանուցումներ։ Բոլոր հաղորդագրությունները՝ ինչպես սերվերի, այնպես էլ օգտվողի, ունեն տողի տեսք, որոնք վերջանում են հատուկ հաջորդականությամբ։ Ցանկացած ընթացակարգ(պրոցեդուրա) սկսվում է օգտվողի հրամանից։ Օգտվողի ցանկացած հրաման սկսվում է նախածանց-նույնացուցչից(պրեֆիկս-իդենտիֆիկատոր)(սովորաբար կարճ տառա-թվային տող, օրինակ՝ A0001
, A0002
և այլն), որը կոչվում է պիտակ(tag)։ Ամեն հրամանի համար օգտվողը գեներացնում է իր պիտակը։ Հնարավոր է 2 դեպք, երբ օգտվողի կողմից ուղարկված տողը իրենից չի ներկայացնում վերջացված հրաման։ Առաջին դեպքում՝ հրամանի արգումենտը մատակարարվում է կոդով, որը և որոշում է օկտետների քանակը տողի մեջ։ Երկրորդ դեպքում՝ հրամանի արգումենտները պահանջում են արձագանք սերվերի կողմից։ Երկու դեպքում էլ սերվերը ուղարկում է հրամանի շարունակման հարցում, որը սկսվում է + սիմվոլով։ Օգտվողը պետք է վերջացնի մի հրամանի ուղարկումը, մինչ մյուսի ուղարկելը։ Սերվերի պրոտոկոլային ընդունիչը կարդում է օգտվողի կողմից ուղարկված հրմանաի տողը, իրականացնում է դրա վերլուծությունը, առանձնացնում է պարամետրերը և փոխանցում է տվյալները սերվերին։ Հրամանի վերջացման հետ մեկտեղ սերվերը ուղարկում է արձագանք։ Սերվերից օգտվողին փոխանցվող տվյալները, ինչպես նաև կարգավիճակային արձագանքները, որոնք չեն նշանակում հրամանի վերջացումը, ունեն * նախածանց և կոչվում են չպիտակավորված արձագանքներ։ Տվյալները կարող են ուղարկվել սերվերի կողմից և՛ ի պատասխան օգտվողի հրամանի, և՛ սեփական նախաձեռնությամբ։ Տվյալների ձևաչափը(ֆորմատը) կախված չէ ուղարկման պատճառից։ Արձագանքը նշանակում է հրամանի հաջող/անհաջող իրականացումը։ Այն օգտագործում է նույն պիտակը(tag), որը օգտագործվել էր ընթացակարգը(պրոցեդուրա) սկսող օգտվողի հրամանի մեջ։ Այսպիսով, եթե իրականացվում է մեկ հրամանից ավելին, սերվերի պիտակը(tag) նշում է այն հրամանը, որը կանչել է տվյալ արձագանքը։ Կան սերվերի աշխատանքի վերջացման 3 տիպի արձագանքներ՝
ok
(հաջող կատարում)no
(անհաջող կատարում)bad
(պրոտոկոլային սխալ, օրինակ՝ հրամանը ճանաչված չի կամ գտնված է սինտակտային սխալ)Օգտվողի IMAP4.1-ի պրատոկոլային ընդունիչը կարդում է սերվերից ստացած արձագանքի տողը և անում է գործողություններ կախված * կամ + առաջին սիմվոլից։ Օգտվողը պետք է պատրաստ լինի ստանալ սերվերից ցանկացած արձագանք։ Սերվերից ստացված տվյալները պետք է գրված լինեն այնպես, որպեսզի օգտվողը կարողանա դրանք անմիջականորեն օգտագործել՝ առանց որևէ լրացուցիչ հարցում սերվերին ուղարկելու, ճշտելու։
IMAP4.1 սերվերը գտնվում է 4 կարգավիճակներից մեկում։ Հրամանների մեծամասնությունը կարելի է գործածել միայն որոշակի կարգավիճակներում։ Ահա վերը նշված կարգավիճակների ցուցակը՝
Ոչ աուտենտիֆիկացված կարգավիճակում օգտվողը պետք է մուտքագրի անունը և գաղտնաբառը, մինչ նրան հասանելի կդառնա հրամանների մեծամասնությունը։ Այս կարգավիճակի անցումը իրականանում է սերվերի հետ կապ հաստատելու ժամանակ՝ առանց նախապես աուտենտիֆիկացման։ Աուտենտիֆիկացված կարգավիճակում օգտվողը նույնականացված է(իդենտիֆիկացված) և պետք է ընտրի էլ. փոստարկղը, որից հետո իրեն հասանելի կդառան հաղորդագրությունների հետ աշխատելու հրամանները։ Այս կարգավիճակի անցումը իրականանում է սերվերի հետ կապ հաստատելու ժամանակ՝ նախապես աուտենտիֆիկացմամբ, երբ տրված են բոլոր անհրաժեշտ նույնականացման(իդենտիֆիկացիոն) տվյալները կամ էլ. փոստարկղի սխալ ընտրման ժամանակ։ Համակարգը անցում է կատարում ընտրման կարգավիճակ, երբ էլ. փոստարկղի ընտրությունը բարեհաջող իրականացված է։ Համակարգը անցում է կատարում ելքի կարգավիճակ սերվերի հետ կապի ընդհատման արդյունքում՝ օգտվողի հարցման արդյունքում կամ սերվերի անկախ որոշման հետևանքով։
LOGIN
կամ AUTHETICATE
հրամանների բարեհաջող իրականացումSELECT
կամ EXAMINE
հրամանների բարեհաջող իրականացումCLOSE
հրամանի բարեհաջող իրականացում, կամ SELECT
կամ EXAMINE
հրամանների անհաջող իրականացումLOGOUT
հրամանի իրականացում, սերվերի փակում կամ սերվերի աշխատանքի ընդհատումAUTHENTICATE
հրամանը, սերվերը պատասխանում է դրան կանչի տողով, որը ունի base64
կոդավորում։ Այնուհետեև օգտվողը պետք է պատասխան ուղարկի սերվերի վավերականացման ստուգման կանչին, նույնպես կոդավորված base64
-ով։ Եթե սերվերում իրականացված չէ վավերականության ստուգման մեթոդը, որը առաջարկում է օգտվողը՝ սերվերը ներառում է իր պատասխանի մեջ NO
: Դրանից հետո օգտվողը պետք է շարունակի բանակցությունները վավերականության ստուգման մեթոդի համաձայնեցման համար։ Եթե վավերականության ստուգման մեթոդը պարզելու բոլոր փորձերը անցնում են անհաջող, ապա օգտվողը փորձ է կատարում գրանցվել սերվերում LOGIN
հրամանի միջոցով։\DELETED
դրոշակով, ֆիզիկապես հեռացվում են փոստարկղի միջից։ Պարամետրեր չունի։\DELETED
դրոշակով, ֆիզիկապես հեռացվում են փոստարկղի միջից։LIST
հրամանի օգտագործվում է ստանալու համար բոլոր այն էլ. փոստարկղերի ցուցակը, որոնք ակտիվցվել են SUBSCRIBE
հրամանի միջոցով։ Պարամետրերը նույնն են ինչ LIST
հրամանինը։STATUS
հրամանը կարող է օգտագործվել էլ. փոստարկղի ընթացիկ կարգավիճակի մասին տեղեկություն ստանալու համար՝ առանց էլ. փոստարկղը բացելու SELECT
կամ EXAMINE
հրամանների միջոցով։MESSAGES
– էլ. փոստարկղում գտնվող հաղորդագրությունների ընդհանուր քանակըRECENT
– \recent դրոշակով նշված հաղորդագրությունների քանակըUIDNEXT
– UID նույնացուցիչը(իդենտիֆիկատոր), որը տրվելու է հաջորդ նոր հաղորդագրությանըUIDVALIDITY
- էլ. փոստարկղի ունիկալ նույնացուցիչը(իդենտիֆիկատոր)UNSEEN
– առանց \seen դրոշակի հաղորդագրությունների քանակը\Seen
– կարդացված\Answered
– պատասխանված\Flagged
– շտապ\Deleted
– նշված է հեռացման համար\Draft
– սևագիր\Recent
– նոր հաղորդագրություն, այն եկել է էլ. փոստարկղ անցած սեանսի ավարտից հետո\Recent
դրոշակը։ Եթե հրամանի մեջ տրված է ժամանակի պիտակը(tag), ապա այդ ժամանակը կսահմանվի որպես հաղորդագրության ստեղծման ժամ, հակառակ դեպքում որպես ստեծման ժամ սահմանվում է ընթացիկ ժամը։C A003 APPEND saved-messages (\Seen) {247} S + Ready for literal data C Date: Sat, 28 May 2012 21:03:17 -0800 (PST) C From: Grish Meliksetyan <test@testsite.AM> C Subject: Afternoon meeting C To: user@testdomain.info C Message-Id: <B27397-0100000@testsite.AM> C C Hello Armen, do you think we can meet at 13:00 tomorrow? S A003 OK APPEND completed
CHECK
հրամանը։ Այս հրամանը գործածվում է առանց պարամետրերի։\DELETED
դրոշակով, ընդ որում էլ. փոստարկղը չի փակվում։ Սերվերի պատասխանը EXPUNGE
հրամանին ներկայացնում է իրենից էլ. փոստարկղի նոր վիճակի մասին հաշվետվություն։FETCH
, COPY
, STORE
կամ SEARCH
հրամանների հետ համատեղ։ Այս հրամանի օգնությամբ այդ հրամաններում կարելի է օգտագործել իրական UID նունարկիչ(իդենտիֆիկացիոն) համարներ, հաղորդագրությունների միջակայքից թվերի շարքի փոխարեն։NOOP
հրամանին պետք է միշտ լինի դրական։ Քանի որ սերվերը պատասխանի մեջ հաճախ վերադարձնում է այս կամ այն հրամանի կատարման ընթացիկ վիճակը, ապա NOOP
հրամանը միանգամայն կարելի է օգտագործել որպես տրիգգեր՝ սերվերի ընթացիկ վիճակից տեղեկանալու համար։
|