IMAP artıq bir müddətdir ki, Mail.Ru Mail-də tam gücü ilə işləyir və mən onu işə salarkən qarşılaşdığımız problemlər barədə danışmağa hazıram. Onlardan bəziləri protokolun özünəməxsus xüsusiyyətləri və onun tarixi ilə, digərləri isə yaddaşımızla IMAP qarşılıqlı əlaqəsinin xüsusiyyətləri ilə əlaqədar idi. Çətinliklərin ayrıca kateqoriyası e-poçt müştərilərinin müxtəlifliyindən qaynaqlanır.
Ətraflı məlumat üçün - pişiyə xoş gəlmisiniz.
Hazırkı IMAP buraxılışı mərmiyə ikinci yanaşmamızdır. Keçən dəfə Dovecot serverini götürdük və onu özümüz üçün fərdiləşdirməyə çalışdıq. Nəticə bizi qane etmədi: yüklərimizə və infrastrukturumuza uyğun gəlmirdi. Bu dəfə fərqli bir yol tutmağa qərar verdik və öz həllimizi yazdıq.
Biz IMAP-ı may ayında işə saldıq, lakin onu yalnız iyun ayında elan etdik. Əslində, May auditoriyası əməkdaşlarımız və müştəriləri Mailimizdə IMAP-ın mövcudluğunu avtomatik aşkarlayan və ona yeni əlavə edilmiş hesabları birləşdirən istifadəçilərdir.
IMAP protokoluna xas olan çətinliklər
1. Protokolun özünün çətinliyi
IMAP protokolunun ilk versiyası 1986-cı ildə ortaya çıxdı. IN hal-hazırda Hazırkı IMAP standartı 2003-cü ildə yenilənmiş 4rev1 versiyasıdır. Belələri üçün uzun müddətli standart əhəmiyyətli dərəcədə artmışdır: o cari versiya 200-ə yaxın səhifədən ibarətdir.İndi standartda təsvir olunan bir çox məqam köhnəlmişdir - bugünkü şəraitdə onlar artıq lazım deyil. Məsələn, protokol sətirlərin sayını və məktubun hissələrinin MD5 cəmini qaytarmağı nəzərdə tutur - müasir müştərilərdə əslində istifadə edilməyən funksionallıq.
Bundan əlavə, bir çox isteğe bağlı protokol uzantıları var. Onlardan bəziləri, əslində, zəruridir rahat iş poçt qutusu ilə.
Tarixi irsi aradan qaldırmaq üçün bir neçə genişləndirmə həyata keçirməli olduq. Onlardan biri UID+-dır: hərfi köçürdükdə və ya əlavə etdikdə, kopyalama və ya əlavə etmə nəticəsində serverdə görünən yeni məktubun identifikatorunu qaytarırıq. Bu, bizə hansı e-poçtun əlavə olunduğunu tanımaq üçün müştərinin yerinə yetirməli olduğu resurs tələb edən axtarış əməliyyatına qənaət etməyə imkan verir.
2. Serverlə işləmək üçün standart nümunənin olmaması
IMAP eyni problemi həll etmək üçün bir çox yol təqdim edir və nəticədə demək olar ki, bütün müştərilər fərqli bir əməliyyat sxeminə malikdir. Əməliyyat nümunələrinin veb poçt və ya POP3-ün necə işlədiyindən tamamilə fərqli olması da vacibdir.
Yarıdan çoxu altındakı müştərilərdən gəlir Apple cihazları: Səbəb IMAP avtomatik aşkarlanmasının onlar üçün yaxşı işləməsidir. Outlook, əksinə, standart olaraq POP3 vasitəsilə işləyir və IMAP-ı əl ilə konfiqurasiya etməlisiniz.
Burada 2 əsas kateqoriyanı ayırd edə bilərik: poçt qutusu və ya qovluqdakı bütün məktublar haqqında dərhal məlumat tələb edən masaüstü müştərilər və mobil müştərilər, ilkin olaraq yalnız ən yeni mesajlar haqqında məlumat tələb edir. Sonra, dövləti yeniləmək üçün etdikləri sorğuları, məktublar haqqında məlumatları necə dəqiq çəkdiklərini öyrənməli olduq.
Niyə bu bizim üçün zəruri addım idi? Təvazökar yüklər altında (məsələn, server xidmət edirsə korporativ poçt kiçik şirkət) optimallıq məsələsi o qədər də kəskin deyil. Bununla belə, həcmlərimizlə optimallıq kritik hala gəlir: buna görə də, yaddaşa daxil olan e-poçt müştərilərinin bütün zooparkının iş sxemlərini öyrənməli olduq.
3. Sinxron seansların sayı
Standarta görə, minimum server fasiləsi 30 dəqiqədir. Bundan əlavə, bir müştəri eyni anda serverə bir neçə əlaqə saxlaya bilər (protokol göstərmir maksimum miqdar icazə verilən bağlantılar). Əslində, bizim miqyasda bu o deməkdir ki, bir server eyni vaxtda on minlərlə əlaqəni optimal şəkildə idarə etməlidir. Sinxron rejimdə işləyərkən, belə bir sıra əlaqə sadəcə olaraq bütün resursları mənimsəyəcəkdir.Bu problemi həll etmək üçün kənardan tetiklenen epoll üzərində qurulmuş asinxron iş üçün bir kitabxana yazdım. Başlanğıcda qarşıma IMAP-dan başqa digər problemləri həll etmək üçün gələcəkdə bir neçə gün ərzində öz asinxron serverimi yaza biləcəyim bir kitabxana yaratmağı tapşırdım; nəticədə demək olar ki, bütün kodlar digər xidmətlərin yazılması üçün istifadə edilə bilər.
4. Müştərini unikal şəkildə müəyyən edə bilməmək
Bizim serverimiz müştərilərin təxminən yarısını müəyyən etməyə imkan verən ID genişlənməsini dəstəkləyir. Təəssüf ki, digər yarısı bu genişləndirmə haqqında bilmir (məşhur olanlardan, məsələn, Outlook).Hansı müştəri ilə işlədiyimizi başa düşmək bizə onun xarakterik səhvlərindən yan keçməyə imkan verir, həmçinin verilmiş seans çərçivəsində iş modelinin nə olacağını proqnozlaşdırmağa və müvafiq olaraq işi optimallaşdırmağa imkan verir. Bu, bizim üçün çox vacibdir, ona görə də müştəri şəxsiyyət vəsiqəsini təqdim etmirsə, biz onu başqa yollarla (Outlook vəziyyətində, teqlərlə) müəyyən etməyə çalışırıq.
5. Mesajları köçürmək əmri yoxdur
Müştərilərdə hərəkət kopyalama + silmə yolu ilə həyata keçirilir. Biz, əlbəttə ki, məktubun surətinin yerləşdirilməsini istəyirik istədiyiniz qovluq, və orijinal silindi və zibil qutusunu qarışdırmadı. Digər tərəfdən, bəzən istifadəçinin özü məktubu kopyalayır yeni qovluq və sonra orijinalı silir: bu halda silinmiş məktub səbətə uyğun olmalıdır.Bu iki halı ayırd etmək üçün kopyaladıqdan sonra eyni sessiyada məktubu xüsusi daxili bayraqla qeyd edirik. İstifadəçinin özü məktubu kopyalayıb orijinalı sildikdə, müştəri, bir qayda olaraq, məktubların siyahısını yeniləyir. Yeniləmə zamanı onay qutusu avtomatik olaraq sıfırlanır və silinmiş mesaj zibil qutusuna atılır. Müştəri məktubu silirsə (köçmənin bir hissəsi kimi), heç bir yeniləmə baş vermir və bayraqla qeyd olunan məktub həmişəlik silinir.
Cari poçt yaddaşının və indekslərin uyğunlaşdırılması ilə bağlı çətinliklər
1. Mesajın identifikasiyası
IMAP üzərində işləmək üçün iki növ mesaj identifikatorunu dəstəkləmək lazım idi: seansdan sessiyaya fərqlənə bilən ardıcıllıq nömrəsi və mesajın bütün ömrü üçün saxlanılan unikal nömrə. Hər iki identifikator kifayət qədər ciddi meyarlara cavab verməli idi ki, bu da veb poçtu və POP3 serverinin istifadə etdiyi sxemə uyğun gəlmir.Belə çıxır ki, onu saxlamaq ən rasionaldır RAM ardıcıl nömrələrin bütün dəsti, onların daxili identifikatorlara uyğunluğu, həmçinin IMAP ID. Qovluğu açarkən yaddaşdan bütün hərflərin siyahısını, daxili identifikatorlarımızı, IMAP ID-ni, bayraqları və mesaj ölçüsünü - lazımsız sorğular olmadan göndərmək istədiyimiz hər şeyi çıxarırıq.
Bütün dəyişikliklər haqqında seriya nömrəsi bir seans ərzində müştərini xəbərdar etməliyik. Standarta görə, IMAP ID ardıcıllığı sıra nömrələrinin ardıcıllığına uyğun olmalıdır. Hərflərin siyahısını sıralamaqla seriya nömrələrini əldə edəcəyik unikal nömrələr. Müştəri məsələ qaldırdıqda yeni komanda, biz saxlama ilə əlaqəni yenidən açırıq, vaxtı tələb edirik son dəyişikliklər qutuda hazırlanmışdır. Əgər sonuncu belə sorğudan sonra heç bir dəyişiklik baş verməyibsə, biz sadəcə əmrə cavab qaytarırıq. Əks halda, biz qovluqdakı mesajların siyahısını yenidən sorğulayırıq və onu müştərinin oxşar siyahısı ilə müqayisə edirik. Sonra, ya dəyişikliklər haqqında məlumatı qaytarırıq, ya da protokol bunu dərhal etməyə imkan vermirsə, məktubun silindiyini qeyd edirik və bu barədə müştəriyə məlumat vermək üçün uyğun anı gözləyirik.
Bu spesifikliyə görə - məktub artıq poçt qutusunda deyil, lakin müştəri hələ bu barədə məlumat əldə etməyib - müştəri artıq silinmiş məktub haqqında məlumat tələb edə bilər. Üstəlik, onlardan bəziləri təcrübəlidir ciddi problemlər, əgər onların sorğusuna cavab verilməsə. Müştərinin sınmasının qarşısını almaq üçün bu cür sorğulara cavab olaraq stubları qaytarırıq. Müştəri normal iş üçün lazım olan məlumatları alır və sonra növbəti yeniləmə məktubların siyahısı (bu adətən dərhal baş verir) mesajı ondan silir.
2. Mesajın MIME strukturu haqqında məlumatın optimal şəkildə qaytarılması ehtiyacı
Demək olar ki, bütün müştərilər məktubun strukturu haqqında məlumat tələb edirlər. Çox vaxt ilk seans zamanı qovluqdakı bütün məktublar haqqında belə məlumatları bir anda tələb edirlər. Hər bir belə sorğu üçün məktubu təhlil etmək son dərəcə suboptimal olardı.Bunun əvəzinə biz MIME strukturlarının keşini yaratdıq. Keşin olması bizə IMAP-ın xüsusiyyətləri ilə bağlı bir sıra çətinliklərin öhdəsindən gəlməyə kömək etdi - xüsusən də serverlə işləmək üçün standart nümunənin olmaması: bəzi məlumatlar keşdə saxlandığından, bu, əlaqəli yükü neytrallaşdırmağa kömək edir. müştəri işinin müxtəlif nümunələri ilə.
Hazırda 50-yə qədər mesajı keşləyirik. Niyə 2-3 yox? Məsələ burasındadır ki, bəzi müştərilər əvvəlcə məktubun strukturunu, sonra isə gövdəsini və eyni anda bir neçə mesaj üçün; maksimum sayı belə bir "paketdəki" hərflər adətən 50 ədəddir.
3. Məktubun hissələrinin optimal çıxışı
Çox vaxt müştərilər məktubun yalnız mətn hissələrini xahiş edirlər, bu da mesajın sonunda ola bilər. Parçaları göstərmək üçün müştərilər eyni anda 50-200 e-poçtdan mətn hissələrini tələb edə bilərlər. Siz bütün mesaj faylını oxumaq istəmirsiniz (və 10 KB mətn göndərmək üçün 10 MB e-poçtu emal edin); hər sorğu üçün fayl daxilində bir hissənin mövqeyini müəyyən etmək üçün indeksdən istifadə etmək də baha başa gələcək. Bu vəziyyətdə mesaj strukturu önbelleği də kömək edir.Müştəri bir neçə onlarla hərf üçün fraqmentləri yüklədikdə bu yanaşmanın üstünlükləri xüsusilə aydın olur: əgər biz struktur keşindən istifadə etməsəydik, onda çoxlu meqabaytları nəzərdən keçirməli və sürəti qurban verməli olardıq.
Anbarlarımızda yerə qənaət etmək üçün base64 hissələri məktubun daxilində deşifrə olunmuş formada saxlanılır: veb-poçtla işləyərkən bu, lazımsız yenidən kodlaşdırmadan əlavələri göndərməyə imkan verir. Bu yenidən kodlaşdırmanı nəzərə alaraq hissələrin çatdırılması üçün bir sxem hazırlamaq lazım idi. IMAP serverində axın kodlaşdırmasını yazdıq. Keş burada da kömək etdi - onun sayəsində strukturu yenidən oxumadan müəyyən bir fraqmentin hansı formada (ikili və ya olmayan) saxlandığını başa düşə bilərik.
4. Bəzi müştərilərin xüsusiyyətləri
Bəzi müştərilər RFC-yə tam uyğun gəlmir: məs. standart müştərilər Android versiyaları 2.2 - 2.3 bəzi əlavə sahələri qaytarmadan hərfləri düzgün göstərə bilməz. Əsas çətinlik bu müştərilərin hər birinin hansı sahələri özləri üçün məcburi hesab etdiyini müəyyən etmək idi: bu, kobud güc yolu ilə həll edilməli idi.Artıq yuxarıda qeyd olundu ki, müştərilər məktubları silmək üçün fərqli yanaşmalara sahib ola bilərlər: bəziləri onları zibil qutusuna aparır, digərləri dərhal və həmişəlik silirlər. Ancaq bəzi müştərilər başa düşmürlər standart uzantı Hansı qovluğun zibil olduğunu müəyyən etməyə imkan verən XLIST. Bunun əvəzinə qovluqlarını zibil qutusu kimi istifadə edirlər (məsələn, Sərçə özünü belə aparır).
Outlook maraqlı şəkildə davranır: silmə əmri ilə məktublar zibil qutusuna köçürülmür, lakin üstündən xətt çəkilmiş kimi qeyd olunur və sonra silinir. Məlum oldu ki, istifadəçilər üçün bu, səhv kimi görünür - bir çoxları bundan sonra nə edəcəyini və müştərinin adi şəkildə davranmasını və hərflərin zibil qutusuna düşməsini necə təmin edəcəyini başa düşmür.
Bu cür müxtəliflik qarşısında biz həm də hər bir müştərinin necə davrandığını və bu variantlara uyğunlaşdığını empirik şəkildə başa düşmək lazım idi - və istifadəçi əmin ola bilsin: hansı müştəridə işləməsindən asılı olmayaraq, poçt onun hərəkətlərinə cavab verəcəkdir. həmişəki kimi və proqnozlaşdırıla bilən (in bu halda- silinmiş məktub zibil qutusuna düşəcək). Test proksi serveri vasitəsilə müxtəlif cavabları sınamaqla və müştərinin hər seçimə reaksiyasını izləməklə bunu həll etdik.
Özümüz üçün öyrəndiklərimiz: IMAP çoxları ilə olduqca "yayılmış" bir şeydir tarixi xüsusiyyətləri, e-poçt müştərilərinin müxtəlifliyi ilə vurulan 26 il ərzində əldə edilmişdir. Yüklərimizi nəzərə alsaq, bu, nə götürəcəyimizlə nəticələnir hazır həll və onu özünüzə uyğunlaşdırmağa çalışmaq məntiqsizdir: in ən yaxşı ssenariİşin həcmi özünüz həll hazırladığınız zaman olduğu kimi olacaq. Bu yolla getdik :)
Viktor Starodub,
Mail.ru Mail komandası
əsasında nəqliyyat protokolu TCP və 143 portunu istifadə edir.
IMAP istifadəçini təmin edir geniş imkanlar mərkəzi serverdə yerləşən poçt qutuları ilə işləmək üçün. Bu protokoldan istifadə edən e-poçt proqramı, sanki yazışmalar alıcının kompüterində yerləşirmiş kimi serverdəki yazışma yaddaşına daxil olur. E-poçtlar istifadəçinin (müştərinin) kompüterindən e-poçtların tam məzmunu ilə faylları daim serverdən irəli və geri göndərmədən manipulyasiya edilə bilər.
SMTP protokolu adətən e-poçt göndərmək üçün istifadə olunur, çünki IMAP-ın APPEND adlanan göndərmə əmri "uğursuzluq" və "təhlükəsiz" hesab olunur.
Ensiklopedik YouTube
1 / 5
✪Əsaslar IMAP və POP3-dən fərqlənir
✪ POP3 vs IMAP, hansını seçməlisiniz? | 123-reg Dəstəyi
✪ IMAP HESABATI
✪ Necə Aktivləşdirilir Gmail IMAP Parametrlər
✪ IMAP nədir və ondan necə istifadə olunur | E-poçt Təlimatı
Altyazılar
IMAP protokolunun hazırlanmasında məqsəd
IMAP əsasən ibtidai göndərmə imkanları ilə POP3-ə alternativdir.
Nəqliyyat əsasında TCP protokolu və port 143-dən istifadə edir.
IMAP istifadəçiyə mərkəzi serverdə yerləşən poçt qutuları ilə işləmək üçün geniş imkanlar təqdim edir. Poçt proqramı bu protokoldan istifadə edərək, sanki bu yazışma alıcının kompüterində yerləşirmiş kimi serverdəki yazışma anbarına daxil olur. E-poçtlar istifadəçinin (müştərinin) kompüterindən e-poçtların tam məzmunu ilə faylları daim serverdən irəli və geri göndərmədən manipulyasiya edilə bilər.
Məktub göndərmək üçün SMTP protokolundan istifadə olunur.
IMAP protokolunun hazırlanmasında məqsəd
IMAP protokolu POP3-ə alternativdir.
POP3-ün bir sıra çatışmazlıqları var və onlardan ən ciddisi serverdə mesajların hərəkətinə və saxlanmasına nəzarət etmək imkanlarının olmamasıdır. Mesajlar, bir qayda olaraq, poçt serverindən bir anda yüklənir, bundan sonra onlar serverdən silinir, yəni qəbul etmək üçün mesajları seçmək imkanı yoxdur.
POP3-ün bu xüsusiyyəti ilə bağlı problemləri həll etmək üçün Vaşinqton Universiteti istifadəçilərə mesajlar qəbul nöqtələri arasında paylanmadan bir neçə yerdən eyni poçt qutusundan e-poçt almağa imkan verən yeni protokol hazırlayıb. İstifadəçiyə poçt qutusundakı mesajları idarə etmək imkanı verilir və əlavə funksiyalar serverdə poçt qutularına xidmət göstərmək üçün.
POP3 ilə müqayisədə üstünlüklər
POP3 istifadə edərkən, müştəri serverə yalnız yeni mesajları yükləmək üçün lazım olan müddət ərzində qoşulur. IMAP istifadə edərkən əlaqə kəsilmir istifadəçi interfeysi aktivdir və mesajlar yalnız müştərinin tələbi ilə endirilir. Bu, poçt qutularında çoxlu böyük mesajlar olan istifadəçilər üçün cavab vaxtını azaltmağa imkan verir.
POP protokolu cari müştərinin poçt qutusuna qoşulmuş yeganə müştəri olmasını tələb edir. IMAP icazə verir eyni vaxtda giriş bir poçt qutusuna birdən çox müştəri göndərir və müştəriyə eyni anda qoşulmuş digər müştərilər tərəfindən edilən dəyişiklikləri izləmək imkanı verir.
IMAP4-də müəyyən edilmiş bayraq sistemi sayəsində müştəri mesajın statusunu izləyə bilər (oxu, cavab göndər, silindi və s.); bayraq məlumatları serverdə saxlanılır.
IMAP4 müştəriləri poçt qutularını yarada, adını dəyişdirə və silə və mesajları poçt qutuları arasında köçürə bilər. Siz həmçinin poçt qutusuna giriş hüquqlarını idarə etmək üçün IMAP4 Girişə Nəzarət Siyahısının (ACL) Genişlənməsindən (RFC 4314) istifadə edə bilərsiniz.
Mesajların axtarışı server tərəfində baş verir.
IMAP4 açıq genişləndirmə mexanizminə malikdir.
IMAP protokolunun versiyaları
- Orijinal IMAP (1986, spesifikasiya yoxdur)
- IMAP2 (1988 - RFC 1064, 1990 - RFC 1176)
- IMAP3 (1991, RFC 1203)
- IMAP2bis (spesifikasiya yalnız 1993-cü il layihəsində mövcuddur)
- IMAP4 (adı dəyişdirilib IMAP2bis)
Mesajlar və onların atributları
IMAP yalnız mesajlarla işləyir və xüsusi başlıqları olan heç bir paket tələb etmir.
Hər bir mesajın onunla əlaqəli bir neçə atributu var. Bu atributlar ayrı-ayrılıqda və ya digər atributlarla birlikdə müəyyən edilə bilər.
UID
Hər bir mesaja unikal identifikatorla birlikdə istifadə edildikdə poçt qutusunda mesajın unikal identifikasiyasına zəmanət verən 64 bitlik ardıcıllıq təşkil edən 32 bitlik kod təyin edilir. Mesaj nə qədər gec gəlsə, onun UID-i bir o qədər böyükdür.
UID poçt qutusu ilə əlaqələndirilir və poçt qutusunun seçilməsi mərhələsində uidvalidity cavab kodu (ok) kimi göndərilir. Əgər əvvəlki sessiyanın UID-si nədənsə istifadə oluna bilmirsə, UID artırılmalıdır.
UID mesajı sessiya ərzində dəyişməməli və sessiyadan sessiyaya dəyişməməlidir. Bununla belə, UID mesajını növbəti sessiyada saxlamaq mümkün deyilsə, hər bir sonrakı seansda əvvəllər istifadə edilmiş hər hansı UID-dən böyük olan yeni unikal identifikator kodu olmalıdır.
Mesajın ardıcıl nömrəsi
Poçt qutusundakı mesajın ardıcıl nömrəsi 1-dən başlayır. İkincidən başlayaraq hər bir mesaj özündən əvvəlkindən düz 1 böyük ardıcıllığa malikdir.
Sessiya zamanı mesajın ardıcıl nömrəsini dəyişmək mümkündür. Məsələn, poçt qutusundan mesaj silindikdə, bütün sonrakı mesajların nömrələri dəyişir.
Mesaj bayraqları
Bu atribut əlaqəli sıfır və ya daha çox adlandırılmış işarələrin siyahısıdır bu mesaj. Bayraq bu siyahıya əlavə edilməklə təyin edilir və onu silməklə təmizlənir. IMAP 4.1-də iki növ bayraq var. Bayraq daimi və ya yalnız müəyyən seans müddətində etibarlı ola bilər.
Sistem bayrağı adı protokol spesifikasiyasında müəyyən edilmiş bir bayraqdır. Bütün sistem bayraqları \ simvolu ilə başlayır.
Aşağıdakı sistem bayraqları hazırda müəyyən edilmişdir:
- \göründü - mesaj oxundu
- \cavab verdi - mesaja cavab göndərildi
- \bayraqlanmış - mesaj "vacib" olaraq qeyd edilmişdir
- \deleted - mesaj silinmiş kimi qeyd olunur
- \qaralama - qaralama kimi qeyd olunan mesaj
- \son - son mesaj (ilk dəfə cari sessiya zamanı poçt qutusunda göründü)
Serverdə daxili mesaj tarixi və vaxtı
Mesajın alınma tarixi və vaxtı. Mesaj vasitəsilə çatdırılırsa SMTP protokolu- son ünvana çatdırılma tarixi və vaxtı. Kopyalama əmri ilə çatdırılan mesajlar üçün mesaj göndərənin daxili tarixi və vaxtı. Əlavə əmrindən istifadə edərkən - tarix və vaxt, parametrləri ilə müəyyən edilir komandalar.
Digər atributlar
- mesaj ölçüsü - mesajdakı oktetlərin sayı.
- mesaj zərfinin quruluşu.
- mesaj bədən quruluşu
Müştəri-server qarşılıqlı əlaqəsi
IMAP 4.1 bağlantısı müştəri ilə server arasında əlaqə yaratmağı nəzərdə tutur. Müştəri serverə əmrlər göndərir, server isə müştəriyə sorğunun vəziyyəti haqqında məlumat və bildirişlər göndərir. İstər müştəri, istərsə də server kimi bütün mesajlar xüsusi ardıcıllıqla bitən sətirlər şəklindədir.
İstənilən prosedur müştərinin əmri ilə başlayır. İstənilən müştəri əmri teq adlanan identifikator prefiksi ilə başlayır (adətən qısa alfasayısal sətir, məsələn, A0001, A0002 və s.). Hər bir əmr üçün müştəri öz etiketini yaradır.
Müştərinin göndərdiyi sətirin tam əmri təmsil etmədiyi iki mümkün hal var. Birincidə, komanda arqumenti sətirdəki oktetlərin sayını təyin edən kodla təmin edilir. İkincidə, komanda arqumentləri serverdən cavab tələb edir. Hər iki halda server + simvolu ilə başlayan əmrin davamı sorğusu göndərir.
Müştəri digərini göndərməzdən əvvəl bir əmr göndərməyi tamamlamalıdır.
Serverin protokol qəbuledicisi müştəridən gələn komanda xəttini oxuyur, onu təhlil edir, parametrləri çıxarır və məlumatları serverə ötürür. Əmr başa çatdıqdan sonra server cavab göndərir.
Serverdən müştəriyə göndərilən məlumatlar, eləcə də əmrin tamamlanmasını göstərməyən status cavabları * ilə prefikslə yazılır və etiketsiz cavablar adlanır.
Məlumat server tərəfindən müştəri əmrinə cavab olaraq və ya öz təşəbbüsü ilə göndərilə bilər. Məlumat formatı göndərilmə səbəbindən asılı deyil.
Cavab əməliyyatın uğurlu/uğursuzluğunu göstərir. O, proseduru icra edən müştəri əmri ilə eyni etiketdən istifadə edir. Beləliklə, birdən çox əmr verilirsə, server etiketi verilən cavaba səbəb olan əmri göstərir. Serverin dayandırılması cavabının üç növü var: ok (uğur), yox (uğursuzluq), pis (protokol xətası, məsələn, əmr tanınmadı və ya sintaksis xətası aşkarlandı).
IMAP 4.1 müştəri protokolu dinləyicisi serverdən cavab sətrini oxuyur və ilk * və ya + simvoluna əsasən hərəkət edir.
Müştəri istənilən vaxt serverdən istənilən cavabı qəbul etməyə hazır olmalıdır. Server məlumatları elə yazılmalıdır ki, müştəri serverə dəqiqləşdirici sorğular göndərmədən birbaşa istifadə edə bilsin.
IMAP serveri bildirir
IMAP 4.1 serveri dörd ştatdan birindədir.
Əksər əmrlər yalnız müəyyən dövlətlərdə istifadə edilə bilər.
bacarır autentifikasiya olmadanƏksər əmrlər müştəriyə təqdim edilməzdən əvvəl müştəri istifadəçi adı və şifrə təqdim etməlidir. Bu vəziyyətə keçid əvvəlcədən autentifikasiya edilmədən əlaqə qurulduqda baş verir.
bacarır autentifikasiya müştəri müəyyən edilir və bir poçt qutusu seçməlidir, bundan sonra mesajlarla işləmək üçün əmrlər onun üçün əlçatan olacaqdır. Bu vəziyyətə keçid əvvəlcədən autentifikasiya ilə əlaqə qurulduqda, bütün lazımi identifikasiya məlumatları verildikdə və ya poçt qutusu səhv seçildikdə baş verir.
Vəziyyətdə seçim Poçt qutusu uğurla seçildikdə sistem daxil olur.
Vəziyyətdə çıxış müştəri müraciəti nəticəsində və ya serverin müstəqil qərarı ilə əlaqə kəsildikdə sistem vurulur.
- (1) Əvvəlcədən doğrulama olmadan əlaqə
- (2) Əvvəlcədən təsdiqlənmiş əlaqə
- (3) Bağlantı rədd edildi
- (4) LOGIN və ya AUTHENTICATE əmrinin uğurla tamamlanması
- (5) SEÇ və ya EXAMINE əmrinin uğurla tamamlanması
- (6) CLOSE əmri yerinə yetirildi və ya SELECT və ya EXAMINE əmri uğursuz oldu
- (7) LOGOUT əmrini yerinə yetirin, serveri bağlayın və ya əlaqəni dayandırın
IMAP protokol əmrləri
LOGIN Müştəriyə həmişə olduğu kimi istifadəçi ID və paroldan istifadə edərək IMAP serverinə daxil olmağa imkan verir. mətn forması. Bu ən çox deyil ən yaxşı üsul, lakin bəzən bu serverə qoşulmağın yeganə yoludur. AUTHENTICATE Müştəriyə IMAP serverində qeydiyyatdan keçərkən istifadə etməyə imkan verir autentifikasiya. Fərdi istifadəçi autentifikasiyası isteğe bağlıdır və bütün IMAP serverləri tərəfindən dəstəklənmir. Bundan əlavə, bu cür yoxlamanın həyata keçirilməsi serverdən asılı olaraq dəyişə bilər. Müştəri AUTHENTICATE əmrini verdikdə, server base64 kodlu çağırış sətri ilə cavab verir. Sonra, müştəri serverin identifikasiyası probleminə cavab göndərməlidir, həmçinin base64 kodludur. Əgər server müştərinin təklif etdiyi autentifikasiya metodunu dəstəkləmirsə, o, cavabında NO sözünü ehtiva edir. Müştəri daha sonra autentifikasiya üsulu ilə razılaşmaq üçün danışıqlara davam etməlidir. Doğrulama metodunu müəyyən etmək üçün bütün cəhdlər uğursuz olarsa, müştəri LOGIN əmrindən istifadə edərək serverə daxil olmağa çalışır. Parametrlər LIST ilə eynidir. alternativ üsullar cari vəziyyət- poçt qutusu. Bu əmrin ilk parametri onun tətbiq olunduğu poçt qutusunun adıdır. İkinci parametr müştərinin məlumat almaq istədiyi meyarların siyahısıdır. STATUS əmrindən SEÇ və ya EXAMINE əmrlərindən istifadə etməklə poçt qutusunu açmadan onun statusu haqqında məlumat əldə etmək olar.
- İstifadəçi məlumatı aşağıdakı meyarlar əsasında əldə edə bilər:
- MESAJLAR - poçt qutusundakı mesajların ümumi sayı
- SON - \son bayrağı olan mesajların sayı
- UIDNEXT - yeni mesaja təyin ediləcək UID
- UNSEEN - \görülmüş bayrağı olmayan mesajların sayı
- APPEND Göstərilən poçt qutusunun sonuna mesaj əlavə edir. Arqumentlərə poçt qutusu adı, mesaj bayraqları (isteğe bağlı), vaxt damğası (isteğe bağlı) və mesajın özü - başlıq və əsas daxildir.
- Aşağıdakı mesaj bayraqları mövcuddur:
- \Gördü - oxu
- \Cavab verildi - cavab yazılıb
- \Bayraqlı - təcili
QABİLLİLİK İmkanları haqqında məlumat üçün IMAP serverini sorğulayır.
- NOOP Komanda heç nə etmir. O, seans zamanı fəaliyyəti saxlamaq üçün istifadə oluna bilər ki, seans vaxt aşımı taymerinə görə dayandırılmasın. Serverin NOOP əmrinə cavabı həmişə müsbət olmalıdır. Server tez-tez cavabında müəyyən bir əmrin icra vəziyyətini qaytardığından, NOOP server statusunu vaxtaşırı sorğulamaq üçün tetikleyici kimi istifadə edilə bilər. Bağlantılar RFC 3501 İnternet Mesajı
- Giriş Protokolu
- v4rev1 (İngilis dili)
| IMAP Bağlantısı | |
|---|---|
| Necə: KMail-in Gmail ilə konfiqurasiyası - IMAP və Bağlantısız IMAP | URI sxemləri Rəsmi aaa : aaas : acap : qapaq: cid : crid: data : dav : dict : dns : faks : fayl: ftp : : gopher : h323 : http : https : : |
| imap | |
: ldap : mailto : orta : xəbərlər : nfs : nntp : pop : pres: rtsp : sip : sips: snmp : tel : telnet : urn : wais : xmpp : Qeyri-rəsmi Bu gün sizə ən çox istifadə olunan İnternet protokolları - POP3, IMAP və SMTP haqqında ətraflı məlumat verəcəyik. Bu protokolların hər birinin xüsusi məqsədi və
funksionallıq
. Gəlin bunu anlamağa çalışaq. POP3 protokolu və onun portları Poçt İdarəsi Protokolu 3 (POP3). standart protokolüçün yaradılmış poçt e-poçtların qəbulu ilə uzaq server e-mail client.POP3 sizə e-poçt mesajını kompüterinizdə saxlamağa və hətta oflayn olduğunuz halda onu oxumağa imkan verir. Qeyd etmək vacibdir ki, qoşulmaq üçün POP3-dən istifadə etmək qərarına gəlsəniz hesab poçt, artıq kompüterinizə endirilmiş məktublar poçt serverindən silinəcək. Nümunə olaraq, birinə qoşulmaq üçün bir neçə kompüterdən istifadə edirsinizsə poçt hesabı, onda POP3 protokolu olmaya bilər ən yaxşı seçim bu vəziyyətdə. Digər tərəfdən, poçt yerli olaraq PC-də saxlandığından xüsusi istifadəçi, bu, optimallaşdırmağa imkan verir
disk sahəsi
- poçt serveri tərəfində.
- Varsayılan olaraq, POP3 protokolu aşağıdakı portlardan istifadə edir:
Port 110 standart POP3 portudur. Təhlükəsiz deyil.
Port 995 – Təhlükəsiz əlaqə yaratmaq istəyirsinizsə, bu portdan istifadə edilməlidir. IMAP protokolu və portları Internet Message Access Protocol (IMAP) dir poçt protokolu Bu protokolların hər ikisi bütün müasirlər tərəfindən dəstəklənir poçt müştəriləri(MUA - Poçt İstifadəçi Agenti) və WEB serverləri.
POP3 yalnız bir proqramdan poçta daxil olmaq imkanı versə də, IMAP birdən çox müştəridən daxil olmağa imkan verir. Bu səbəbdən, IMAP, birdən çox istifadəçinin eyni e-poçt hesabına daxil olması lazım olduğu hallarda ən uyğunlaşdırıla biləndir.
Varsayılan olaraq, IMAP protokolu aşağıdakı portlardan istifadə edir:
- Port 143– standart port. Təhlükəsiz deyil.
- Port 993- təhlükəsiz əlaqə üçün port.
SMTP protokolu və onun portları
Simple Mail Transfer Protocol (SMTP) üçün standart protokoldur göndərilməsi poçt mesajları internet vasitəsilə.
Bu protokol ilk dəfə 1982-ci ilin avqustunda nəşr olunan RFC 821 və RFC 822-də təsvir edilmişdir. RFC məlumatı çərçivəsində ünvan formatı formatda olmalıdır username@domainname. Poçt çatdırılması adi işə bənzəyir poçt xidməti: məsələn, ünvana məktub Mesaj bir sətir uzunluğunda olmadığı üçün hərflərdən istifadə olunur., aşağıdakı kimi şərh olunacaq: ivan_ivanov ünvan, merionet.ru isə poçt kodu. Əgər domen adı alıcının domen adı göndərənin domen adından fərqlidirsə, MSA (Mail Submission Agent) məktubu Mail Transfer Agent (MTA) vasitəsilə göndərəcək. MTA-nın əsas ideyası məktubları başqa birinə yönləndirməkdir domen zonası, ənənəvi poçtun başqa şəhərə və ya bölgəyə məktub göndərməsinə bənzər. MTA digər MTA-lardan da məktub alır.
SMTP protokolu aşağıdakı portlardan istifadə edir.
POP3
POP3 e-poçt mesajlarını qəbul etmək üçün bir protokoldur.
POP3 protokolundan istifadə edərək məktuba baxarkən, hər şey e-poçtlar istifadəçinin kompüterinə yüklənir və avtomatik olaraq serverdən silinir (baxmayaraq ki, bu, aradan qaldırıla bilər). Hamısı əlavə tədbirlər hərflərlə istifadəçinin kompüterində işlənəcək.
Bir kompüterdən yalnız bir nəfər poçt qutusundan istifadə edərsə, POP3 protokoluna üstünlük verilir və İnternet bağlantısı olmasa belə poçta giriş zəruridir.
IMAP
IMAP qəbul və idarəetmə imkanlarını dəstəkləyən bir protokoldur e-poçt vasitəsilə birbaşa poçt serverində.
Protokoldan istifadə edərkən IMAP elektron e-poçtlar həmişə serverdə yerləşir və hər dəfə baxıldıqda oradan endirilir. Bu, giriş zamanı çox rahatdır poçt qutusu bir neçə nəfər olmalıdır - onlardan birinin yerinə yetirdiyi hərflərlə bütün əməliyyatları (hərfin statusunu “oxumaq”a dəyişdirmək, hərfləri qovluqlar arasında köçürmək və s.) hamı görəcək. Dezavantaj - poçtla işləmək, hətta köhnə hərflərlə də lazımdır aktiv əlaqəİnternetə.
SMTP
SMTP serveridir poçt serveri, yalnız e-poçt göndərməyi dəstəkləyir.
SMTP serverindən istifadə edərkən port 25-dən istifadə olunur. Bəzi ISP-lər 25-ci portu bloklayır. Bu halda, ya portu blokdan çıxarmaq üçün şəbəkə administratorunuzla əlaqə saxlamalı, ya da alternativ 587 portundan istifadə etməlisiniz.
