VPN बदलने के बाद Mail घूमता रहता है: फिर से सिंक करें या दोबारा डाउनलोड करें?

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

एक व्यस्त संकेतक, तीन अलग कहानियाँ

तीन संभावनाएँ हैं सामान्य पुनः सिंक, बार-बार प्रयास करती लॉगिन या प्रमाणीकरण विफलता, और पथ की समस्या जिसमें Mail नए नेटवर्क से सर्वर तक पहुँच ही नहीं पाता। दूर से ये एक जैसी दिखती हैं, क्योंकि तीनों एक ही विंडो को हिलाती हैं, और तीनों के लिए अलग कदम चाहिए।

वही तालिका पूरा निर्णय है। यह यह भी समझाती है कि «यह फिर डाउनलोड कर रहा है» विंडो का वर्णन है, खराबी का निदान नहीं, और लॉगिन विफलता के जवाब में VPN सेटिंग बदलना शायद ही कभी मदद करता है।

कुछ भी व्याख्या करने से पहले खाते की स्थिति पढ़ें

प्रभावित खाते के पास या Mail विंडो के भीतर स्थिति संकेतक खोजें और उसे खोलें ताकि सटीक संदेश दिखे। भेजने और प्राप्त करने पर Apple का मार्गदर्शन कनेक्शन समस्याओं, लॉगिन विफलताओं, सेवा की उपलब्धता और खाता सीमाओं को अलग करता है, और ये चार श्रेणियाँ चार अलग ज़िम्मेदार लोगों तक ले जाती हैं। सेवा की उपलब्धता वाले संदेश के लिए पासवर्ड दोबारा टाइप करना उसी दोपहर को दो बार बर्बाद करता है।

परीक्षण संकीर्ण रखें: एक खाता, एक नया कार्य जो कोई संवेदनशील चीज़ साझा न करे, और सब कुछ उसी पथ से जिसे आप उपयोग करना चाहते हैं। कैश किया गया इनबॉक्स पूरी तरह दिखाई देता रह सकता है जबकि मौजूदा सिंक विफल हो जाए, जिससे «मैं अपना मेल देख सकता हूँ» यह जाँचने की खराब परीक्षा बन जाता है कि कुछ आ रहा है या नहीं। सेटिंग बदलने से पहले स्थिति का सटीक पाठ लिख लें, क्योंकि बाद में वही वाक्य आपका एकमात्र सबूत होगा। पाँच मिनट बाद याद रहने वाला संस्करण हमेशा स्क्रीन वाले संस्करण से अधिक धुँधला होता है।

Mac में इंटरनेट है, पर Mail कहता है ऑफ़लाइन

जब मशीन पर बाकी सब कुछ काम करता है और Mail ऑफ़लाइन बताता है, दिलचस्प सवाल यह है कि कनेक्शन से कौन सा पथ लेने को कहा जा रहा है। प्रॉक्सी सेटिंग, नेटवर्क फ़िल्टर या ऐसा टनल जो केवल कुछ ट्रैफ़िक ले जाता है, Mail को ऐसे मार्ग पर छोड़ सकते हैं जिस पर सर्वर जवाब नहीं देगा। खाता संपादित करने से पहले जाँचें कि सिस्टम-स्तर का प्रॉक्सी कॉन्फ़िगरेशन क्या कहता है।

scutil --proxy

फिर खाते को पथ से अलग करें। वेबमेल साबित करता है कि खाता प्रदाता के पास काम करता है, लेकिन यह Mail ऐप के कॉन्फ़िगरेशन या ऐप जिस पथ का उपयोग करता है उसके बारे में कुछ भी साबित नहीं करता, क्योंकि ब्राउज़र अलग प्रॉक्सी प्रबंधन के साथ पूरी तरह अलग रास्ता ले सकता है। भेजना और प्राप्त करना भी अलग सेवाओं पर निर्भर हो सकता है, इसलिए एक सफल कार्य दूसरे की पूरी परीक्षा नहीं है।

डुप्लिकेट एक अलग अवलोकन है

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

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

खाता हटाने से पहले निर्णय लें

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

अंत में याद रखें कि गतिविधि प्रदर्शन क्या है। यह Mail के अपने काम के बारे में ऐप का अवलोकन है, यह सबूत नहीं कि VPN रोका नहीं जा सकता या टनल ज़िम्मेदार है। निर्णय, क्रम में, यह है: स्थिति पढ़ें, तालिका के अनुसार उसे वर्गीकृत करें, इच्छित पथ से एक कार्य जाँचें, और तभी खाते को छुएँ।