नमस्कार! मैं इल्या हूँ। दो साल पहले, मैं IMAP मोबाइल क्लाइंट में शामिल हुआ। अनुप्रयोग के पहले संस्करणों ने लंबे समय तक पत्रों की सूची डाउनलोड की और मेलबॉक्स को अपडेट करने के लिए बहुत अधिक ट्रैफ़िक खर्च किया। सवाल प्रोटोकॉल के साथ काम के अनुकूलन के बारे में और सामान्य रूप से इस प्रोटोकॉल की क्षमताओं के बारे में उठता है। मैं प्रोटोकॉल के बारे में कुछ नहीं जानता था और प्रलेखन पढ़ने में डूब गया। यह पता चला है कि इस बार क्लाइंट ने बिना ब्रेक के प्रोटोकॉल का उपयोग किया और कार्यान्वयन सुविधाओं को ध्यान में नहीं रखा। इन सुविधाओं ने 2 से 3 बार मेल डाउनलोड को गति देने में मदद की। IMAP क्या है और इसे अपने लेख में बाद में अनुकूलित करने के लिए क्या चिप्स हैं।

मैं बहुत गहराई से प्रोटोकॉल में गोता नहीं लगाऊंगा। श्रेणी के बजाय एक लेख "मैं दो साल पहले इस लेख को पढ़ना चाहूंगा।" IMAP गुरुओं को अपने लिए नई जानकारी मिलने की संभावना नहीं है। यह आलेख RFC 3501 से प्रोटोकॉल विवरण पर निर्भर करता है ।

सर्वर कनेक्शन

IMAP एक स्टेटफुल प्रोटोकॉल है। यह मेरे लिए एक खोज थी, इससे पहले मैंने ऐसे प्रोटोकॉल के साथ नहीं देखा था या काम नहीं किया था। सर्वर के साथ काम करने की योजना पर विचार करें।

आइए उदाहरणों के साथ क्रम में जाएं, और सबसे महत्वपूर्ण बात। पहले आपको सर्वर से कनेक्शन बनाने की आवश्यकता है। ऐसा करने के लिए, ओपनएसएसएल लाइब्रेरी का उपयोग करें।

openssl s_client -connect imap.server.com:993 -crlf

महान, कनेक्शन स्थापित किया गया है और आप क्षमता प्रतिक्रिया के साथ शुरू होने वाली रेखा के साथ ठीक प्रतिक्रिया का निरीक्षण कर सकते हैं

OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE  SPECIAL-USE AUTH=PLAIN AUTH=LOGIN]

क्षमता के प्रत्येक के लिए एक सुविधाजनक धोखा पत्र है , जहां सभी संभावित क्षमता मान आरएफसी के लिंक के साथ लिखे गए हैं। उदाहरण के लिए, IMAP4rev1 क्लाइंट को बताता है कि सर्वर IMAP4 मानक के अनुसार काम कर रहा है, और IDLE सिग्नल जो आप मेलबॉक्स में होने वाले परिवर्तनों के लिए सदस्यता ले सकते हैं।

सर्वर प्राधिकरण

सर्वर से कनेक्ट होने के बाद, आपको अपने मेलबॉक्स पर जाने की आवश्यकता है। यह LOGIN कमांड का उपयोग करके किया जाता है।

a1 LOGIN email pass

तो, बंद करो, लॉगिन, मैं समझता हूं, और a1 यह क्या है? - शायद आप पूछें। और यह टीम टैग है। क्लाइंट के हितों में, टैग अलग-अलग होने चाहिए, क्योंकि प्रतिक्रिया अनुरोध के समान टैग के साथ आती है, जिसका अर्थ है कि यह टीमों के बीच पार्स करने के लिए मिलान किया जा सकता है। सर्वर शुरुआत में एक तारांकन चिह्न के साथ प्रतिक्रिया भी दे सकता है, जैसे कि * ठीक है, इसे एक अनुत्तरित प्रतिक्रिया कहा जाता है। मूल रूप से, ऐसा जवाब उन टीमों के लिए दिया जाता है जो प्रतिक्रिया में कई संस्थाओं से अपेक्षा करते हैं, उदाहरण के लिए, लिस्ट।

फ़ोल्डर सूची अनुरोध

किसी फ़ोल्डर में अक्षरों की सूची का अनुरोध करने के लिए, आपको पहले इन फ़ोल्डरों का पता लगाना होगा। यह लिस्ट कमांड द्वारा किया जाता है। यह कमांड सर्वर पर फ़ोल्डर्स की एक सूची देता है।

A2 LIST «» *
* LIST (\HasNoChildren \Trash) «/» Trash
* LIST (\HasNoChildren \Sent) «/» Sent
* LIST (\HasNoChildren \Drafts) «/» Drafts
* LIST (\HasNoChildren \Junk) «/» Junk
* LIST (\HasNoChildren) «/» INBOX
A2 OK List completed (0.001 + 0.000 + 0.001 secs).

कमांड में पहला पैरामीटर नेमस्पेस है। यदि सर्वर नेमस्पेस का समर्थन करता है, तो इसका मान NAMESPACE क्वेरी का उपयोग करके अनुरोध किया जा सकता है। मानक नाम स्थान एक रिक्त स्ट्रिंग की तरह दिखता है। इसके बाद, वाइल्डकार्ड पैरामीटर खेलने में आता है। इसके साथ, हम सर्वर को बता सकते हैं कि हमें किन फ़ोल्डरों को वापस करना है। उदाहरण के लिए, हम प्राप्त कर सकते हैं: एक फ़ोल्डर ट्री शाखा, केवल जड़ें, या बस सब कुछ, जैसा कि ऊपर दिए गए उदाहरण में है। ऐसा न करना बेहतर है, क्योंकि कौन जानता है कि उपयोगकर्ता के पास बॉक्स में कितने फ़ोल्डर हैं। प्रोटोकॉल के लेखक "%" का उपयोग करने की सलाह देते हैं - इस मामले में आपको मेलबॉक्स से सभी शीर्ष-स्तरीय फ़ोल्डर मिलेंगे।

उत्तर से, हम समझते हैं कि यह एक अनुत्तरित उत्तर है जहाँ प्रत्येक पंक्ति बॉक्स में आपका फ़ोल्डर है। सबसे पहले, ऐसे झंडे हैं जिनके द्वारा हम फ़ोल्डर की मेटा-जानकारी पढ़ते हैं, उदाहरण के लिए, उदाहरण में सभी फ़ोल्डरों में कोई वंशज और कुछ विशेष-उद्देश्य वाले फ़ोल्डर (जैसे ट्रैश, जंक, आदि) नहीं हैं। इसके बाद फोल्डर सेपरेटर कैरेक्टर आता है। इस प्रतीक का उपयोग सबफ़ोल्डर्स के लिए किया जाता है। उदाहरण के लिए, ट्रैश फ़ोल्डर के वंशज के लिए, नाम "कचरा / नया फ़ोल्डर" जैसा दिखेगा। सभी फ़ोल्डरों के बाद, सर्वर हमें उस टैग के साथ ठीक करेगा जो हमने कमांड और इस कमांड के निष्पादन समय को सौंपा था।

फ़ोल्डर चयन

आगे योजना के अनुसार, हमें एक फ़ोल्डर का चयन करना होगा, जहाँ से हम अपने संदेशों को कसेंगे। यह SELECT कमांड का उपयोग करके किया जाता है।

4 SELECT INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent \*)] Flags permitted.
* 16337 EXISTS
* 2 RECENT
* OK [UNSEEN 6037] First unseen.
* OK [UIDVALIDITY 1532079879] UIDs valid
* OK [UIDNEXT 17412] Predicted next UID
* OK [HIGHESTMODSEQ 21503] Highest
4 OK [READ-WRITE] Select completed (0.015 + 0.000 + 0.014 secs).

जब आप एक फ़ोल्डर चुनते हैं, तो इसके बारे में सभी जानकारी वापस आ जाती है। क्रम में चलते हैं।

पत्र के लिए फ़ोल्डर के अंदर अनुमत झंडे के साथ उत्तर दें।
झंडे के साथ उत्तर दें कि ग्राहक हमेशा के लिए बदल सकता है
फ़ोल्डर में अक्षरों की संख्या के साथ उत्तर दें
इसका उत्तर हाल के पत्रों की संख्या के साथ है, अर्थात, जिन्हें हमने फ़ोल्डर चयन के बीच प्राप्त किया था
अपठित संदेशों की संख्या के साथ उत्तर दें

खैर, अभी के लिए, इस पर ध्यान दें। बाकी जानकारी की हमें जरूरत नहीं है।

अनुरोध पत्र

अब सबसे दिलचस्प बात पत्रों के लिए अनुरोध है। आपको यहां विशेष रूप से मोबाइल क्लाइंट्स से सावधान रहना होगा। सहमत, यह संभावना नहीं है कि जब आप आवेदन दर्ज करते हैं तो आपको सर्वर से आपके डेटाबेस में हजारों संदेश प्राप्त होंगे। इसके अलावा, पूरे पत्र को डाउनलोड करने का कोई मतलब नहीं है, क्योंकि यह प्रदर्शित करने के लिए व्यावहारिक नहीं हो सकता है, उदाहरण के लिए, सभी पत्रों की एक सूची। उदाहरण के लिए, उपयोगकर्ता पत्रों को जल्दी से दिखाने के लिए, हम केवल "लिफाफा" मांगेंगे। इस लिफाफे में हम देखना चाहते हैं: प्रेषक, प्राप्तकर्ता, पत्र का विषय और भेजने की तारीख। हम पहले 10 पोस्ट लोड करेंगे।

5 FETCH 16337:16327 (ENVELOPE)

बृहदान्त्र उन अक्षरों की संख्या को खंडित करता है जो हम प्राप्त करना चाहते हैं, और कोष्ठक में हम इन पत्रों से क्या पढ़ना चाहते हैं, इस मामले में, पत्र का लिफाफा।

मैं संक्षिप्त रूप में उत्तर दूंगा:

* 16334 FETCH (ENVELOPE ("Sat, 07 Sep 2019 23:07:48 +0000" "Hello from Fabric.io" (("Fabric" NIL "notifier" "fabric.io")) (("Fabric" NIL "notifier" "fabric.io")) (("Fabric" NIL "notifier" "fabric.io")) ((NIL NIL "me" "me@mail")) NIL NIL NIL "<5d7438441b07c_2d872ad30967b9646405c6@answers-notifier2012.mail>"))

यह स्पष्ट है कि कुछ भी स्पष्ट नहीं है। और बात यह है कि लिफाफा प्रारूप RFC 2822 द्वारा तय किया गया है। मैं इस लेख में इस पर विचार नहीं करूंगा। इस लिफाफे में सभी आवश्यक जानकारी है: पत्र की प्राप्ति की तारीख, पत्र का विषय, प्रेषक, प्राप्तकर्ता, और यहां तक कि संदेश। उनके ग्राहक वार्तालाप प्रदर्शित करने के लिए उपयोग करते हैं।

इसलिए, हम उपयोगकर्ता को पत्र के बारे में बुनियादी जानकारी दिखाने में सक्षम थे, लेकिन शरीर के बारे में क्या?
हम पत्र के पूरे शरीर को तुरंत डाउनलोड कर सकते हैं, इसके आकार की परवाह किए बिना, यह निश्चित रूप से लंबे समय तक नहीं है, लेकिन फिर भी नेटवर्क और मेमोरी पर महंगा है। वैसे, यह उसी FETCH कमांड के साथ किया जाता है।

6 FETCH 16337:16327 (BODY[])

अपने इनबॉक्स पर इस तरह के एक कमांड का प्रयास करें, और आप समझेंगे कि "महंगा" से मेरा क्या मतलब है, यहां तक कि 10 संदेशों के साथ हमें पत्र के बारे में पूरी जानकारी के साथ एक बहुत ही शानदार प्रतिक्रिया मिलती है। उसका बोलना।

आपने किसी भी क्लाइंट में पत्र के स्रोत को कितनी बार डाउनलोड किया, यह जानने के लिए कि यह अपने मूल रूप में कैसा दिखता है? यदि नहीं, तो आइए इससे एक परीक्षण पत्र प्राप्त करें। इसमें, मैंने सीधे अक्षर के साथ एक तस्वीर और एक चित्र को अनुलग्नक के रूप में जोड़ा। इसे eml फॉर्मेट में सेव करें, और फिर इसे किसी टेक्स्ट एडिटर के साथ खोलें। क्लाइंट के आधार पर, आपको पत्र के विभिन्न स्रोत प्राप्त होंगे, लेकिन सामान्य तौर पर वे समान होंगे।

ईमेल हेडर से शुरू करते हैं:

Return-Path: <myemail>
Delivered-To:myemail
Received: from localhost (localhost [127.0.0.1])
	byimap.server.com (imap.server.com) with ESMTP id 6C2BE2A0363
	for <myemail>; Sun,  8 Sep 2019 23:41:29 +0300 (MSK)
X-Virus-Scanned: amavisd-new at imap.server.com
Received: from imap.server.com ([127.0.0.1])
	by localhost ( imap.server.com [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id abx8HQQT_k5A for <myemail>;
	Sun,  8 Sep 2019 23:41:29 +0300 (MSK)
Mime-Version: 1.0
Date: Sun, 08 Sep 2019 20:41:28 +0000
Content-Type: multipart/mixed;
 boundary=»--=_Part_722_554093397.1567975288»
Message-ID: <9e4e3872e603eac2c20f26bb1d65548d>
From: "Me" <myemail>
Subject: Hey, Habr!
To: myemail
X-Priority: 3 (Normal)

पत्र के शीर्षलेख में सभी मेटा-जानकारी का वर्णन किया गया है, किससे, किससे, कब, किस प्रकार की संदेश सामग्री, विषय और पत्र की प्राथमिकता। सीमा क्षेत्र पत्र की सीमा को इंगित करता है।

आगे समझें कि इसका क्या मतलब है।

----=_Part_722_554093397.1567975288
Content-Type: multipart/related;
 boundary=»--=_Part_583_946112260.1567975288»
----=_Part_583_946112260.1567975288
Content-Type: multipart/alternative;
 boundary=»--=_Part_881_599167713.1567975288»
----=_Part_881_599167713.1567975288
Content-Type: text/plain; charset=«utf-8»
Content-Transfer-Encoding: quoted-printable
----=_Part_881_599167713.1567975288
Content-Type: text/html; charset=«utf-8»
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html; charset=3Dutf-8" /></head><body><div data-crea=3D"font-wrapper"=
 style=3D«font-family: XO Tahion; font-size: 16px; direction: ltr»> <img =
src=3D"cid:jua-uid-q1nz1guinitrcfd3-1567975257318"><br><br><div></div> <b=
r> </div></body></html>
----=_Part_881_599167713.1567975288--
----=_Part_583_946112260.1567975288
Content-Type: image/jpeg; name=«2018-09-04 22.46.36.jpg»
Content-Disposition: inline; filename=«2018-09-04 22.46.36.jpg»
Content-ID: <jua-uid-q1nz1guinitrcfd3-1567975257318>
Content-Transfer-Encoding: base64

प्रत्येक सीमा लेखन के एक टुकड़े की सामान्य सीमा है। वे दो हाइफ़न "-" से शुरू करते हैं। समापन सीमा के अंत में ये दो हाइफ़न हैं। इसे RFC1341 में अधिक विस्तार से वर्णित किया गया है ।

इसे पत्र का मुख्य भाग कहा जा सकता है, पत्र के भाग और उनके MIME प्रकार यहाँ वर्णित हैं।

MIME प्रकारों के बारे में

MIME- , MIME (Multipurpose Internet Mail Extensions) email .

multipart/mixed , .

multipart/related , , ,

multipart/alternative , , , text/plain text/html, .

हमारे पास यहां सरल पाठ नहीं है, इसलिए html प्रतिनिधित्व लेना अधिक तर्कसंगत है। इस HTML-प्रस्तुति में सामग्री-विवाद: इनलाइन पैरामीटर के साथ सिर्फ एक तस्वीर है, अर्थात्, यह सीधे पत्र के शरीर में स्थित है, और संलग्न दस्तावेजों में नहीं।

इस चित्र का लिंक काफी सरल नहीं है। यह सामग्री-आईडी पैरामीटर द्वारा वर्णित है, जो कि jua-uid-q1nz1guinitrcfd3-1567975257318 के बराबर है । यह पत्र के अगले भाग की एक कड़ी है - एक तस्वीर जो बेस -64 में एन्कोड की गई है। मेरी नसों को बचाने के लिए, मैंने सभी आधार -64 कोड को शामिल नहीं किया।

पत्र के अंतिम भाग में फॉर्म है

----=_Part_722_554093397.1567975288
Content-Type: image/png; name=«2018-07-02 11.08.23 pm.png»
Content-Disposition: attachment; filename=«2018-07-02 11.08.23 pm.png»
Content-Transfer-Encoding: base64

जिसके पास पहले से कंटेंट-डिस्पोजल इनलाइन नहीं है, ऊपर की इमेज की तरह, लेकिन अटैचमेंट। इस छवि को केवल फ़ाइल अटैचमेंट पैनल में जाना चाहिए, जिस तरह से यह बेस -64 में भी इनकोडेड है और इसका आकार बड़ा है। यहां यह स्पष्ट हो जाता है कि आपको एक बार फिर पत्र के पूरे शरीर को लोड नहीं करना चाहिए यदि हम केवल बुनियादी जानकारी दिखाना चाहते हैं।

वापस प्रोटोकॉल के लिए

अक्षरों पर काम करने के बाद, आपको चयनित फ़ोल्डर को बंद करने और सर्वर को अलविदा कहने की आवश्यकता है। फ़ोल्डर को बंद करने के लिए, हमें CLOSE कमांड दर्ज करने की आवश्यकता है। हां, यह बहुत आसान है


7 CLOSE
7 OK Close completed (0.001 + 0.000 secs).

वैसे, अगर आपने मेरे साथ समानांतर में कंसोल के साथ काम किया और लेख पढ़ा, तो एक नहीं-सुखद घटना हो सकती थी, सर्वर टाइमआउट द्वारा आपका कनेक्शन बंद कर सकता था। यह पूरी तरह से सामान्य है, और प्रत्येक सर्वर का अपना समयबाह्य है, उदाहरण के लिए, हमारे पास 30 मिनट हैं।
इसलिए, पृष्ठभूमि में एनओओपी कमांड करने की सिफारिश की गई है

1 NOOP
1 OK NOOP completed (0.001 + 0.000 secs).

यह शाब्दिक रूप से कुछ भी नहीं करता है, लेकिन आपको बिना टाइमआउट के जितना संभव हो उतना कनेक्शन रखने की अनुमति देता है। यदि आप वर्तमान में एक फ़ोल्डर का चयन करते हैं, तो NOOP इस फ़ोल्डर में परिवर्तन के लिए आवधिक अनुरोध के रूप में काम कर सकता है

1 NOOP
* 16472 EXPUNGE
* 16471 EXPUNGE
* 16472 EXISTS
* 1 RECENT
1 OK NOOP completed (0.004 + 0.000 + 0.003 secs).

यहां प्रतिक्रिया में हमें दो हटाए गए संदेशों के बारे में सूचित किया जाता है, एक नया और इस फ़ोल्डर में संदेशों की संख्या 16 472 है।

मैं यह भी ध्यान देता हूं कि आप केवल एक चयनित फ़ोल्डर के साथ काम कर सकते हैं, यहां कोई समानांतर काम नहीं है।

खैर, अंत में, सर्वर के साथ सत्र बंद करें और हम इसे अलविदा कहेंगे।

8 LOGOUT
* BYE Logging out
8 OK Logout completed (0.001 + 0.000 secs).

हम उदास असंबद्ध BYE जवाब देखते हैं, जिसका अर्थ है कि यह काम खत्म करने का समय है।

CONDSOTORE और QRESYNC के साथ त्वरित सिंक

आप किसी चयनित फ़ोल्डर में बॉक्स में परिवर्तनों को ट्रैक करने के लिए NOOP ऑपरेशन का उपयोग कर सकते हैं। लेकिन क्या होगा अगर हम यह पता लगाना चाहते हैं कि जब हम दूसरे के साथ काम कर रहे थे तो फ़ोल्डर में क्या बदलाव आया है? सबसे स्पष्ट विकल्प स्थानीय भंडारण में सभी अक्षरों के माध्यम से सॉर्ट करना है, चाहे वह कैश या डेटाबेस हो, और सर्वर क्या लौटेगा, इसकी तुलना करें। एक ओर, यह वास्तव में एक समाधान है, और कुछ सर्वरों पर यह शाब्दिक रूप से एकमात्र सच होगा। दूसरी ओर, हम अक्षरों को उतनी ही तेजी से दिखाना चाहते हैं जितना कि प्रोटोकॉल आमतौर पर अनुमति देता है। सौभाग्य से, हमारा सर्वर CONDSTORE और QRESYNC जैसे प्रोटोकॉल एक्सटेंशन का समर्थन करता है, जिन्हें RFC7162 में जोड़ा गया था। पहले एक संदेश और फ़ोल्डर में एक विशेष 63-बिट संख्या को जोड़ता है, जिसे मॉड-सीक्वेंस कहा जाता है, जो इस पत्र पर प्रत्येक ऑपरेशन के साथ बढ़ता है। सभी संदेशों के बीच उच्चतम मॉड-अनुक्रम फ़ोल्डर में जोड़ा जाता है। परिणामस्वरूप, हर बार जब आप एक सर्वर से कनेक्ट होते हैं जो CONDSTORE का समर्थन करता है, तो हम आसानी से पता लगा सकते हैं कि कुछ बदल गया है या नहीं, बस स्थानीय और सर्वर फ़ोल्डर के लिए मॉड-अनुक्रम मानों की तुलना करके।

इसके अतिरिक्त, यह एक्सटेंशन STORE और FETCH कमांड के लिए अतिरिक्त पैरामीटर जोड़ता है - CHANGEDSINCE मॉड-सीक्वेंस और UNCHANGEDSINCE मॉड-सीक्वेंस, जो आपको एक ऑपरेशन करने की अनुमति देता है यदि क्रमशः ट्रांसमिट किए गए संदेशों का मॉड-अनुक्रम इससे बड़ा और छोटा है। आइए एक उदाहरण देखें।

FETCH 17221:17241 (UID) (CHANGEDSINCE 0)
* OK [HIGHESTMODSEQ 22746] Highest
* 17222 FETCH (UID 18319 MODSEQ (22580))
* 17223 FETCH (UID 18320 MODSEQ (22601))
* 17224 FETCH (UID 18324 MODSEQ (22607))
* 17225 FETCH (UID 18325 MODSEQ (22604))
* 17226 FETCH (UID 18326 MODSEQ (22608))
* 17227 FETCH (UID 18327 MODSEQ (22614))
* 17228 FETCH (UID 18328 MODSEQ (22613))
* 17229 FETCH (UID 18336 MODSEQ (22628))
* 17230 FETCH (UID 18338 MODSEQ (22628))
* 17231 FETCH (UID 18340 MODSEQ (22628)
* 17232 FETCH (UID 18341 MODSEQ (22628))
* 17221 FETCH (UID 18318 MODSEQ (22583))

मैंने एक ऐसी स्थिति का अनुकरण किया जिसमें हम मेलबॉक्स में जाते हैं और इसके बारे में पहले से कुछ भी नहीं जानते थे, अर्थात् हमारा स्थानीय मॉड-अनुक्रम 0. है। जैसा कि आप देख सकते हैं, सर्वर आम तौर पर मेलबॉक्स में आने वाले सभी संदेशों को लौटाता है, क्योंकि इससे पहले हमें कुछ भी नहीं मिला था। और बॉक्स के बारे में कुछ भी पता नहीं है। CHANGEDSINCE से UID पत्रों के अनुरोध के जवाब में, एक अनटैग्ड प्रतिक्रिया OK भी एक HIGHESTMODESEQ के साथ आती है, जिसे अब हम सहेजेंगे, और प्रत्येक संदेश हमारे MODSEQ के लिए।

हम मेलबॉक्स के साथ कुछ संचालन करेंगे: नए अक्षर जोड़ें, झंडे बदलें। आइए एक नया अनुरोध करें लेकिन पिछले मॉड-सीक्वेंस के साथ

1 fetch 17221:* (UID FLAGS) (CHANGEDSINCE 22746)
* 17267 FETCH (UID 18378 FLAGS () MODSEQ (22753))
* 17270 FETCH (UID 18381 FLAGS (\Seen) MODSEQ (22754))
* 17271 FETCH (UID 18382 FLAGS () MODSEQ (22751))
* 17273 FETCH (UID 18384 FLAGS () MODSEQ (22750))

और हम पहले से ही 20 पुराने और नए समुदायों के आउटपुट के बजाय अंतर को देखते हैं (17221 में तारांकन: * का मतलब है कि संख्या को 17221 से अधिकतम संभव अक्षर लेने के लिए) हमें ऐसे पत्र मिलते हैं जिनका MODSEQ पिछले एक से अधिक है। यह एक फ़ोल्डर को सिंक्रनाइज़ करने में काफी अच्छी तरह से मदद करता है जिसमें हम कुछ समय के लिए नहीं होते हैं और सभी संभावित लोगों की कोशिश करने के बजाय, बदले हुए अक्षरों का एक प्रकार प्राप्त करते हैं।

ऐसा लगता है, बहुत बेहतर होगा? लेकिन QRESYNC सिंक्रनाइज़ेशन ऑपरेशन को और भी तेज करता है, यह आपको MODSEQ मापदंडों और फ़ोल्डर के चयन के दौरान हमारे लिए ज्ञात UIDs को निर्दिष्ट करने की अनुमति देता है। चलिए एक उदाहरण से समझाते हैं। सबसे पहले, QRESYNC सक्षम कमांड के साथ सक्षम होना चाहिए।

1 ENABLE QRESYNC
* ENABLED QRESYNC
1 OK Enabled (0.001 + 0.000 secs).
1 SELECT INBOX (QRESYNC (0 0))
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent \*)] Flags permitted.
* 17271 EXISTS
* 0 RECENT
* OK [UNSEEN 17241] First unseen.
* OK [UIDVALIDITY 1532079879] UIDs valid
* OK [UIDNEXT 18385] Predicted next UID
* OK [HIGHESTMODSEQ 22754] Highest
1 OK [READ-WRITE] Select completed (0.001 + 0.000 secs).

चूँकि इससे पहले हमें फ़ोल्डर के बारे में कुछ भी पता नहीं था, इसलिए सर्वर हमें फ़ोल्डर के बारे में केवल जानकारी देता है, उसके परिवर्तनों की एक डली के बिना। मान लीजिए कि हमने पहले बीस संदेश दिए और उनके UID को याद किया और HIGHESTMODESEQ को भी याद किया। हम फ़ोल्डर को छोड़ देते हैं, अपने आप को एक संदेश भेजते हैं, संदेश को हटाते हैं, झंडे बदलते हैं और फ़ोल्डर के बारे में पिछली जानकारी के साथ लौटते हैं

1 CLOSE
1 OK Close completed (0.001 + 0.000 secs).
1 SELECT INBOX (QRESYNC (1532079879 22754 18300:18385))
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent \*)] Flags permitted.
* 17271 EXISTS
* 0 RECENT
* OK [UNSEEN 17241] First unseen.
* OK [UIDVALIDITY 1532079879] UIDs valid
* OK [UIDNEXT 18386] Predicted next UID
* OK [HIGHESTMODSEQ 22757] Highest
* VANISHED (EARLIER) 18380
* 17269 FETCH (UID 18383 FLAGS () MODSEQ (22757))
* 17271 FETCH (UID 18385 FLAGS () MODSEQ (22755))
1 OK [READ-WRITE] Select completed (0.001 + 0.000 secs).

और अब, एक बदले हुए फ़ोल्डर का चयन करते समय, हमें तुरंत संदेशों के लिए VANISHED (EARLIER) प्रतिक्रिया के रूप में, और हटाए गए या बदले गए संदेशों के लिए FETCH के रूप में, परिवर्तनों की एक डली मिल जाती है। यदि उपयोगकर्ता ने लंबे समय तक इसका दौरा नहीं किया है तो अब फ़ोल्डर को सिंक्रनाइज़ करना और भी आसान है। यह एक बहुत अच्छा तरीका है यदि आपके पास कैश में स्थानीय रूप से संग्रहीत संदेशों का एक गुच्छा है और आप सर्वर पर संदेशों के साथ उनकी तुलना नहीं करना चाहते हैं।

इस अनुरोध का पहला पैरामीटर UIDVALIDITY है, जिसका उपयोग अनिवार्य रूप से यह सत्यापित करने के लिए किया जाता है कि आपके द्वारा पहले प्राप्त किया गया uid फ़ोल्डर में परिवर्तित नहीं हुआ था। यह तब हो सकता है जब सर्वर सभी संदेशों के लिए सत्र से सत्र तक यूआईडी को बदलता है या फ़ोल्डर हटा दिया गया था और उसी स्थान पर समान नाम वाला एक फ़ोल्डर बनाया गया था।

दूसरा पैरामीटर है HIGHESTMODSEQ जो हमारे लिए जाना जाता है और अंतिम ज्ञात यूआईडी का अंतराल है, उन्हें एक बृहदान्त्र के रूप में लिखा जा सकता है, यदि अंतराल निरंतर है, या अल्पविराम द्वारा अलग किया गया है।

निष्कर्ष

मेरे उदाहरण में, मैं एक ऐसी स्थिति में आया था, जहां विषय क्षेत्र की अज्ञानता से आवेदन का गलत और अडॉप्टिमल संचालन होता है। मैंने इस लेख के साथ प्रोटोकॉल का उपयोग करने के लिए सभी संभावित विकल्पों को कवर नहीं किया। लेकिन मुझे आशा है कि IMAP क्लाइंट के अगले डेवलपर के लिए उपरोक्त जानकारी उपयोगी होगी।

IMAP में एक टन दिलचस्प सामान है। त्वरित सिंक्रनाइज़ेशन के लिए कमांड सिर्फ शुरुआत है, वास्तव में, आप सर्वर की क्षमताओं के आधार पर, विभिन्न आईएमएपी कमांडों को और अधिक अनुकूलित कर सकते हैं, और तेजी से मेल के साथ काम कर सकते हैं, नेटवर्क और मेमोरी पर अधिक किफायती, और आम तौर पर अधिक सुखद। लेकिन मैं इस बारे में बाद में बात करूंगा।

जल्दी जाना है। फास्ट IMAP ईमेल सिंक