«IMAP»–ի խմբագրումների տարբերություն

Վիքիպեդիայից՝ ազատ հանրագիտարանից
Content deleted Content added
No edit summary
չ r2.7.2) (Ռոբոտը ավելացնում է․: sr:IMAP
Տող 265. Տող 265.
[[sk:Internet Message Access Protocol]]
[[sk:Internet Message Access Protocol]]
[[sl:IMAP]]
[[sl:IMAP]]
[[sr:IMAP]]
[[sv:Internet Message Access Protocol]]
[[sv:Internet Message Access Protocol]]
[[ta:இணையச் செய்தி அணுகு நெறிமுறை]]
[[ta:இணையச் செய்தி அணுகு நெறிமுறை]]

10:47, 6 Սեպտեմբերի 2012-ի տարբերակ

IMAP (անգլ.՝ Internet Message Access Protocol), կիրառական մակարդակի ցանցային պրոտոկոլ է՝ էլեկտրոնային փոստ մուտք գործելու և դրա հետ աշխատելու համար: Հիմնվում է TCP տրանսպորտային պրոտոկոլի վրա և օգտագործում է 143 պորտը:

Ստեղծվել է 1986 թվականին Վաշինգտոնի համալսարանում որպես այլընտրանք POP3-ին: IMAP-ը ընձեռում է օգտվողին լայն հնարավորություններ կենտրոնական սերվերի վրա գտնվող փոստարկղերի հետ աշխատելու համար:

IMAP պրոտոկոլը օգտագործող փոստարկղային ծրագիրը կարող է մուտք գործել սերվեր և աշխատել տվյալ սերվերի փոստարկղերում գտնվող ինֆորմացիայի հետ այնպես, կարծես թե այդ ինֆորմացիան տեղակայված լինի տվյալ համակարգչի մեջ:

էլեկտրոնային հաղորդագրությունների հետ կարելի է աշխատել հենց օգտվողի(client) համակարգչից՝ առանց բոլոր հաղորդագրությունները ամբողջական տեսքով՝ սերվեր-օգտվող և օգտվող-սերվեր անընդհատ ուղարկելու անհրաժեշտության:

Հաղորդագրություններ ուղարկելու համար օգտագործվում է SMTP(Simple Mail Transfer Protocol) պրոտոկոլը:

IMAP պրոտոկոլի մշակման նպատակը

IMAP-ը իրենից ներկայացնում է այլընտրանք POP3-ին:
POP3-ը ունի մի շարք թերություններ, և դրանցից ամենալուրջը այն է, որ օգտվողը չի կարող կառավարել սերվերի վրա գտնվող հաղորդագրությունների պահպանումը և տեղաշարժումը:
Այսինքն, որպես օրենք, բոլոր հաղորդագրությունները միանգամից բեռնվում են սերվերից օգտվողի համակարգիչ, որից հետո նրանք սերվերից հեռացվում են: Այսինքն օգտվողը չի կարող ընտրել, թե որ նամակը ստանա, իսկ որը՝ ոչ:
POP3-ի տվյալ թերությունները շտկելու նպատակով Վաշինգտոնի համալսարանում մշակվեց նոր պրոտոկոլ, որով օգտվողներին հնարավորություն ընձեռնվեց ստանալ էլ. հաղորդագրություններ տարբեր վայրերից մեկ էլ. փոստի միջոցով, ընդ որում հաղորդագրությունները չեն բաշխվում ըստ ստացման վայրի:
Այսինքն օգտվողը կարող է նույն փոստից օգտվել աշխարհի ցանկացած ծայրում գտնվելով, և փոստի հաղորդագրությունների պարունակությունը չի փոխվում վայրից կախված՝ բոլոր հաղորդագրությունները անխտիր միշտ պահպանվում են սերվերի վրա:
Օգտվողին հնարավորություն է տրվում իր էլ. փոստում գտնվող հաղորդագրությունները և սերվերի էլեկտրոնային փոստարկղերի սպասարկման հետ կապված ֆունկցիաները կառավարել:

POP3-ի հանդեպ ունեցած առավելությունները

POP3-ի օգտագործման ժամանակ օգտվողը միանում է սերվերին միայն այն ժամանակահատվածով, որը անհրաժեշտ է նոր հաղորդագրությունները բեռնելու համար:
IMAP-ի օգտագործման ժամանակ կապը սերվերի հետ ակտիվ է լինում այնքան ժամանակ, ինչքան ժամանակ ակտիվ է լինում օգտվողի ինտերֆեյսը, իսկ հաղորդագրությունները բեռնվում են միայն օգտվողի պահանջով: Դա թույլ է տալիս կրճատել սերվերի արձագանքման ժամանակը այն օգտվողներին, որոնց փոստարկղերում առկա են շատ հաղորդագրություններ մեծ ծավալով:
POP պրոտոկոլի օգտագործման ժամանակ միայն մեկ օգտվող կարող է միացած լինել մի փոստարկղի, մինչ դեռ IMAP պրոտոկոլը թույլ է տալիս միևնույն փոստարկղին միևնույն ժամանակ մի քանի օգտվողների միացում:
IMAP-ը նաև հնարավորություն է տալիս օգտվողին հետևել փոփոխություններին, որոնք կատարում են իր հետ միաժամանակ միացած մյուս օգտվողները: Դրոշակային համակարգի շնորհիվ, որը իրականացված է IMAP4-ում, օգտվողը ինֆորմացիա է ստանում հաղորդագրության վիճակի մասին(նոր, կարդացված, հեռացված, սպամ, պոտենցիալ վտանգավոր և այլն): Դրոշակների մասին ինֆորմացիան պահպանվում է սերվերի վրա:
IMAP4-ից օգտվողները կարող են փոստարկղերը ստեղծել, վերանվանել, հեռացնել և հաղորդագրություններ տեղափոխել մի էլ. փոստարկղից մյուսը: Բացի դրանից, կարելի է օգտագործել IMAP4 Access Control List (ACL) Extension ընդլայնումը՝ տարբեր օգտվողների՝ տարբեր փոստարկղեր մուտք գործելու իրավունքների ղեկավարման համար:
Հաղորդագրությունների որոնումը տեղի է ունենում սերվերում:
IMAP4-ը ունի բացահայտ ընդլայնման մեխանիզմ:

IMAP պրոտոկոլի տարբերակները

  • Original IMAP (1986 թ. սպեցիֆիկացիան բացակայում է)
  • IMAP2 (1988 թ. - RFC 1064, 1990 թ. - RFC 1176)
  • IMAP3 (1991 թ. - RFC 1203)
  • IMAP2bis (սպեցիֆիկացիան գոյություն ունի միայն 1993 թ. սևագիր տարբերակով)
  • IMAP4 (վերանվանված IMAP2bis)

Հաղորդագրությունները և դրանց ատրիբուտները

IMAP-ը աշխատում է միայն հաղորդագրությունների հետ և չի պահանջում որևէ փաթեթներ հատուկ վերնագրերով: Ամեն հաղորդագրություն ունի իր հետ կապված մի քանի ատրիբուտ: Այս ատրիբուտները կարող են նույնականացվել ինչպես առանձին առանձին, այնպես էլ մյուս ատրիբուտների հետ միասին:

UID

Ամեն հաղորդագրության՝ պայմանականորեն համապատասխանեցվում է 32-բիտանի կոդ, որը ունիկալ նույնացուցչի(իդենտիֆիկատորի) հետ համատեղ օգտագործելով կազմում են 64-բիտանի հաջորդականություն, որը կարող է երաշխավորել փոստարկղի մեջ գտնվող հաղորդագրության միանշանակ նույնականացումը(իդենտիֆիկացիան): UID-ը ասոցացվում է էլ. փոստարկղի հետ և ուղարկվում է uidvalidity արձագանքի (ok) տեսքով՝ էլ. փոստարկղի ընտրման փուլում: Եթե անցյալ սեսսիայի UID-ը չի կարող օգտագործվել ինչ որ պատճառով, ապա UID-ը պետք է ինկրեմենտացվի(մեծացվի մեկով): Հաղորդագրության UID-ը չպետք է փոխվի սեսսիայի սահմաններում, խորհուրդ չի տրվում փոխել այն նաև սեսսիայից սեսսիա: Բայց եթե հնարավոր չէ պահպանել հաղորդագրության UID-ը մյուս սեսսիայում, ապա հաջորդ սեսսիան պետք է ունենա նոր ունիկալ կոդ, որը պետք է մեծ լինի ցանկացած օգտագործված հաղորդագրության UID-ից:

Հաղորդագրության հերթական համարը

Հաղորդագրության համարը էլ. փոստարկղում սկսվում է 1-ից: Ամեն հաջորդ հաղորդագրություն, սկսաց 2-ից, ունի ուղիղ 1-ով ավել հերթական համար, նախորդի համեմատ: Սեսսիայի ընթցքում թույլատրված է հաղորդագրության հերթական համարի փոփոխություն: Օրինակ, երբ ինչ որ հաղորդագրություն հեռացվում է էլ. փոստարկղից, մնացած հաջորդ հաղորդագրությունների հերթական համարները փոփոխվում են:

Հաղորդագրությունների դրոշակները

Այս ատրիբուտը իրենից ներկայացնում է 0 կամ ավելի անվանավորված լեքսեմներ, փոխկապակցված տվյալ հաղորդագրության հետ: Դրոշակը տեղադրվում է իրեն այդ ցուցակին ավելացնելով և զրոյացվում է իրեն այդ ցուցակից հեռացնելու ճանապարհով: IMAP4.1-ում գոյություն ունեն 2 տիպի դրոշակներ՝

  • Անընդհատ դրոշակ
  • Տվյալ սեսսիայի ժամանակահատվածում գործող դրոշակ

Ներկա պահին գոյություն ունեն հետևյալ համակարգային դրոշակները՝

  • \seen – հաղորդագրությունը կարդացված է
  • \answered – հաղորդագրությանը ուղարկված է պատասխան
  • \flagged – հաղորդագրությունը նշված է որպես «կարևոր»
  • \deleted – հաղորդագրությունը նշված է որպես հեռացված(ջնջված)
  • \draft – հաղորդագրությունը նշված է որպես «սևագիր»
  • \recent – նոր հաղորդագրություն(հայտնվել է տվյալ սեսսիայի ժամանակահատվածում)

Հաղորդագրության ներքին ամսաթիվը և ժամը սերվերի վրա

Հաղորդագրության ստացման ամսաթիվն ու ժամը:

  • SMTP պրոտոկոլի օգնությամբ ուղարկված հաղորդագրությունների համար՝ վերջնական հասցեատիրոջը հասնելու ամսաթիվն ու ժամը
  • Կրկնօրինակման(copy) հրամանով հասցված հաղորդագրությունների համար՝ հաղորդագրությունը ուղարկողի ներքին ամսաթիվն ու ժամը
  • Append հրամանի օգտագործման ժամանակ՝ ամսաթիվն ու ժամը, որ տրվել են հրամանի պարամետրերում

Այլ ատրիբուտներ

  • Հաղորդագրության չափը՝ օկտետների քանակը հաղորդագրության մեջ
  • Հաղորդագրության ծրարի կառուցվածքը
  • Հաղորդագրության մարմնի կառուցվածքը

Օգտվողի և սերվերի փոխազդեցությունը

IMAP4.1 միացությունը ակնկալում է օգտվողի և սերվերի միջև կապի հաստատում: Օգտվողը ուղարկում է սերվերին հրամաններ, սերվերը օգտվողին՝ հարցման կատարման մասին տվյալներ և ծանուցումներ: Բոլոր հաղորդագրությունները՝ ինչպես սերվերի, այնպես էլ օգտվողի, ունեն տողի տեսք, որոնք վերջանում են հատուկ հաջորդականությամբ: Ցանկացած ընթացակարգ(պրոցեդուրա) սկսվում է օգտվողի հրամանից: Օգտվողի ցանկացած հրաման սկսվում է նախածանց-նույնացուցչից(պրեֆիկս-իդենտիֆիկատոր)(սովորաբար կարճ տառա-թվային տող, օրինակ՝ A0001, A0002 և այլն), որը կոչվում է պիտակ(tag): Ամեն հրամանի համար օգտվողը գեներացնում է իր պիտակը: Հնարավոր է 2 դեպք, երբ օգտվողի կողմից ուղարկված տողը իրենից չի ներկայացնում վերջացված հրաման: Առաջին դեպքում՝ հրամանի արգումենտը մատակարարվում է կոդով, որը և որոշում է օկտետների քանակը տողի մեջ: Երկրորդ դեպքում՝ հրամանի արգումենտները պահանջում են արձագանք սերվերի կողմից: Երկու դեպքում էլ սերվերը ուղարկում է հրամանի շարունակման հարցում, որը սկսվում է + սիմվոլով: Օգտվողը պետք է վերջացնի մի հրամանի ուղարկումը, մինչ մյուսի ուղարկելը: Սերվերի պրոտոկոլային ընդունիչը կարդում է օգտվողի կողմից ուղարկված հրմանաի տողը, իրականացնում է դրա վերլուծությունը, առանձնացնում է պարամետրերը և փոխանցում է տվյալները սերվերին: Հրամանի վերջացման հետ մեկտեղ սերվերը ուղարկում է արձագանք: Սերվերից օգտվողին փոխանցվող տվյալները, ինչպես նաև կարգավիճակային արձագանքները, որոնք չեն նշանակում հրամանի վերջացումը, ունեն * նախածանց և կոչվում են չպիտակավորված արձագանքներ: Տվյալները կարող են ուղարկվել սերվերի կողմից և՛ ի պատասխան օգտվողի հրամանի, և՛ սեփական նախաձեռնությամբ: Տվյալների ձևաչափը(ֆորմատը)կախված չէ ուղարկման պատճառից: Արձագանքը նշանակում է հրամանի հաջող/անհաջող իրականացումը: Այն օգտագործում է նույն պիտակը(tag), որը օգտագործվել էր ընթացակարգը(պրոցեդուրա) սկսող օգտվողի հրամանի մեջ: Այսպիսով, եթե իրականացվում է մեկ հրամանից ավելին, սերվերի պիտակը(tag) նշում է այն հրամանը, որը կանչել է տվյալ արձագանքը: Կան սերվերի աշխատանքի վերջացման 3 տիպի արձագանքներ՝

  • ok(հաջող կատարում)
  • no(անհաջող կատարում)
  • bad(պրոտոկոլային սխալ, օրինակ՝ հրամանը ճանաչված չի կամ գտնված է սինտակտային սխալ)

Օգտվողի IMAP4.1-ի պրատոկոլային ընդունիչը կարդում է սերվերից ստացած արձագանքի տողը և անում է գործողություններ կախված * կամ + առաջին սիմվոլից: Օգտվողը պետք է պատրաստ լինի ստանալ սերվերից ցանկացած արձագանք: Սերվերից ստացված տվյալները պետք է գրված լինեն այնպես, որպեսզի օգտվողը կարողանա դրանք անմիջականորեն օգտագործել՝ առանց որևէ լրացուցիչ հարցում սերվերին ուղարկելու, ճշտելու:

IMAP սերվերի կարգավիճակները

IMAP4.1 սերվերը գտնվում է 4 կարգավիճակներից մեկում: Հրամանների մեծամասնությունը կարելի է գործածել միայն որոշակի կարգավիճակներում: Ահա վերը նշված կարգավիճակների ցուցակը՝

  • Ոչ աուտենտիֆիկացված
  • Աուտենտիֆիկացված
  • Ընտրման
  • Ելքի

Ոչ աուտենտիֆիկացված կարգավիճակում օգտվողը պետք է մուտքագրի անունը և գաղտնաբառը, մինչ նրան հասանելի կդառնա հրամանների մեծամասնությունը: Այս կարգավիճակի անցումը իրականանում է սերվերի հետ կապ հաստատելու ժամանակ՝ առանց նախապես աուտենտիֆիկացման: Աուտենտիֆիկացված կարգավիճակում օգտվողը նույնականացված է(իդենտիֆիկացված) և պետք է ընտրի էլ. փոստարկղը, որից հետո իրեն հասանելի կդառան հաղորդագրությունների հետ աշխատելու հրամանները: Այս կարգավիճակի անցումը իրականանում է սերվերի հետ կապ հաստատելու ժամանակ՝ նախապես աուտենտիֆիկացմամբ, երբ տրված են բոլոր անհրաժեշտ նույնականացման(իդենտիֆիկացիոն) տվյալները կամ էլ. փոստարկղի սխալ ընտրման ժամանակ: Համակարգը անցում է կատարում ընտրման կարգավիճակ, երբ էլ. փոստարկղի ընտրությունը բարեհաջող իրականացված է: Համակարգը անցում է կատարում ելքի կարգավիճակ սերվերի հետ կապի ընդհատման արդյունքում՝ օգտվողի հարցման արդյունքում կամ սերվերի անկախ որոշման հետևանքով:

IMAP սերվերի աշխատանքի սկզբունքը


  1. Միացում առանց նախապես աուտենտիֆիկացման
  2. Միացում նախապես աուտենտիֆիկացմամբ
  3. Միացումը մերժված է
  4. LOGIN կամ AUTHETICATE հրամանների բարեհաջող իրականացում
  5. SELECT կամ EXAMINE հրամանների բարեհաջող իրականացում
  6. CLOSE հրամանի բարեհաջող իրականացում, կամ SELECT կամ EXAMINE հրամանների անհաջող իրականացում
  7. LOGOUT հրամանի իրականացում, սերվերի փակում կամ սերվերի աշխատանքի ընդհատում

IMAP պրոտոկոլի հրամանները

LOGIN
Թույլ է տալիս օգտվողին IMAP սերվերի վրա գրանցման ժամանակ օգտագործել օգտվողի նույնացուցիչը(իդենտիֆիկատոր) և գաղտնաբառը սովորական տեքստային տեսքով: Սա ամենալավ մեթոդը չէ, բայց երբեմն միակ տարբերակն է սերվերին միանալու համար:


AUTHENTICATE
Թույլ է տալիս օգտվողին IMAP սերվերի վրա գրանցվելուց օգտագործել վավերականության ստուգման այլընտրանքային մեթոդներ: Օգտվողների վավերականության անհատական ստուգումը պարտադիր չի հանդիսանում և ոչ բոլոր IMAP սերվերներում է իրականացրած: Նաև այդպիսի ստուգման իրականացուման ձևերը կարող են տարբերվել կախված սերվերից: Երբ օգտվողը մուտքագրում է AUTHENTICATE հրամանը, սերվերը պատասխանում է դրան կանչի տողով, որը ունի base64 կոդավորում: Այնուհետեև օգտվողը պետք է պատասխան ուղարկի սերվերի վավերականացման ստուգման կանչին, նույնպես կոդավորված base64-ով: Եթե սերվերում իրականացված չէ վավերականության ստուգման մեթոդը, որը առաջարկում է օգտվողը՝ սերվերը ներառում է իր պատասխանի մեջ NO: Դրանից հետո օգտվողը պետք է շարունակի բանակցությունները վավերականության ստուգման մեթոդի համաձայնեցման համար: Եթե վավերականության ստուգման մեթոդը պարզելու բոլոր փորձերը անցնում են անհաջող, ապա օգտվողը փորձ է կատարում գրանցվել սերվերում LOGIN հրամանի միջոցով:


CLOSE
Փակում է էլ. փոստարկղը: Երբ էլ. փոստարկղը փակված է, բոլոր հաղորդագրությունները, որոնք նշվել էին \DELETED դրոշակով, ֆիզիկապես հեռացվում են փոստարկղի միջից: Պարամետրեր չունի:


LOGOUT
Վերջացնում է օգտվողի ընթացիկ նույնացուցչի համար սեանսը և փակում է բոլոր բացված էլ. փոստարկղերը: Բոլոր հաղորդագրությունները, որոնք նշվել էին \DELETED դրոշակով, ֆիզիկապես հեռացվում են փոստարկղի միջից:


CREATE
Ստեղծում է նոր էլ. փոստարկղ: Նոր էլ. փոստարկղերի անունները և տեղակայությունը որոշվում են սերվերի ընդհանուր հատկանիշներով:


DELETE
Օգտագործվում է էլ. փոստարկղերի համար: IMAP սերվերը, ստանալով այս հրամանը, կփորձի հեռացնել այն փոստարկղը, որի անունը նշվել էր հրամանի մեջ որպես արգումենտ: Էլ. փոստարկղի մեջ գտնվող բոլոր հաղորդագրությունները հեռացվում են էլ. փոստարկղի հետ միասին և վերականգնման ենթակա չեն լինում:


RENAME
Փոխում է էլ. փոստարկղի անունը: Ասյ հրամանը ունի 2 արգումենտ՝ էլ. փոստարկղի անունը, որը պետք է փոխել և նոր անունը:


SUBSCRIBE
Ավելացնում է էլ. փոստարկղը օգտվողի ակտիվ էլ. փոստարկղերի ցուցկակի մեջ: Այս հրամանի մեջ օգտագործվում է միայն 1 պարամետր՝ էլ. փոստարկղի անունը, որը պետք է ավելացնել ցուցակի մեջ: Էլ. փոստարկղը պարտադիր չէ, որ գույություն ունենա, որպեսզի նրան հնարավոր լինի ավելացնել ակտիվ էլ. փոստարկղերի ցուցկակի մեջ՝ դա թույլ է տալիս ավեացնել ակտիվ էլ. փոստարկղերի ցուցկակի մեջ էլ. փոստարկղեր, որոնք դեռ ստեղծված չեն, կամ հեռացնել դրանք, եթե դրանք դատարկ են:


UNSUBSCRIBE
Հեռացնում է էլ. փոստարկղը օգտվողի ակտիվ էլ. փոստարկղերի ցուցկակի միջից: Այս հրամանի մեջ ևս օգտագործվում է միայն 1 պարամետր՝ էլ. փոստարկղի անունը, որը պետք է հեռացնել օգտվողի ակտիվ էլ. փոստարկղերի ցուցակի միջից: Ընդ որում էլ. փոստարկղը չի հեռացվում ֆիզիկապես:


LIST
Ստանալ օգտվողի բոլոր էլ. փոստարկղերի ցուցակը: Ունի 2 պարամետր:


LSUB
Ի տարբերություն LIST հրամանի օգտագործվում է ստանալու համար բոլոր այն էլ. փոստարկղերի ցուցակը, որոնք ակտիվցվել են SUBSCRIBE հրամանի միջոցով: Պարամետրերը նույնն են ինչ LIST հրամանինը:


STATUS
Գոյացնում է հարցում էլ. փոստարկղի ընթացիկ կարգավիճակի մասին: Ունի 2 պարամետր. առաջինը՝ էլ. փոստարկղի անունը, որի նկատմամբ կիրառվում է հրամանը, իսկ երկրորդը՝ այն չափանիշների ցուցակը, ըստ որոնցի օգտվողը ցանկաանում է ստանալ ինֆորմացիա: STATUS հրամանը կարող է օգտագործվել էլ. փոստարկղի ընթացիկ կարգավիճակի մասին տեղեկություն ստանալու համար՝ առանց էլ. փոստարկղը բացելու SELECT կամ EXAMINE հրամանների միջոցով:
Օգտվողը կարող է ստանալ ինֆորմացիա հետևյալ չափանիշներով՝
  • MESSAGES – էլ. փոստարկղում գտնվող հաղորդագրությունների ընդհանուր քանակը
  • RECENT – \recent դրոշակով նշված հաղրդագրությունների քանակը
  • UIDNEXT – UID նույնացուցիչը(իդենտիֆիկատոր), որը տրվելու է հաջորդ նոր հաղորդագրությանը
  • UIDVALIDITY - էլ. փոստարկղի ունիկալ նույնացուցիչը(իդենտիֆիկատոր)
  • UNSEEN – առանց \seen դրոշակի հաղորդագրությունների քանակը


APPEND
Ավելացնում է հաղորդագրությունը նշված էլ. փոստարկղի վերջում: Որպես արգումենտներ նշվում են էլ. փոստարկղի անունը, հաղորդագրությունների դրոշակները(ոչ պարտադիր), ժամանակի պիտակը(tag) (ոչ պարտադիր) և հենց ինքը հաղորդագրությունը՝ վերնագիրը և մարմինը:
Գոյություն ունեն հաղորդագրությունների հետևյալ դրոշակները՝
  • \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


MULTIAPPEND
Ընդլայնումը, նկարագրված RFC 3502-ում, թույլ է տալիս մեկ հրամանով էլ. փոստարկղ ավելացնել մի քանի հաղորդագրություններ:


CHECK
Էլ. փոստարկղում տեղադրում է ստուգողական կետը: Ցանկացած գործողություն, ինչպես օրինակ՝ տվյալների պահպանումը սերվերի հիշողությունից նրա կոշտ սկավառակի վրա, պետք է կատարվեն էլ. փոստարկղի որոշակի կարգավիճակում գտնվելուց: Հենց էլ. փոստարկղի վրա սկավառակային կամ նման այլ գործողությունների կատարումից հետո էլ ամբողջականության ստուգման համար գործածվում է CHECK հրամանը: Այս հրամանը գործածվում է առանց պարամետրերի:


EXPUNGE
Էլ. փոստարկղից հեռացնում է բոլոր այն հաղորդագրությունները, որոնք նշված են եղել \DELETED դրոշակով, ընդ որում էլ. փոստարկղը չի փակվում: Սերվերի պատախանը EXPUNGE հրամանին ներկայացնում է իրենից էլ. փոստարկղի նոր վիճակի մասին հաշվետվություն:


SEARCH
Ակտիվ էլ. փոստարկղի մեջ հաղորդագրությունների փնտրում որոշակի չափանիշներով՝ հետագա արդյունքների ցուցադրմամբ հաղորդագրության հերթական համարի տեսքով: Հնարավոր է փնտրում հաղորդագրության մարմնի մեջ գտնվող ինչ որ տեքստային տողի, կամ հաղորդագրություններ, որոնք ունեն որոշակի դրոշակ, կամ որոնք ստացված են եղել մինչև որոշակի ժամանակահատվածը և այլն:


FETCH
Էլ. հաղորդագրության տեքստը ստանալը: Այս հրամանը գործածվում է միայն հաղորդագրությունների ցուցադրման համար: Ի տարբերություն POP3-ի, IMAP օգտագործողը չի պահպանում հաղորդագրության կրկնօրինակը օգտվողի համակարգչի մեջ:


STORE
Հաղորդագրության մասին ինֆորմացիայի փոփոխում:


COPY
Մի էլ. փոստարկղից մի ուրիշ հաղորդագրության կրկնօրինակում:


UID
Օգտագործվում է FETCH, COPY, STORE կամ SEARCH հրամանների հետ համատեղ: Այս հրամանի օգնությամբ այդ հրամաններում կարելի է օգտագործել իրական UID նունարկիչ(իդենտիֆիկացիոն) համարներ, հաղորդագրությունների միջակայքից թվերի շարքի փոխարեն:


CAPABILITY
Հարցում IMAP սերվերից նրա հնարավորությունների մասին:


NOOP
Հրամանը ոչինչ չի անում: Այն կարող է օգտագործվել սեանսը ակտիվ պահելու համար, որպեսզի այն չավարտվի սպասման ժամանակաչափի ժամանակով: Սերվերի պատասխանը NOOP հրամանին պետք է միշտ լինի դրական: Քանի որ սերվերը պատասխանի մեջ հաճախ վերադարձնում է այս կամ այն հրամանի կատարման ընթացիկ վիճակը, ապա NOOP հրամանը միանգամայն կարելի է օգտագործել որպես տրիգգեր՝ սերվերի ընթացիկ վիճակից տեղեկանալու համար:

Տես նաև

Էլեկտրոնային փոստ

Արտաքին հղումներ