VPN फेरेपछि Mail घुमिरहन्छ: फेरि सिङ्क गर्ने कि फेरि डाउनलोड गर्ने?

नेटवर्क परिवर्तनले Mail लाई उठाउँदा र प्रगति सूचक सर्न थाल्दा, मानिसहरूले VPN ले पूर्ण फेरि डाउनलोड थोप्यो भनी निष्कर्ष निकाल्ने ठ्याक्कै त्यही क्षण हो। सामान्यतया त्यसो भएको हुँदैन। फेरि जडान हुनुले सिङ्क्रोनाइजेसन चरण सुरु गर्छ, र सिङ्क्रोनाइजेसन चरणले सन्देशको मुख्य भागमा पुग्नुभन्दा धेरै अघि मेलबक्सको अवस्था, झन्डा र सन्देश मेटाडाटा समेट्छ। उपयोगी निर्णय भनेको तपाईं तीन कथामध्ये कुनमा हुनुहुन्छ भन्ने हो, र त्यो तपाईंलाई खाताको आफ्नै स्थितिले मात्र बताउन सक्छ।

एउटा व्यस्त सूचक, तीन फरक कथा

तीन सम्भावना हुन् सामान्य फेरि सिङ्क, बारम्बार प्रयास गर्ने लगइन वा प्रमाणीकरण त्रुटि, र नयाँ नेटवर्कबाट Mail सर्भरसम्म पुग्नै नसक्ने मार्ग समस्या। टाढाबाट ती उस्तै देखिन्छन्, किनकि तीनवटै एउटै विन्डो हल्लाउँछन्, र तीनवटैका लागि फरक कदम चाहिन्छ।

त्यही तालिका पूरै निर्णय हो। «यो फेरि डाउनलोड गर्दै छ» भन्ने विन्डोको वर्णन हो, खराबीको निदान होइन, र लगइन त्रुटिको जवाफमा VPN सेटिङ बदल्नु किन विरलै सहयोग हुन्छ भन्ने पनि त्यसले व्याख्या गर्छ।

केही पनि व्याख्या गर्नुअघि खाताको स्थिति पढ्नुहोस्

प्रभावित खाताको छेउमा वा Mail विन्डोभित्र स्थिति सूचक खोज्नुहोस् र ठ्याक्कै सन्देश देखिने गरी खोल्नुहोस्। पठाउने र प्राप्त गर्नेबारे Apple को मार्गदर्शनले जडान समस्या, लगइन असफलता, सेवाको उपलब्धता र खाता सीमा छुट्याउँछ, र यी चार श्रेणी चार फरक जिम्मेवार व्यक्तितर्फ लैजान्छन्। सेवाको उपलब्धताबारे सन्देशका लागि पासवर्ड फेरि टाइप गर्नु त्यही दिउँसो दुई पटक बर्बाद गर्नु हो।

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

Mac सँग इन्टरनेट छ, तर Mail अफलाइन छ भन्छ

जब मेसिनमा बाँकी सबै काम गर्छ र Mail अफलाइन भएको जनाउँछ, रोचक प्रश्न यो हो कि जडानलाई कुन मार्गबाट जान भनिएको छ। प्रोक्सी सेटिङ, नेटवर्क फिल्टर वा थोरै ट्राफिक मात्र बोक्ने टनेलले Mail लाई सर्भरले जवाफ नदिने मार्गमा छोड्न सक्छ। खाता सम्पादन गर्नुअघि प्रणाली-स्तरको प्रोक्सी कन्फिगरेसनले के भन्छ हेर्नुहोस्।

scutil --proxy

त्यसपछि खातालाई मार्गबाट अलग गर्नुहोस्। वेबमेलले खाता प्रदायककहाँ चल्छ भनी प्रमाणित गर्छ, तर Mail एपको कन्फिगरेसन वा एपले प्रयोग गर्ने मार्गबारे केही पनि प्रमाणित गर्दैन, किनकि ब्राउजरले फरक प्रोक्सी व्यवस्थापनसहित पूरै फरक बाटो लिन सक्छ। पठाउने र प्राप्त गर्ने पनि फरक सेवामा निर्भर हुन सक्छ, त्यसैले एउटा सफल कार्य अर्कोको पूर्ण परीक्षण होइन।

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

चलिरहेको सिङ्क्रोनाइजेसन देखिने डुप्लिकेट बनेको प्रमाण होइन, र पहिले नै रहेका डुप्लिकेट VPN ले के गर्यो भन्ने प्रमाण होइन। यदि साँच्चै दोहोरिएका प्रतिलिपि देख्नुहुन्छ भने, त्यसलाई छुट्टै फेला रूपमा लेख्नुहोस् र प्रदायकसँग सर्भरतर्फ मेलबक्स जाँच्नुहोस्। यसले प्रतिलिपि एक पटक छन् र दुई पटक देखाइन्छन्, कि साँच्चै दुई पटक छन् भन्ने बताउँछ।

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

खाता हटाउनुअघि निर्णय गर्नुहोस्

यदि स्वीकृत रिकभरी प्रक्रियाले साँच्चै खाता हटाएर फेरि थप्न आवश्यक ठान्छ भने, फेरि प्राप्त गर्न नसकिने दुई कुरा जोगाउनुहोस्: नपठाइएको काम र यही मेसिनमा मात्र रहेको कुनै पनि मेल। नेटवर्क परिवर्तन तालिका बनाउनुअघि नै, पछि होइन, बुझाउनुपर्ने सबै पूरा गर्नुहोस्, त्यसपछि VPN को मालिकको सामान्य नियन्त्रणमार्फत डिस्कनेक्ट गर्नुहोस्।

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